Debian – incoming ACCEPT all iptables rule still appearing

debianiptables

I'm following this guide here: http://isalazyadmin.net/2009/07/02/configuring-a-basic-firewall-for-debian-linux/

And I have the iptables listed shown, but my server still appears to be accepting all incoming connections (ie: bittorrent peers are still connecting, even though I didn't allow those ports).

/etc/iptables.rules

*filter

# This will allow all loopback (lo0) traffic and drop all traffic to 127/8
# that does not use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

#  This accepts all already established connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# This allows all outbound traffic
-A OUTPUT -j ACCEPT

# This will allow HTTP and HTTPS connections from anywhere, this are the normal
# ports used for a web server
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow SSH connections
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow bittorrent/rtorrent ports, from ~/.rtorrent.rc
## -A INPUT -p tcp --dport 8071:8079 -j ACCEPT


# Allow ICMP ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# Reject all other inbound traffic
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

When I run iptables -L after a reboot, I still get this as my first rule:

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

Not sure where this is coming from.

Here is the full list:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             loopback/8          reject-with icmp-port-unreachable 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

Here is the output of iptables-save:

# Generated by iptables-save v1.4.8 on Fri Jan 11 09:54:19 2013
*raw
:PREROUTING ACCEPT [6701:942626]
:OUTPUT ACCEPT [8927:989420]
COMMIT
# Completed on Fri Jan 11 09:54:19 2013
# Generated by iptables-save v1.4.8 on Fri Jan 11 09:54:19 2013
*nat
:PREROUTING ACCEPT [3281:284415]
:INPUT ACCEPT [9:720]
:OUTPUT ACCEPT [1758:148908]
:POSTROUTING ACCEPT [1758:148908]
COMMIT
# Completed on Fri Jan 11 09:54:19 2013
# Generated by iptables-save v1.4.8 on Fri Jan 11 09:54:19 2013
*mangle
:PREROUTING ACCEPT [6701:942626]
:INPUT ACCEPT [6701:942626]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [8928:989684]
:POSTROUTING ACCEPT [8928:989684]
COMMIT
# Completed on Fri Jan 11 09:54:19 2013
# Generated by iptables-save v1.4.8 on Fri Jan 11 09:54:19 2013
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -j REJECT --reject-with icmp-port-unreachable 
-A OUTPUT -j ACCEPT 
COMMIT
# Completed on Fri Jan 11 09:54:19 2013

Here is the iptables -vL output:

$ sudo iptables -vL
[sudo] password for ettinger: 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 8303 1206K ACCEPT     all  --  lo     any     anywhere             anywhere            
    0     0 REJECT     all  --  !lo    any     anywhere             loopback/8          reject-with icmp-port-unreachable 
  12M 7191M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
   18   980 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:www 
    7   344 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:https 
  379 22728 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh 
18316 1110K ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpts:8071:8079 
 120K   15M ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:6881 
24809 1489K ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:9001 
  688 35244 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:9030 
  874 73072 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp echo-request 
12705  871K REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-port-unreachable 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  14M   12G ACCEPT     all  --  any    any     anywhere             anywhere

Best Answer

The line you are worried about:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

is actually because of this in your rules:

-A INPUT -i lo -j ACCEPT

Notice the interface is explicit in the rule, but not in the -L output. Move that rule to the middle of the list, use iptables-restore and notice the "ACCEPT all -- anywhere" has moved down too. Now try changing the rule a bit:

-A INPUT -i lo -s 127.0.0.1 -j ACCEPT

and the -L output will become:

target     prot opt source                 destination  
ACCEPT     all  --  localhost.localdomain  anywhere

"localhost.localdomain" will be your 127.0.0.1 hostname from /etc/hosts. This at least makes it clearer where that rule came from.

You can also see more detailed information including the interfaces with iptables -vL.

BTW, you may want to start your rules:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

Drop everything by default as a fall through for safety. This is considered bad manners, however (see the link in Gilles comment below), so you may want to create a final catch all for each table which uses -j REJECT --reject-with icmp-net-prohibited.

Related Solutions

Iptables: Matching Outgoing Traffic with Conntrack and Owner – Troubleshooting Drops

To cut a long story short, that ACK was sent when the socket didn't belong to anybody. Instead of allowing packets that pertain to a socket that belongs to user x, allow packets that pertain to a connection that was initiated by a socket from user x.

The longer story.

To understand the issue, it helps to understand how wget and HTTP requests work in general.

wget http://cachefly.cachefly.net/10mb.test

wget establishes a TCP connection to cachefly.cachefly.net, and once established sends a request in the HTTP protocol that says: "Please send me the content of /10mb.test (GET /10mb.test HTTP/1.1) and by the way, could you please not close the connection after you're done (Connection: Keep-alive). The reason it does that is because in case the server replies with a redirection for a URL on the same IP address, it can reuse the connection.

Now the server can reply with either, "here comes the data you requested, beware it's 10MB large (Content-Length: 10485760), and yes OK, I'll leave the connection open". Or if it doesn't know the size of the data, "Here's the data, sorry I can't leave the connection open but I'll tell when you can stop downloading the data by closing my end of the connection".

In the URL above, we're in the first case.

So, as soon as wget has obtained the headers for the response, it knows its job is done once it has downloaded 10MB of data.

Basically, what wget does is read the data until 10MB have been received and exit. But at that point, there's more to be done. What about the server? It's been told to leave the connection open.

Before exiting, wget closes (close system call) the file descriptor for the socket. Upon, the close, the system finishes acknowledging the data sent by the server and sends a FIN to say: "I won't be sending any more data". At that point close returns and wget exits. There is no socket associated to the TCP connection anymore (at least not one owned by any user). However it's not finished yet. Upon receiving that FIN, the HTTP server sees end-of-file when reading the next request from the client. In HTTP, that means "no more request, I'll close my end". So it sends its FIN as well, to say, "I won't be sending anything either, that connection is going away".

Upon receiving that FIN, the client sends a "ACK". But, at that point, wget is long gone, so that ACK is not from any user. Which is why it is blocked by your firewall. Because the server doesn't receive the ACK, it's going to send the FIN over and over until it gives up and you'll see more dropped ACKs. That also means that by dropping those ACKs, you're needlessly using resources of the server (which needs to maintain a socket in the LAST-ACK state) for quite some time.

The behavior would have been different if the client had not requested "Keep-alive" or the server had not replied with "Keep-alive".

As already mentioned, if you're using the connection tracker, what you want to do is let every packet in the ESTABLISHED and RELATED states through and only worry about NEW packets.

If you allow NEW packets from user x but not packets from user y, then other packets for established connections by user x will go through, and because there can't be established connections by user y (since we're blocking the NEW packets that would establish the connection), there will not be any packet for user y connections going through.

Best Answer

Related Solutions

Iptables: Matching Outgoing Traffic with Conntrack and Owner – Troubleshooting Drops

Related Question