Hello,

Please excuse me if this has already been covered, but I have had a persistent problem with a CentOS 5.x box for over a year now.

Using any random ftp client, I sometimes get what looks like a machine breakdown. The FTP session dies. No other FTP session can be started. Restarting the FTP daemon did nothing.

I used to reboot the box to get the FTP working again, but one day I checked to see if SSH was still working (it was) so I then realized that maybe it wasn't the FTP server but something interfering with the FTP server.

This led me to trying turning off IPTABLES, which led to the FTP server working again.

So I have now determined that somehow IPTABLES has a problem with vsFTPd, but the problem appears to happen randomly.

Can anyone help me to understand why this would happen and what I can do to fix it?

Is it THIS RULE that's causing my grief? What adjustment should I make to it?

4 blockip all -- 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 30 hit_count: 5 name: STOPFTP side: source


Here's the stats on the machine versions:

- CentOS release 5.7 (Final)
- vsFTPd 2.0.5

Here's the IPTABLES:

Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 stopattacks all -- 0.0.0.0/0 0.0.0.0/0
2 common all -- 0.0.0.0/0 0.0.0.0/0
3 global all -- 0.0.0.0/0 0.0.0.0/0
4 blackhole all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)
num target prot opt source destination

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

Chain blackhole (1 references)
num target prot opt source destination
1 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
2 REJECT udp -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
3 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable

Chain blockip (2 references)
num target prot opt source destination
1 all -- 0.0.0.0/0 0.0.0.0/0 recent: SET name: BLOCKIP side: source

Chain common (1 references)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 logdrop all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain global (1 references)
num target prot opt source destination
1 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
6 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
7 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:161
8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
9 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3690
10 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000

Chain logdrop (2 references)
num target prot opt source destination
1 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FIREWALL: '
2 DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain stopattacks (1 references)
num target prot opt source destination
1 tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: STOPSSH side: source
2 tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW recent: SET name: STOPFTP side: source
3 blockip all -- 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 30 hit_count: 5 name: STOPSSH side: source
4 blockip all -- 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 30 hit_count: 5 name: STOPFTP side: source
5 logdrop all -- 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 3600 hit_count: 1 name: BLOCKIP side: source

Thank you,

Graham Leach
----

Perhaps you should use something like fail2ban instead of crude iptables recent check to limit brute force attacks?

Some logging rules can help to debug possible iptables problems:

/sbin/iptables -A INPUT -m limit --limit 15/minute -j LOG \
--log-level 7 --log-prefix "Dropped by firewall: "
/sbin/iptables -A OUTPUT -m limit --limit 15/minute -j LOG \
--log-level 7 --log-prefix "Dropped by firewall: "

then watch your logs.