IPTABLES Issues

Soulful93 · 09-18-2005, 05:15 PM

For some reason I'm getting an error, whenever the --icmp-type argument is invoked?

Code:

iptables v1.3.1: Unknown arg `--icmp-type'
Try `iptables -h' or 'iptables --help' for more information.

win32sux · 09-18-2005, 05:57 PM

Quote:

Originally posted by Soulful93
For some reason I'm getting an error, whenever the --icmp-type argument is invoked?

Code:

iptables v1.3.1: Unknown arg `--icmp-type' Try `iptables -h' or 'iptables --help' for more information.

look for the rules in your script which have "--icmp-type" in them... you probably just have a syntax error/typo... make sure you are actually specifying a type, such as for example:

Code:

iptables -A WHATEVER -p ICMP --icmp-type 8 -j REJECT

Soulful93 · 09-19-2005, 05:45 PM

For some reason this is blocking my SMB connections. I've tried making the samba section less-complex but it doesn't seem to be helping. SMB works just fine with I stop and flush iptables? Does anyone have any idea's? Also, because the BAD_PACKETS chain has been created should I set a default drop policy for that chain?

Code:

#!/bin/sh

IPT="/sbin/iptables"

echo "0" > /proc/sys/net/ipv4/ip_forward

echo "1" > /proc/sys/net/ipv4/tcp_syncookies

echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

/sbin/modprobe ip_conntrack_ftp

#Flush The Old Rules
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -X -t nat
$IPT -X -t mangle

echo Old Rules Flushed

#Set Default-Drop Policy
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP

#Create New Chain Called BAD_PACKETS
$IPT -N BAD_PACKETS

#Allow The Loopback
$IPT -A INPUT -i lo -j ACCEPT

#Jump To BAD_PACKETS
$IPT -A INPUT -j BAD_PACKETS

#Allow Established Connections
$IPT -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

#Allow SSH From Specified Hots
$IPT -A INPUT -p TCP -i eth0 --dport 22 -s 192.168.255.3 \-m state --state NEW -j ACCEPT
$IPT -A INPUT -p TCP -i eth0 --dport 22 -s 192.168.255.4 \-m state --state NEW -j ACCEPT

#Allow Samba From Specified Hosts
$IPT -A INPUT -p TCP -i eth0 --dport 137:139 -s 192.168.255.3 \-m state --state NEW -j ACCEPT
$IPT -A INPUT -p UDP -i eth0 --dport 137:139 -s 192.168.255.3 \-m state --state NEW -j ACCEPT
$IPT -A INPUT -p TCP -i eth0 --dport 137:139 -s 192.168.255.4 \-m state --state NEW -j ACCEPT
$IPT -A INPUT -p UDP -i eth0 --dport 137:139 -s 192.168.255.4 \-m state --state NEW -j ACCEPT

#Allow ICMP Replies From Specified Hosts (Ping)
$IPT -A INPUT -p ICMP -i eth0 --icmp-type 8 -s 192.168.255.3 \-m state --state NEW -j ACCEPT
$IPT -A INPUT -p ICMP -i eth0 --icmp-type 8 -s 192.168.255.4 \-m state --state NEW -j ACCEPT

#Log
$IPT -A INPUT -j LOG --log-prefix "INPUT DROP: "

#Accept Loopback On OUTPUT
$IPT -A OUTPUT -o lo -j ACCEPT

#Allow Established Connections
$IPT -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

#Allow HTTP,FTP,DNS, & Port 443 Outbound
$IPT -A OUTPUT -p TCP -o eth0 --dport 443 -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -p TCP -o eth0 --dport 80 -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -p UDP -o eth0 --dport 53 -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -p TCP -o eth0 --dport 21 -m state --state NEW -j ACCEPT

#Allow ICMP Replies (Ping)
$IPT -A OUTPUT -p ICMP -o eth0 --icmp-type 8 \-m state --state NEW -j ACCEPT

#Drop
$IPT -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: "
$IPT -A BAD_PACKETS -p TCP ! --syn -m state --state NEW -j DROP
$IPT -A BAD_PACKETS -p TCP --tcp-flags ALL ALL -j DROP
$IPT -A BAD_PACKETS -p TCP --tcp-flags ALL NONE -j DROP
$IPT -A BAD_PACKETS -p TCP --tcp-flags ALL SYN \-m state --state ESTABLISHED -j DROP
$IPT -A BAD_PACKETS -p ICMP --fragment -j DROP
$IPT -A BAD_PACKETS -m state --state INVALID -j DROP
$IPT -A BAD_PACKETS -d 255.255.255.255 -j DROP
$IPT -A BAD_PACKETS -j RETURN

echo "So let it be written. So let it be done."

win32sux · 09-19-2005, 06:13 PM

Quote:

