# iptables conntrack problems

## jcpunk

I am having a bunch of packets captured that I would not expect to be captured.  They are coming from my server and destined for some place else with the FIN bit set.  These have the mark of RELATED/ESTABLISHED to me but obviously.....  Any idea what is up?  I am getting similar behavior on INPUT as well, but it seems easier to troubleshoot merely my system rather than mine and someone else's...  If one is solved the other should be too.

Here are a few packets from last night:

```
Default DROP (OUTPUT): IN= OUT=eth0 SRC=192.168.132.39 DST=58.60.130.89 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=24309 DF PROTO=TCP SPT=25 DPT=42764 WINDOW=1460 RES=0x00 ACK FIN URGP=0 

Default DROP (OUTPUT): IN= OUT=eth0 SRC=192.168.132.39 DST=58.60.130.89 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=24311 DF PROTO=TCP SPT=25 DPT=42764 WINDOW=1460 RES=0x00 ACK FIN URGP=0 

Default DROP (OUTPUT): IN= OUT=eth0 SRC=192.168.132.39 DST=83.208.8.167 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=3683 DF PROTO=TCP SPT=25 DPT=29926 WINDOW=5840 RES=0x00 ACK FIN URGP=0 

Default DROP (OUTPUT): IN= OUT=eth0 SRC=192.168.132.39 DST=83.208.8.167 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=3685 DF PROTO=TCP SPT=25 DPT=29926 WINDOW=5840 RES=0x00 ACK FIN URGP=0 

Default DROP (OUTPUT): IN= OUT=eth0 SRC=192.168.132.39 DST=218.18.29.101 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=63905 DF PROTO=TCP SPT=25 DPT=19087 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 

Default DROP (OUTPUT): IN= OUT=eth0 SRC=192.168.132.39 DST=218.18.29.101 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=63907 DF PROTO=TCP SPT=25 DPT=19087 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
```

As you can see they are FIN/ACK packets essentially.  I would have expected "-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT " to let these out.

As you can see the modules are loaded:

```
# lsmod|grep ^ip_tables

ip_tables              19521  9 iptable_mangle,ipt_multiport,ipt_REJECT,ipt_conntrack,ipt_limit,ipt_state,ipt_LOG,iptable_filter

```

Here is the output from iptables-save:

```
# Generated by iptables-save v1.3.0 on Wed Jun  6 08:44:56 2007

*mangle

:FORWARD ACCEPT [0:0]

:INPUT ACCEPT [17693360:9672935788]

:LOGACTTCP - [0:0]

:OUTPUT ACCEPT [15908593:9528061786]

:POSTROUTING ACCEPT [15908318:9528012450]

:PREROUTING ACCEPT [7359832:3146528160]

-A LOGACTTCP -j LOG --log-prefix "Bad TCP/IP DROP: " 

-A LOGACTTCP -j DROP 

-A PREROUTING -p tcp -m tcp --tcp-flags ACK,URG URG -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,ACK FIN -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags PSH,ACK PSH -j LOGACTTCP 

-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOGACTTCP 

COMMIT

# Completed on Wed Jun  6 08:44:56 2007

# Generated by iptables-save v1.3.0 on Wed Jun  6 08:44:56 2007

*filter

:FORWARD DROP [0:0]

:INPUT DROP [0:0]

:OUTPUT DROP [0:0]

-A FORWARD -j LOG --log-prefix "Default DROP (FORWARD): " 

-A FORWARD -j DROP 

-A INPUT -i lo -j ACCEPT 

-A INPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j LOG --log-prefix "Scan attempt? " 

-A INPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j DROP 

-A INPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m conntrack --ctstate INVALID -j LOG --log-prefix "Not New/Established " 

-A INPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m conntrack --ctstate INVALID -j DROP 

-A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset 

-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 4/sec --limit-burst 9 -j ACCEPT 

-A INPUT -p icmp -m icmp --icmp-type 8 -j LOG --log-prefix "Ping abuse " 

-A INPUT -p icmp -m icmp --icmp-type 8 -j DROP 

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT 

-A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset 

-A INPUT -p tcp -m multiport --dports 25,465,587 -m state --state NEW -j ACCEPT 

-A INPUT -p tcp -m tcp --dport 10000 -m state --state NEW -j ACCEPT 

-A INPUT -j LOG --log-prefix "Default DROP (INPUT): " 

-A INPUT -j DROP 

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

-A OUTPUT -o lo -j ACCEPT 

-A OUTPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 9/sec --limit-burst 15 -j ACCEPT 

-A OUTPUT -p icmp -m icmp --icmp-type 8 -j LOG --log-prefix "Ping abuse from us " 

-A OUTPUT -p icmp -m icmp --icmp-type 8 -j DROP 

-A OUTPUT -p icmp -m icmp --icmp-type any -j ACCEPT 

-A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT 

-A OUTPUT -p tcp -m multiport --dports 25,465,587 -m state --state NEW -j ACCEPT 

-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT 

-A OUTPUT -p tcp -m multiport --dports 389,636 -m state --state NEW -j ACCEPT 

-A OUTPUT -j LOG --log-prefix "Default DROP (OUTPUT): " 

-A OUTPUT -j DROP 

COMMIT

# Completed on Wed Jun  6 08:44:56 2007

```

