iptables not blocking banned IPs
iptables not blocking banned IPs
Hello, I recently started getting HTTP POST flood attack targeting one of my wordpress sites hosted under my VPS.
So I made a custom Jail to trap those bots under Fail2Ban, and it is working properly, please see here:
And in iptables it is also listed fine, please see here:
Yet, I see those bots still POST flooding that wordpress site at this very moment, please see here:
And the custom jail I wrote:
What am I doing wrong? Please help!
So I made a custom Jail to trap those bots under Fail2Ban, and it is working properly, please see here:
Code: Select all
[root@host ~]# fail2ban-client status wordpress
Status for the jail: wordpress
|- Filter
| |- Currently failed: 3
| |- Total failed: 84
| `- File list: /var/log/httpd/domains/xxxxxxxx.com.log
`- Actions
|- Currently banned: 7
|- Total banned: 7
`- Banned IP list: 176.31.14.116 178.32.12.119 188.165.118.37 37.59.184.179 46.105.161.64 94.23.164.171 94.23.165.148
Code: Select all
[root@host ~]# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
f2b-dovecot-pop3imap tcp -- anywhere anywhere multiport dports pop3,pop3s,imap,imaps,submission,urd,sieve
f2b-wordpress tcp -- anywhere anywhere multiport dports http,https
f2b-exim tcp -- anywhere anywhere multiport dports smtp,urd,submission
f2b-vsftpd tcp -- anywhere anywhere multiport dports ftp,ftp-data,ftps,ftps-data
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- host.xxxxxxxx.com anywhere
ACCEPT all -- localhost.localdomain anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere multiport dports http,https
ACCEPT tcp -- anywhere anywhere multiport dports ftp,entextxid:12100
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere multiport dports smtp,urd,submission,ms-v-worlds
ACCEPT tcp -- anywhere anywhere multiport dports pop3,pop3s
ACCEPT tcp -- anywhere anywhere multiport dports imap,imaps
DROP tcp -- anywhere anywhere multiport dports mysql,postgres
ACCEPT tcp -- anywhere anywhere tcp dpt:us-srv
ACCEPT icmp -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- anywhere anywhere tcp dpt:ssh
Chain f2b-dovecot (0 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain f2b-dovecot-pop3imap (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-exim (1 references)
target prot opt source destination
REJECT all -- 80.82.64.102 anywhere reject-with icmp-port-unreachable
REJECT all -- 219.255.177.16 anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere
Chain f2b-exim-spam (0 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain f2b-mysqld-auth (0 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-sshd (1 references)
target prot opt source destination
REJECT all -- mail.colorwind.net anywhere reject-with icmp-port-unreachable
REJECT all -- dictapartment.com anywhere reject-with icmp-port-unreachable
REJECT all -- 121.18.238.109 anywhere reject-with icmp-port-unreachable
REJECT all -- 119.249.54.68 anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere
Chain f2b-vsftpd (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-wordpress (1 references)
target prot opt source destination
REJECT all -- 94.23.165.148 anywhere reject-with icmp-port-unreachable
REJECT all -- 94.23.164.171 anywhere reject-with icmp-port-unreachable
REJECT all -- 46.105.161.64 anywhere reject-with icmp-port-unreachable
REJECT all -- 37.59.184.179 anywhere reject-with icmp-port-unreachable
REJECT all -- 188.165.118.37 anywhere reject-with icmp-port-unreachable
REJECT all -- 178.32.12.119 anywhere reject-with icmp-port-unreachable
REJECT all -- 176.31.14.116 anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere
Chain fail2ban-SSH (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain vesta (0 references)
target prot opt source destination
Code: Select all
37.59.184.179 - - [21/Oct/2016:12:37:52 +0000] "GET ...
176.31.14.116 - - [21/Oct/2016:12:37:55 +0000] "POST ...
178.32.12.119 - - [21/Oct/2016:12:38:15 +0000] "POST ...
178.32.12.119 - - [21/Oct/2016:12:38:17 +0000] "POST ...
94.23.165.148 - - [21/Oct/2016:12:38:21 +0000] "POST ...
178.32.12.119 - - [21/Oct/2016:12:38:22 +0000] "POST ...
46.105.161.64 - - [21/Oct/2016:12:38:30 +0000] "POST ...
94.23.164.171 - - [21/Oct/2016:12:38:36 +0000] "POST ...
94.23.164.171 - - [21/Oct/2016:12:38:38 +0000] "POST ...
176.31.14.116 - - [21/Oct/2016:12:38:41 +0000] "POST ...
178.32.12.119 - - [21/Oct/2016:12:39:01 +0000] "POST ...
94.23.165.148 - - [21/Oct/2016:12:39:14 +0000] "POST ...
208.43.68.59 - - [21/Oct/2016:12:39:21 +0000] "GET
Code: Select all
[wordpress]
enabled = true
port = http,https
filter = wordpress
findtime = 600
maxretry = 10
bantime = 86400
logpath = /var/log/httpd/domains/xxxxxxxx.com.log
-
- Support team
- Posts: 1096
- Joined: Sat Sep 06, 2014 9:58 pm
- Contact:
- Os: Debian 8x
- Web: apache + nginx
Re: iptables not blocking banned IPs
stupid question... but worth checking if IP tables is running ?
What OS are you on ?
Try rebooting your Server once... this will flush and reload IPTable Rules.
What OS are you on ?
Try rebooting your Server once... this will flush and reload IPTable Rules.
Re: iptables not blocking banned IPs
Yes, iptables is running.
I usually keep my SSH port disabled from VestaCP, and only enable it when I need server access. So I can confirm from that, iptables is up and running because it doesn't let me login without enabling SSH first.
I did a reboot, didn't help :(
I am running CentOS 6.7 x64.
I usually keep my SSH port disabled from VestaCP, and only enable it when I need server access. So I can confirm from that, iptables is up and running because it doesn't let me login without enabling SSH first.
I did a reboot, didn't help :(
I am running CentOS 6.7 x64.
-
- Support team
- Posts: 1096
- Joined: Sat Sep 06, 2014 9:58 pm
- Contact:
- Os: Debian 8x
- Web: apache + nginx
Re: iptables not blocking banned IPs
you can try manually
then
to see if it is there.
Then check if you still see traffic from that IP?
P.S. this won't survive a reboot, but worth a check.
My knowledge of CentOS is limited... but I remember SELinux can cause problems/conflicts. So try disabling it.
Code: Select all
iptables -A INPUT -s <IP> -j DROP
Code: Select all
http://www.cyberciti.biz/faq/linux-iptables-drop/
Then check if you still see traffic from that IP?
P.S. this won't survive a reboot, but worth a check.
My knowledge of CentOS is limited... but I remember SELinux can cause problems/conflicts. So try disabling it.
Re: iptables not blocking banned IPs
Okay, I figured out the issue...
As I mentioned above, I keep my SSH port disabled from VestaCP, and only enable it when I need server access. And after I am done, I again disable it... this is the issue. It seems VestaCP is resetting iptables rules as soon as I click "suspend" for SSH port.
iptables rules before clicking "suspend":
And iptables rules after clicking "suspend":
^ see the rules before "fail2ban-SSH" went missing.
Can this be filed as a bug or idea? so that VestaCP doesn't reset the rules?
Now that I didn't "suspend" anymore, it seems to be blocking those banned IPs :)
As I mentioned above, I keep my SSH port disabled from VestaCP, and only enable it when I need server access. And after I am done, I again disable it... this is the issue. It seems VestaCP is resetting iptables rules as soon as I click "suspend" for SSH port.
iptables rules before clicking "suspend":
Code: Select all
[root@host ~]# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
f2b-dovecot-pop3imap tcp -- anywhere anywhere multiport dports pop3,pop3s,imap,imaps,submission,urd,sieve
f2b-wordpress tcp -- anywhere anywhere multiport dports http,https
f2b-exim tcp -- anywhere anywhere multiport dports smtp,urd,submission
f2b-vsftpd tcp -- anywhere anywhere multiport dports ftp,ftp-data,ftps,ftps-data
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- host.vengeance2d.com anywhere
ACCEPT all -- localhost.localdomain anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere multiport dports http,https
ACCEPT tcp -- anywhere anywhere multiport dports ftp,entextxid:12100
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere multiport dports smtp,urd,submission,ms-v-worlds
ACCEPT tcp -- anywhere anywhere multiport dports pop3,pop3s
ACCEPT tcp -- anywhere anywhere multiport dports imap,imaps
DROP tcp -- anywhere anywhere multiport dports mysql,postgres
ACCEPT tcp -- anywhere anywhere tcp dpt:us-srv
ACCEPT icmp -- anywhere anywhere
Code: Select all
[root@host ~]# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- host.vengeance2d.com anywhere
ACCEPT all -- localhost.localdomain anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere multiport dports http,https
ACCEPT tcp -- anywhere anywhere multiport dports ftp,entextxid:12100
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere multiport dports smtp,urd,submission,ms-v-worlds
ACCEPT tcp -- anywhere anywhere multiport dports pop3,pop3s
ACCEPT tcp -- anywhere anywhere multiport dports imap,imaps
DROP tcp -- anywhere anywhere multiport dports mysql,postgres
ACCEPT tcp -- anywhere anywhere tcp dpt:us-srv
ACCEPT icmp -- anywhere anywhere
Can this be filed as a bug or idea? so that VestaCP doesn't reset the rules?
Now that I didn't "suspend" anymore, it seems to be blocking those banned IPs :)
-
- Support team
- Posts: 1096
- Joined: Sat Sep 06, 2014 9:58 pm
- Contact:
- Os: Debian 8x
- Web: apache + nginx
Re: iptables not blocking banned IPs
Nice Catch!
I never used a "suspend" on the firewall rules.
You usually either use "Accept" or "Drop".
file a bug on the bug tracker... I'm sure the devs will investigate and fix if anything.
As a temporary fix... you can set your SSH port to DROP rather than suspending... so that's equal to blocking Port 22. do post your observations
I never used a "suspend" on the firewall rules.
You usually either use "Accept" or "Drop".
file a bug on the bug tracker... I'm sure the devs will investigate and fix if anything.
As a temporary fix... you can set your SSH port to DROP rather than suspending... so that's equal to blocking Port 22. do post your observations
Re: iptables not blocking banned IPs
Really interesting find Syeef!
Let me suggest something else for SSH. Instead of enabling/disabling SSH port, you could configure SSH to only accept key-based authentication and drop all password authentication attempts. Key-based authentication is way far more secure than passwords and could drop 99,99% of all unauthorized attempts. It's virtually impossible to login without the key :)
If you're interested, have a look here. The you can completely disable password authentication by editing /etc/ssh/sshd_config and setting the line PasswordAuthentication no
Let me suggest something else for SSH. Instead of enabling/disabling SSH port, you could configure SSH to only accept key-based authentication and drop all password authentication attempts. Key-based authentication is way far more secure than passwords and could drop 99,99% of all unauthorized attempts. It's virtually impossible to login without the key :)
If you're interested, have a look here. The you can completely disable password authentication by editing /etc/ssh/sshd_config and setting the line PasswordAuthentication no