LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   IP-Tables configuration dropping packets. (https://www.linuxquestions.org/questions/linux-networking-3/ip-tables-configuration-dropping-packets-746586/)

J.Sherman 08-10-2009 08:13 PM
IP-Tables configuration dropping packets.
 
Hey guys,

I've compiled (what I thought) was a pretty good IPTables configuration - and it worked well for a while, until I stopped using it for a while (and must have changed something). Now it seems that all packets get dropped (Or either the INPUT or OUTPUT tables is dropping packets) because I can not successfully connect to any websites using HTTP, I can't ssh to other computers (times out), etc.

I've looked through it quite a bit, and I can't find the problem, I must be missing something. Anyway, heres the script for it (for iptables-restore):

Code:
# Generated by iptables-save v1.4.0
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [1:231]
:f0to1 - [0:0]
:f1to0 - [0:0]
:logaborted - [0:0]
:logaborted2 - [0:0]
:logdrop - [0:0]
:logdrop2 - [0:0]
:logreject - [0:0]
:logreject2 - [0:0]
:nicfilt - [0:0]
:s0 - [0:0]
:syn_flood - [0:0]

-A INPUT -p tcp --syn -j syn_flood
-A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
-A syn_flood -j DROP

-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP
-A INPUT -f -j DROP

-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --tcp-flags RST RST -j logaborted
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -j nicfilt
-A INPUT -j s0
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -j f1to0
-A f0to1 -p tcp -m tcp --sport 1024:65535 --dport 6881:6889 -m state --state NEW -j ACCEPT
-A f0to1 -j logdrop
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 22 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 0:1023 --dport 22 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 1080 -m state --state NEW -j ACCEPT
-A f1to0 -p udp -m udp --dport 1080 -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 3389 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 6660:6669 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 23 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 21 -m state --state NEW -j ACCEPT
-A f1to0 -p udp -m udp --sport 1024:5999 --dport 37 -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 37 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
-A f1to0 -p udp -m udp --dport 53 -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 6969 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 6881:6889 -m state --state NEW -j ACCEPT
-A f1to0 -p udp -m udp --dport 28785:28786 -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 5900:5903 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 5800 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 1863 -m state --state NEW -j ACCEPT
-A f1to0 -p udp -m udp --dport 123 -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 123 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 443 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 80 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 8080 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 8008 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 8000 -m state --state NEW -j ACCEPT
-A f1to0 -p tcp -m tcp --sport 1024:5999 --dport 8888 -m state --state NEW -j ACCEPT
-A f1to0 -p udp -m udp --dport 514 -j ACCEPT
-A f1to0 -j logdrop
-A logaborted -m limit --limit 1/sec --limit-burst 10 -j logaborted2
-A logaborted -m limit --limit 2/min --limit-burst 1 -j LOG --log-prefix "LIMITED "
-A logaborted2 -j LOG --log-prefix "ABORTED " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaborted2 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A logdrop -m limit --limit 1/sec --limit-burst 10 -j logdrop2
-A logdrop -m limit --limit 2/min --limit-burst 1 -j LOG --log-prefix "LIMITED "
-A logdrop -j DROP
-A logdrop2 -j LOG --log-prefix "DROPPED " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop2 -j DROP
-A logreject -m limit --limit 1/sec --limit-burst 10 -j logreject2
-A logreject -m limit --limit 2/min --limit-burst 1 -j LOG --log-prefix "LIMITED "
-A logreject -p tcp -j REJECT --reject-with tcp-reset
-A logreject -p udp -j REJECT --reject-with icmp-port-unreachable
-A logreject -j DROP
-A logreject2 -j LOG --log-prefix "REJECTED " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logreject2 -p tcp -j REJECT --reject-with tcp-reset
-A logreject2 -p udp -j REJECT --reject-with icmp-port-unreachable
-A logreject2 -j DROP
-A nicfilt -i eth0 -j RETURN
-A nicfilt -i eth0 -j RETURN
-A nicfilt -i lo -j RETURN
-A nicfilt -j logdrop
-A s0 -d 127.0.0.1/32 -j f0to1
-A s0 -j logdrop 
COMMIT
Hope you guys can help, thanks. :)

win32sux 08-10-2009 08:33 PM
The filtered packets are being logged, right? Could you post the relevant snippets?

I suspect your source port matches might be to blame here, but I'm not sure.

J.Sherman 08-10-2009 09:28 PM
Code:
root@localhost:/var/log# ping google.com
PING google.com (74.125.67.100) 56(84) bytes of data.
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=1 ttl=52 time=296 ms
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=2 ttl=52 time=290 ms
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=3 ttl=52 time=293 ms
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=4 ttl=52 time=296 ms
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=5 ttl=52 time=293 ms
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=6 ttl=52 time=294 ms
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=7 ttl=52 time=288 ms
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=8 ttl=52 time=291 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7029ms
rtt min/avg/max/mdev = 288.616/293.166/296.744/2.803 ms
root@localhost:/var/log# wget google.com
--2009-08-11 12:21:44--  http://google.com/
Resolving google.com... 74.125.67.100, 74.125.127.100, 74.125.45.100
Connecting to google.com|74.125.67.100|:80... ^C
root@localhost:/var/log# ftp google.com
*nothing*
^C
root@localhost:/var/log# nc google.com 80
*nothing*
^C
root@localhost:/var/log# nc -v www.linuxquestions.org 80
*nothing*
^C
root@localhost:/var/log# nc -v www.linuxquestions.org 6252
*no reset packet?*
^C
root@localhost:/var/log# iptables -F
root@localhost:/var/log# iptables -P INPUT ACCEPT
root@localhost:/var/log# iptables -P OUTPUT ACCEPT
root@localhost:/var/log#
Also, I looked in my syslog and the only filtered packets seem to be DHCP packets from my internal network (I use a cable modem).

Weird, as ping requests work fine but it seems that a lot of TCP protocol packets don't work. The syslog provides useless data (no relevance).


All times are GMT -5. The time now is 11:53 PM.