iptables help?

Zucca · 2011-05-04 17:46:32

(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)

fukawi2 · 2011-05-04 23:43:59

Did you test that? It should work...

Zucca · 2011-05-05 04:57:46

Nope.
I can still ssh from my test client to random location on the internet.

fukawi2 · 2011-05-05 10:41:04

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.

Damnshock · 2011-05-05 10:50:52

fukawi2 wrote:

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)

jnguyen · 2011-05-05 10:57:39

Zucca wrote:

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)

Damnshock · 2011-05-05 11:37:55

Member, I believe you are right

fukawi2 · 2011-05-05 12:42:54

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

Zucca · 2011-05-05 15:11:16

fukawi2 wrote:

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)

Damnshock · 2011-05-05 16:23:34

fukawi2 wrote:

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

Damnshock · 2011-05-05 16:32:59

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?

Zucca · 2011-05-05 17:36:16

Damnshock wrote:

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

fukawi2 · 2011-05-05 23:11:46

Zucca wrote:

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:

Damnshock wrote:

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)

Damnshock · 2011-05-06 11:33:35

fukawi2 wrote:

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!

Zucca · 2011-05-24 17:15:34

*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..?

Arch Linux

#1 2011-05-04 17:46:32

iptables help?

#2 2011-05-04 23:43:59

Re: iptables help?

#3 2011-05-05 04:57:46

Re: iptables help?

#4 2011-05-05 10:41:04

Re: iptables help?

#5 2011-05-05 10:50:52

Re: iptables help?

#6 2011-05-05 10:57:39

Re: iptables help?

#7 2011-05-05 11:37:55

Re: iptables help?

#8 2011-05-05 12:42:54

Re: iptables help?

#9 2011-05-05 15:11:16

Re: iptables help?

#10 2011-05-05 16:23:34

Re: iptables help?

#11 2011-05-05 16:32:59

Re: iptables help?

#12 2011-05-05 17:36:16

Re: iptables help?

#13 2011-05-05 23:11:46

Re: iptables help?

#14 2011-05-06 11:33:35

Re: iptables help?

#15 2011-05-24 17:15:34

Re: iptables help?

Board footer