LinuxQuestions.org - Iptables and reject rules

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Iptables and reject rules (https://www.linuxquestions.org/questions/linux-security-4/iptables-and-reject-rules-878151/)

Iptables and reject rules

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

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.

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

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

Code:

iptables -nvL INPUT

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

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.

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

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.

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.

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

We kinda knew that already. :)

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

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

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

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

Quote:

Originally Posted by andy.l (Post 4345282)

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

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