Iptables and reject rules

andy.l · 05-01-2011, 12:02 PM

Hi
Working on an new firewall script. My default rule is:

Code:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

But I would like to reject all internal traffic not explicit allowed.
This does not seem to work from internal(eth2) and dmz(eth1):

Code:

iptables -P FORWARD -i eth2 -j REJECT
iptables -P FORWARD -i eth1 -j REJECT

/Andy

win32sux · 05-01-2011, 03:57 PM

In your first code block, you're setting chain policies, so the -P is fine. In the second code block, you're creating actual rules, so you don't use -P anymore. You need to either append (-A) or insert (-I) the rules. See man iptables for more info.

andy.l · 05-01-2011, 05:10 PM

Well I tried that as well and added the following rules:
Forward:

Code:

#reject all other traffic not explisit allowed between DMZ and LAN
iptables -A FORWARD -p ALL -s 192.168.20.0/24 -i eth2 -o eth1 -j REJECT
iptables -A FORWARD -p ALL -s 192.168.10.0/24 -i eth1 -o eth2 -j REJECT
#eject all other traffic not explisit allowed outbound from lan and dmz
iptables -A FORWARD -p ALL -s 192.168.20.0/24 -i eth2 -o eth0 -j REJECT
iptables -A FORWARD -p ALL -s 192.168.10.0/24 -i eth1 -o eth0 -j REJECT

And input:

Code:

# reject internal traffic in on eth2 and eth1 instead of deafault drop
iptables -A INPUT -p ALL -s 192.168.20.0/24 -i eth2 -d 192.168.20.1 -j REJECT
iptables -A INPUT -p ALL -s 192.168.10.0/24 -i eth1 -d 192.168.10.1 -j REJECT

As a controll I tried to telnet to the firewall on IP 192.168.20.1 from IP 192.168.20.2, and didn't get any error messages. Only a generic message saying:

Code:

Connection timed out

/Andy.l

win32sux · 05-01-2011, 09:45 PM

Show us what your INPUT chain's current configuration looks like:

Code:

iptables -nvL INPUT

andy.l · 05-02-2011, 02:13 AM

Here are my input rules:

Code:

#standard rules  stopper alt default uten en lyd###################
iptables -P INPUT   DROP
iptables -P OUTPUT  DROP
iptables -P FORWARD DROP
################################################################################################################################
#INPUT Rules 
# ping 2 firewall from Officenett siden officenett skal kunne pinge FW
iptables -A INPUT -p ICMP -s 192.168.20.0/24 -i eth2 -d 192.168.20.1 --icmp-type echo-request -j ACCEPT
#Ping reply from officenett 2 firewall siden vi skal kunne pinge fra FW
iptables -A INPUT -p ICMP -s 192.168.20.0/24 -i eth2 -d 192.168.20.1 --icmp-type echo-reply -j ACCEPT
#ping reply 2 firewall from DMZ siden vi skal kunne pinge og få svar fra servere i DMZ på firewall
iptables -A INPUT -p ICMP -s 192.168.10.0/24 -i eth1 -d 192.168.10.1 --icmp-type echo-reply -j ACCEPT
#SSH 2 firewall siden vi skal kunne SSH inn på boksen fra officenett
iptables -A INPUT -p tcp  -s 192.168.20.0/24 -i eth2 -d 192.168.20.1 --dport 22 -j ACCEPT
#DNS incomming on WAN interface.NB! Ikke en del av oppgaven men gjorde kommunikasjon mot ftp.no.debian.org via fqdn mulig
iptables -A INPUT -p udp -s 0/0 -i eth0 --sport 53 -j ACCEPT
#Internet 2 firewall
# reject internal traffic in on eth2 and eth1 instead of deafault drop
iptables -A INPUT -p ALL -s 192.168.20.0/24 -i eth2 -d 192.168.20.1 -j REJECT
iptables -A INPUT -p ALL -s 192.168.10.0/24 -i eth1 -d 192.168.10.1 -j REJECT

/Andy.l

win32sux · 05-02-2011, 02:56 PM

That shows us what you wish to have, not what you actually do have.

The command I posted, OTOH, would show us your actual/current configuration.

andy.l · 05-02-2011, 03:17 PM

here is the result:

Code:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     icmp --  eth2   *       192.168.20.0/24      192.168.20.1        icmp type 8
    0     0 ACCEPT     icmp --  eth2   *       192.168.20.0/24      192.168.20.1        icmp type 0
    0     0 ACCEPT     icmp --  eth1   *       192.168.10.0/24      192.168.10.1        icmp type 0
    0     0 ACCEPT     tcp  --  eth2   *       192.168.20.0/24      192.168.20.1        tcp dpt:22
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp spt:53
    0     0 REJECT     all  --  eth2   *       192.168.20.0/24      192.168.20.1        reject-with icmp-port-unreachable
    3   180 REJECT     all  --  eth1   *       192.168.10.0/24      192.168.10.1        reject-with icmp-port-unreachable

/Andy

win32sux · 05-02-2011, 08:55 PM

