You are not logged in.
Pages: 1
(Moderator: please move this topic to another place if this doesn't fit here)
I need a bit help with my Arch nat server setup.
I'd like to know how to drop all the requests sent out to internet that aren't going to port 80 (or to ftp, 21) from ip range of 10.0.0.6-10.0.0.15. Basically allowing http only to those clients/ips.
Thanks in advance. :)
EDIT: This might work, but I'd like to have someone of you, sirs, to confirm this:
-A FORWARD -p tcp -m multiport --dports ! 21,80 -m iprange --src-range 10.0.0.6-10.0.0.15 -j DROP
Last edited by Zucca (2011-05-05 04:58:22)
K.i.s.s. <3
Offline
Did you test that? It should work...
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Nope.
I can still ssh from my test client to random location on the internet.
K.i.s.s. <3
Offline
Might have to do it as multiple rules then... I'm not sure how --dports reacts to negation with multiple ports.
-A FORWARD -p tcp -m multiport --dports 21,80 -m iprange --src-range 10.0.0.6-10.0.0.15 -j ACCEPT
-A FORWARD -m iprange --src-range 10.0.0.6-10.0.0.15 -j DROP
As a side note, to be 'proper' you should REJECT the traffic rather than drop it... It's nicer than just DROP'ing it, especially for internal hosts.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Might have to do it as multiple rules then... I'm not sure how --dports reacts to negation with multiple ports.
It should work correctly even with multiple ports.
As a side note, to be 'proper' you should REJECT the traffic rather than drop it... It's nicer than just DROP'ing it, especially for internal hosts.
That depends it's like the great debates in kde-gnome, vim-emacs... you know
By the way... how did you set up the NAT?
Last edited by Damnshock (2011-05-05 10:53:47)
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
EDIT: This might work, but I'd like to have someone of you, sirs, to confirm this:
-A FORWARD -p tcp -m multiport --dports ! 21,80 -m iprange --src-range 10.0.0.6-10.0.0.15 -j DROP
I'm no iptables expert, but isn't the exclamation mark meant to go before the option, like this:
-A FORWARD -p tcp -m multiport ! --dports 21,80 -m iprange --src-range 10.0.0.6-10.0.0.15 -j DROP
It might also be useful to debug if you post the output of "iptables -nvL" after trying to add your rule.
Last edited by jnguyen (2011-05-05 11:02:00)
TOMOYO Linux: Mandatory Access Control.
My AUR packages
Offline
Member, I believe you are right
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
That depends it's like the great debates in kde-gnome, vim-emacs... you know
OT, but not really.... TCP expects either a RST packet, or ICMP port unreachable if the connection can not be made. The only time the SYN should disappear into a blackhole is if the destination host is unreachable, and even then the last router should return an ICMP host unreachable in return.
Having said that, I tend to DROP traffic coming in from the NET that isn't allowed, since it's mostly kiddies and/or malicious. REJECT'ing traffic from internal hosts allows the application to handle the failed connection a lot faster than if it's waiting for a never arriving return packet.... Which is useful when it's YOU that's waiting and wondering why things are taking so long
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Having said that, I tend to DROP traffic coming in from the NET that isn't allowed, since it's mostly kiddies and/or malicious. REJECT'ing traffic from internal hosts allows the application to handle the failed connection a lot faster than if it's waiting for a never arriving return packet.... Which is useful when it's YOU that's waiting and wondering why things are taking so long
That's what I belive. Also using DROP for request from outside is better against ddoses (right?).
Also I put exclamation mark where it belongs (as iptables told my actually).
But I'm still in the starting position. These tips didn't work...
Here's my config now (I guess it's a mess):
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Some routing stuff... eth0 = WAN, wlan0 = LAN
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
-A FORWARD -p tcp -m multiport ! --dports 21,80 -m iprange --src-range 10.0.0.4-10.0.0.15 -j DROP
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
# For redirecting all http traffic trough proxy (on port 8888)
-A PREROUTING -i wlan0 -p tcp --dport 80 -j DNAT --to 10.0.0.1:8888
-A PREROUTING -i wlan0 -p tcp --dport 8080 -j DNAT --to 10.0.0.1:8888
-A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 80
COMMIT
Last edited by Zucca (2011-05-05 17:14:49)
K.i.s.s. <3
Offline
Damnshock wrote:That depends it's like the great debates in kde-gnome, vim-emacs... you know
OT, but not really.... TCP expects either a RST packet, or ICMP port unreachable if the connection can not be made. The only time the SYN should disappear into a blackhole is if the destination host is unreachable, and even then the last router should return an ICMP host unreachable in return.
Having said that, I tend to DROP traffic coming in from the NET that isn't allowed, since it's mostly kiddies and/or malicious. REJECT'ing traffic from internal hosts allows the application to handle the failed connection a lot faster than if it's waiting for a never arriving return packet.... Which is useful when it's YOU that's waiting and wondering why things are taking so long
I agree to that if you assume the traffic coming from internal network is legitimate
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
-A FORWARD -i wlan0 -o eth0 -j ACCEPT -A FORWARD -p tcp -m multiport ! --dports 21,80 -m iprange --src-range 10.0.0.4-10.0.0.15 -j DROP
Maybe your packets are getting into the first rule and therefore being accepted?
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
Zucca wrote:-A FORWARD -i wlan0 -o eth0 -j ACCEPT -A FORWARD -p tcp -m multiport ! --dports 21,80 -m iprange --src-range 10.0.0.4-10.0.0.15 -j DROP
Maybe your packets are getting into the first rule and therefore being accepted?
Ok. that partially fixed it. But still each client can establish a connection between machines in LAN trough any port.
Here's the newest config:
*filter
-A FORWARD -p tcp -m multiport ! --dports 21,80 -m iprange --src-range 10.0.0.4-10.0.0.15 -j REJECT
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Some routing stuff... eth0 = WAN, wlan0 = LAN
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
# For redirecting all http traffic trough proxy (on port 8888)
-A PREROUTING -i wlan0 -p tcp --dport 80 -j DNAT --to 10.0.0.1:8888
-A PREROUTING -i wlan0 -p tcp --dport 8080 -j DNAT --to 10.0.0.1:8888
-A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 80
COMMIT
K.i.s.s. <3
Offline
Ok. that partially fixed it. But still each client can establish a connection between machines in LAN trough any port.
You can't control LAN to LAN traffic via the firewall/router. Traffic in the same broadcast domain goes direct from host to host, not routed through the firewall/router.
EDIT:
I agree to that if you assume the traffic coming from internal network is legitimate
Jump to "LIMITED_REJECT" instead of just REJECT.... Internal traffic has the benefit of (usually) having a much higher bandwidth/lower latency than your 'net connection
-N LIMITED_REJECT
-A LIMITED_REJECT -m limit --limit 3/sec -j REJECT
-A LIMITED_REJECT -j DROP
Last edited by fukawi2 (2011-05-05 23:15:22)
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
You can't control LAN to LAN traffic via the firewall/router. Traffic in the same broadcast domain goes direct from host to host, not routed through the firewall/router.
You can if you redirect all the traffic, even the internal, through the router/firewall
-N LIMITED_REJECT -A LIMITED_REJECT -m limit --limit 3/sec -j REJECT -A LIMITED_REJECT -j DROP
That seems interesting, I'll look into it
Thanks!
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
*bump* Hi. i have this config working like I described in the last post. I'm happy with it now.
However setting iptables rules is somewhat arcane (at lest for me). I wonder if it's safe to use some frontend (ie. the one ubuntu uses) when fail2ban is constantly modifying the rules..?
K.i.s.s. <3
Offline
Pages: 1