----------

## Hu

Those rules look OK.  Since all the packets are FIN-ACK, I would guess that the connection ceased to exist around the time the incoming FIN started connection teardown, so now no connection exists to let those FIN-ACK packets match the ESTABLISHED qualifier.  What is the output of emerge --info?  I mainly want to see your kernel version, but getting a general feel for the age of this system would be good too.

----------

## jcpunk

High, I am running a stock 2.6.17 kernel, the box is about a year old, my predecessor didn't want to be bothered with fire walling things himself.  He moved on to a better job, I got his....

Regarding connection tear downs read up on the IP Sysctl entries and added this to my sysctl.conf

net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=0

net.ipv4.netfilter.ip_conntrack_udp_timeout = 20

net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 95

net.ipv4.netfilter.ip_conntrack_generic_timeout=650

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=20

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=180

applied the changes but the changes and verified it was right in /proc/ but things continue on this way....

I am seeing similar problems with the input chain where stuff is being caught by conntrack but looks like it should be getting in to finish off closing the connection.  I could technically add a rule letting the FIN/ACK out, but I don't want to do that for letting stuff in because that seems to defeat the point of having a stateful firewall at all....

Any guesses as to anything else I should look at / poke with stick?

----------

## erik258

In my opinion, you might be able to save yourself some gray hairs by getting rid of the stateful filtering on ports to which, assumedly, you always want to accept traffic.  For example, you accept new connections to port 25, and existing connections to port 25, so what connections do you not want to accept from port 25?  

I have my firewall set up so that traffic going to ssh, web, email, etc.  servers is automatically accepted.  I still use stateful firewall to accept established connections' traffic on dynamically associated ports, but leave all the ports on which I have services listening wide open.

----------

## jcpunk

You raise a valid point.  The main reason I am trying to get stateful filtering up on this box is primarily because it is a mail server.  It is well protected in postfix to protect it from being used as a spam gateway, but I am trying to do my best to be a good neighbor.  So in terms of what connections I don't want, I don't want people who seem to be screwing around to even see that port 25 will listen to them.  If I haven't done everything I can to combat spam on my end, I cannot hold any other site to that standard.

----------

## erik258

 *Quote:*   

> If I haven't done everything I can to combat spam on my end, I cannot hold any other site to that standard.

 

I agree, but...

 *Quote:*   

> I don't want people who seem to be screwing around to even see that port 25 will listen to them.

 

I don't think stateful firewalling in iptables has the ability to filter out packets from 'people who seem to be screwing around' from packets belonging to a legitimate email transaction. 

 *Quote:*   

> It is well protected in postfix to protect it from being used as a spam gateway, but I am trying to do my best to be a good neighbor.

 

Yes, as you say, postfix's default configuration disables relaying mail from unauthorized sources to destinations not in $my_destination.  It actually has a lot of anti-spamming features additionally, like sender address verification (use with caution!) and such.  There are also a number of online databases that make updated blacklists available freely, especially to noncommercial or small email servers.  Additionally, you can use spam assassin with various modules and rules-du-jour to catch most of the spam coming into your server (which would hopefully mean that it's mail for you or one of your users!)  and stop its spread.

----------

## jcpunk

 *Quote:*   

> I don't think stateful firewalling in iptables has the ability to filter out packets from 'people who seem to be screwing around' from packets belonging to a legitimate email transaction. 

 

It doesn't exactly, but it adds one layer to the mix that was not otherwise present.  I cannot stop people from spoofing their IPs but I can (with the stateful rules plus reject_unauth_pipelining in postfix) disconnect any session that messes around with the protocol.  Additionally, since most everything is done over tls (RFC says not to enforce tls only) this is further protected.  But only about 40% of the sites my mailserver connects to are tls enabled....  The stateful rules ensure that the packets all belong to the session that was established (or at least appear to).  Postfix ensures that the established session isn't violating the rules of mail protocol.  The two of them together should be a very powerful combination.  

This may not be a 100% solution, but again If I haven't done everything I can, no matter how little it helps...  Spam is too big a problem to be treated with anything other than my greatest respect.  If I can get this to work, I can share it; if I share it, it should help at least some people fight spam on their end.

Additionally a great postfix anti spam source is hosted by the postfix folks themselves : http://www.postfix.org/uce.html

This thread seems to have strayed from its original topic....

----------