I can't see anything wrong there (relevant to the issue at hand, at least). Could you add a LOG rule to the end of the INPUT chain then check the log file for evidence that the packet is getting sent to DROP by the policy?

Code:

iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "

Otherwise, the problem would seem to lie somewhere else. You're sure that host 192.168.20.1 was going in through eth2, right? I ask because if it wasn't, then that would mean a DROP would be used instead of a REJECT.

frankbell · 05-02-2011, 09:41 PM

One of the members of my LUG gave a presentation about iptables and posted his script to the LUG's website. Maybe it will help.

andy.l · 05-03-2011, 01:54 AM

I have three NIC's in the gateway:

Code:

eth0 - wan link, 
eth2 - lan IP:192.168.20.1 network 192.168.20.0/24
eth1 - DMZ IP 192.168.10.1 network 192.168.10.0/24

/Andy

win32sux · 05-03-2011, 09:54 AM

We kinda knew that already.

Do you have the log file snippet(s) ready to share?

andy.l · 05-03-2011, 10:54 AM

So I addef the following at the end of my INPUT rules:

Code:

#Internet 2 firewall
# reject internal traffic in on eth2 and eth1 instead of deafault drop
iptables -A INPUT -j LOG
iptables -A INPUT -p ALL -s 192.168.70.0/24 -i eth2 -d 192.168.70.1 -j REJECT
iptables -A INPUT -p ALL -s 192.168.10.0/24 -i eth1 -d 192.168.10.1 -j REJECT

And that give this in /var/log/kern.log:

Code:

May  3 19:45:43 dc7700 kernel: [  831.913563] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=27959 DF PROTO=TCP SPT=39681 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:45:49 dc7700 kernel: [  837.929417] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=27960 DF PROTO=TCP SPT=39681 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:46:01 dc7700 kernel: [  849.945178] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=27961 DF PROTO=TCP SPT=39681 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:46:25 dc7700 kernel: [  873.976876] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=27962 DF PROTO=TCP SPT=39681 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:47:13 dc7700 kernel: [  922.039851] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=27963 DF PROTO=TCP SPT=39681 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:48:42 dc7700 kernel: [ 1011.224284] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=34537 DF PROTO=TCP SPT=42895 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:48:45 dc7700 kernel: [ 1014.229743] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=34538 DF PROTO=TCP SPT=42895 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:48:51 dc7700 kernel: [ 1020.245664] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=34539 DF PROTO=TCP SPT=42895 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:49:03 dc7700 kernel: [ 1032.277420] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=34540 DF PROTO=TCP SPT=42895 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
May  3 19:49:27 dc7700 kernel: [ 1056.308907] IN=eth1 OUT= MAC=00:0f:fe:50:54:0f:90:e6:ba:0a:4b:cf:08:00 SRC=192.168.10.4 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=34541 DF PROTO=TCP SPT=42895 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

/Andy

andy.l · 05-03-2011, 11:37 AM

I tried to do one thing now, I added the following line to my output chain:

Code:

 iptables -A OUTPUT -p ICMP -j ACCEPT

and when I now try to telnet or browse to the firewall i get an "connection refused" notification

/Andy

andy.l · 05-03-2011, 12:05 PM

So did some additional testing, and added the following lines to my OUTPUT chain:

Code:

iptables -A OUTPUT -p ICMP -o eth1 --icmp-type port-unreachable -j ACCEPT
iptables -A OUTPUT -p ICMP -o eth2 --icmp-type port-unreachable -j ACCEPT

So this actually allows the firewall to send out port-unreachable messages in response for the packages that are rejected. When no rules are in place (as for eth0, WAN interface) the default policy of drop will take effect and packages will be silently dropped.
Any feedback to this conclusion?

/Andy.l

win32sux · 05-04-2011, 12:47 AM

Quote:

Originally Posted by andy.l

So did some additional testing, and added the following lines to my OUTPUT chain:

Code:

iptables -A OUTPUT -p ICMP -o eth1 --icmp-type port-unreachable -j ACCEPT
iptables -A OUTPUT -p ICMP -o eth2 --icmp-type port-unreachable -j ACCEPT

So this actually allows the firewall to send out port-unreachable messages in response for the packages that are rejected. When no rules are in place (as for eth0, WAN interface) the default policy of drop will take effect and packages will be silently dropped.
Any feedback to this conclusion?

/Andy.l

Your conclusion makes perfect sense.

I would just add that you don't really need to do any ICMP matching here. As long as you're matching packets in state RELATED, you'll be fine. I had actually assumed you were matching both RELATED and ESTABLISHED. Using these state matches in the OUTPUT chain is usually a better idea than specifying a protocol/port/code/etc, as it prevents arbitrarily-generated packets from exiting.

Practically speaking, you could get rid of those two rules with a single one like:

Code:

iptables -A OUTPUT -m state --state RELATED -j ACCEPT

You could also just add the RELATED match to each of the two rules if you wanna keep them.

Personally, I prefer to just kill two birds with one stone:

Code:

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT