# Iptables and FTP ports [SOLVED]

## isilia

Hello, I set up an FTP server, which works fine with my firewall off. It also works fine when I execute the following commands:

```
Gentoo iptables # /etc/init.d/iptables stop 

iptables           | * Saving iptables state ...                          [ ok ]

iptables           | * Stopping firewall ...                              [ ok ]

Gentoo iptables # iptables-restore /storage/Documents/iptables

Gentoo iptables # /etc/init.d/iptables save

iptables           | * Saving iptables state ...                          [ ok ]

Gentoo iptables # /etc/init.d/iptables start

iptables           | * Loading iptables state and starting firewall ...   [ ok ]
```

/var/lib/iptables/rules-save now looks exactly the same as /storage/Documents/iptables:

```
# Generated by iptables-save v1.4.0 on Thu Sep 18 14:57:00 2008

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [22:1520]

[20:2392] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

[0:0] -A INPUT -s 127.0.0.1/32 -j ACCEPT

[0:0] -A INPUT -s 192.168.1.101/32 -j ACCEPT

[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT

[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT

[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

[0:0] -A INPUT -j REJECT --reject-with icmp-port-unreachable

COMMIT

# Completed on Thu Sep 18 14:57:00 2008
```

This configuration works, but then the weirdness starts. After I stop iptables, /var/lib/iptables/rules-save looks like:

```
# Generated by iptables-save v1.4.0 on Thu Sep 18 14:59:51 2008

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [99:7320]

[93:11842] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

[0:0] -A INPUT -s 127.0.0.1/32 -j ACCEPT

[0:0] -A INPUT -s 192.168.1.101/32 -j ACCEPT

[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT

[1:60] -A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT

[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

[2:120] -A INPUT -j REJECT --reject-with icmp-port-unreachable

COMMIT

# Completed on Thu Sep 18 14:59:51 2008
```

The numbers in front of the rules changed, I've tried googling to find out what they do, but as I have no idea what they are called or what they do so I couldn't find anything. If I change the [1:60] bit back to [0:0], everything works fine again until I restart iptables. To clarify, all this is only applies to remote connections (over the internet).

So my questions are, what do these numbers mean (something security like I suppose?) and why does iptables change them?Last edited by isilia on Sat Sep 20, 2008 10:37 am; edited 1 time in total

----------

## Kattsand

it looks like your iptables have ACCEPT on all 3 chains which basically have the same effect like a system without a firewall.

a more proper approach would be (depends on the setup and usage of the server ofc but this is a very generic setup):

# drop incoming packets if no matches in your INPUT chain for the packet.

iptables -P INPUT DROP

# accept all outgoing

iptables -P OUTPUT ACCEPT 

# depends on your needs, accept if you want forwarding. 

iptables -P FORWARD DROP

(drop or reject.. up 2 you to decide.)Last edited by Kattsand on Thu Sep 18, 2008 1:36 pm; edited 1 time in total

----------

## isilia

Hi, doesn't this line take care of that?

 *Quote:*   

>  [6:360] -A INPUT -j REJECT --reject-with icmp-port-unreachable 

 

I'm pretty sure it does as I can't connect to any of the other ports than the ones I specified.

----------

## Kattsand

I honestly didnt pay attention too that last chain rule, will try it out myself when I come home in an hour  :Smile: 

About the numbers.. found this FAQ: http://www.faqs.org/docs/iptables/iptables-save.html

"A chain specification looks like :<chain-name> <chain-policy> [<packet-counter>:<byte-counter>]. "

So OUTPUT ACCEPT [22:1520] must mean 22 packets and 1520 bytes (recieved).

----------

## isilia

Looks like your google skills are better than mine! I assume that 0.0 means infinite packages and infinite bytes? I tried changing the numbers to something very large (I bet it's stupid but I'm no expert on networking), which still has iptables show the same behaviour as with 0.0.

I double checked my kernel's configuration as well, it's the same as specified in the gentoo wiki here:

http://gentoo-wiki.com/HOWTO_Iptables_for_newbies#Enable_Kernel_Support (2.6.22 version)

----------

## isilia

I replaced these lines:

```
[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT

[1:60] -A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT

[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
```

with:

```
[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 20:22 -j ACCEPT
```

So, now the packages and bytes stay 0:0 for port 21, but it still isn't working. 

I have no idea what else to blame though as everything works perfectly without iptables running.

----------

## isilia

Even more weirdness! My friend can connect using ftp (the program, on the CLI). But no one else can, all using graphical browsers (firefox, IE). Keep in mind everyone can connect when I turn the firewall off though. O.o

----------

## Hu

As Kattsand mentioned, the bracketed pair of numbers at the beginning tells you how many packets and bytes have matched the rule.  It does not in any way affect whether the rule matches, so changing the values is meaningless.  0:0 means nothing has matched the rule yet.

If everything works when your firewall is down, that means your rules are blocking needed traffic.  Use net-analyzer/tcpdump to collect a packet capture of the traffic that fails, so that you can write a rule to allow it.

The ftp behavior is perfectly normal, and reflects the fact that the CLI ftp defaults to active mode, whereas most modern browsers use passive mode.  Active mode is a leftover from an earlier era, and tends to conflict with modern firewalls.  Stateless firewalls are especially prone to breaking active FTP, but some stateful firewalls also interfere.  Thus, modern clients use passive mode to avoid those problems.  As it happens, your firewall rules are breaking incoming ftp data connections, so only clients using the legacy active mode ftp are functional.

----------

## isilia

Thanks both of you for your replies!

Looks like kernel trouble after all, I had to modprobe ip_conntrack_ftp! (I do have module autoloading on..)

Also, my iptables config looks like this:

```
# Generated by iptables-save v1.4.0 on Fri Sep 19 15:13:12 2008

*filter

:INPUT DROP [744:54125]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [597779:151505822]

[163277:70281216] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

[14:840] -A INPUT -s 127.0.0.1/32 -j ACCEPT

[129:7740] -A INPUT -s 192.168.1.101/32 -j ACCEPT

[88:4864] -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

[2:120] -A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT

COMMIT

# Completed on Fri Sep 19 15:13:12 2008

```

Is this any good security wise?

----------

## Hu

You should use -i lo instead of -s 127.0.0.1/32 to detect loopback connections.

I would require the traffic for 192.168.1.101 to enter on the internal interface.  External traffic can be sent to an RFC 1918 reserved address, and many ISPs will incorrectly allow it to pass.

----------

## isilia

Hi, thanks for your input. Will add the solved tag now.

----------