Originally posted by Soulful93
For some reason this is blocking my SMB connections. I've tried making the samba section less-complex but it doesn't seem to be helping. SMB works just fine with I stop and flush iptables? Does anyone have any idea's?

look at your logfile... if a packet is getting dropped by the input chain it should appear in your logfile... you can look at your logfile in "real-time" with a:

Code:

tail -f /var/log/syslog

you should then be able to clearly see which packets are getting dropped at the time the connection fails... you can paste the relevant log entries here if you need to...

Quote:

Also, because the BAD_PACKETS chain has been created should I set a default drop policy for that chain?

you can only set policies for built-in chains (INPUT, OUTPUT, etc.) - not for user created ones...

besides, if you give the idea of a "bad packet chain policy" some more thought you will realize it's insane...

Soulful93 · 09-19-2005, 06:30 PM

This is the output of tail -f /var/log/messages (default Trustix syslog directory apparently).

Code:

Sep 17 01:25:57 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=UDP SPT=138 DPT=138 LEN=209
Sep 17 01:26:45 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=10 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:45 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=11 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:46 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=12 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:46 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=13 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:47 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=14 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:47 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=15 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:47 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=16 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:48 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=17 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:26:49 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=18 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:32 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=19 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:32 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=20 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=21 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=22 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=23 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=24 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:34 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=25 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:35 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=26 DF PROTO=UDP SPT=137 DPT=137 LEN=70
Sep 17 01:27:36 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=27 DF PROTO=UDP SPT=137 DPT=137 LEN=70

It's obvious that the packets are being dropped, but I still can't tell what might be causing it.

win32sux · 09-19-2005, 06:33 PM

a late reply

:

Quote:

Originally posted by Soulful93
It seems like your appending quite a bit, from which I just read appends a rule to the bottom of the ruleset. Is there a need for a specific order that you have to enter your rules?

yeah, the "-A" adds the rule to the bottom of the chain... "-I" adds it to the top... the rules are read top to bottom, so it DEFINITELY matters what order they are in...

analogical example: you have your iptables script running smoothly, everything is working fine... then one day you need to block IP address 192.168.200.101 from reaching your server for whatever reason... it's an emergency, so you wanna do it quickly from the command line interface (without editing and/or re-running your script)...

you might be tempted to do a:

Code:

iptables -A INPUT -s 192.168.200.101 -j DROP

but as you can see, the "-A" will append the command to the end of your INPUT chain... so packets coming from 192.168.200.101 will still get accepted by the rules above your new rule... the proper way to completely cut-off 192.168.200.101 would be:

Code:

iptables -I INPUT -s 192.168.200.101 -j DROP

now you now the rule will be inserted at the top of the chain, so all packets will go through the rule... so now you are sure that any packets from 192.168.200.101 will be filtered (until you reboot, re-run your script, or flush the tables in some other way)...

Quote:

Also, I'm not understanding what your doing with the -J RETURN. What does RETURN do?

we use the RETURN target in our user chains... it's purpose is to send the packet back to the "parent" chain... basically, when you add the RETURN target to the end of a user chain, what you are saying is: "okay, the packet didn't match any rules in this chain, so send it back and let it continue traversing the rules in the parent chain where it came from"...

AFAIK you can also use it as a target mid-chain itself with some specific matches, so as to return certain packets without having to traverse the entire chain...

(BTW i don't think it's technically called a "parent" chain but you get the idea...)

win32sux · 09-19-2005, 06:38 PM

Quote:

Originally posted by Soulful93
This is the output of tail -f /var/log/messages (default Trustix syslog directory apparently).

Code:

Sep 17 01:25:57 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=UDP SPT=138 DPT=138 LEN=209 Sep 17 01:26:45 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=10 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:45 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=11 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:46 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=12 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:46 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=13 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:47 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=14 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:47 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=15 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:47 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=16 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:48 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=17 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:26:49 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=18 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:32 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=19 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:32 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=20 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=21 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=22 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=23 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:33 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=24 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:34 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=25 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:35 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=26 DF PROTO=UDP SPT=137 DPT=137 LEN=70 Sep 17 01:27:36 Trustix kernel: OUTPUT DROP: IN= OUT=eth0 SRC=192.168.255.2 DST=192.168.255.4 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=27 DF PROTO=UDP SPT=137 DPT=137 LEN=70

It's obvious that the packets are being dropped, but I still can't tell what might be causing it.

outgoing UDP packets with --dport 137 and --sport 137 are getting filtered... since you are accepting ESTABLISHED and RELATED traffic in your OUTPUT chain, i assume the trustix box is attempting to start a new connection... if so, then something like this should do it:

Code:

$IPT -A OUTPUT -p UDP -o eth0 --dport 137 --sport 137 -m state --state NEW -j ACCEPT

(rememeber to place the rule in the appropriate spot in the script...)