POP3 attack on server leads to table crash and DB restore

[aegersz]

this is the second time that I have been attacked and plan some iptables approach.

but I wanted to run this past you as I saw a memory stack message from SMF (in the browse but may not be SMF)

I have since shutdown redundant tasks to free up memory as I only have 1 GB.

I just wondered if memory was the cause of my table crash.

what do you guys think ? can memory issues ultimately cause database corruption ?

any advice on POP3 attacks is welcome too.

[LiroyvH]

What kind of attacks? Details.

Memory issues can cause database corruption, sure. Especially if the mySQL process is killed off by the kernel ("OOM Killer"), for example.
1GB is tight.

[aegersz]

i have been shutting down redundant services and tightening up on my firewall.

i'm testing some anti-POP3-attack firewall rules out currently ... this may go quiet for a while.

[6TiME6]

You can limit the SYNs to your POP3 port with the iptables recent module to like 10 per minute per source IP. If that doesn't help, you can use fail2ban if what you're experiencing is a bruteforce attack (I assume it is, there are lots of them on plain POP3).

The most drastic option would be to disable plain POP3 and only use POP3S, if you have to use POP3 at all (IMAP anyone?).

[aegersz]

I have been reconfiguring my firewall to stop this.

I also added a swap file and shut down redundant tasks to take the pressure off memory.

I am aware of fail2ban and run it for ssh.

thanks for your help ... I'm on it and now waiting for something I hope won't happen again.
I

[6TiME6]

Thanks for the update, that's good news. If you already use fail2ban for SSH, you can simply enable the jail for your Dovecot or whatever you use for POP3 in /etc/fail2ban/jail.conf (or enable it in /etc/fail2ban/jail.local which is the "new way" with more recent fail2ban versions). If you should still experience similar issues in the future, here are some iptables rules for you that would limit new connections to 10 per minute per source IP, which should mitigate the problem in addition to fail2ban.

Code Select Expand

iptables -A INPUT -p tcp --dport 110 -m conntrack --ctstate NEW -m recent --set
iptables -A INPUT -p tcp --dport 110 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

[aegersz]

i took the following from https://www.thatsgeeky.com/2011/01/limiting-brute-force-attacks-with-iptables/ and implemented it. i feel it goes further than your example and it covers some additional port. but THANK YOU for suggesting another option for me:

:ATTACKED - [0:0]
:ATTK_CHECK - [0:0]

-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 21,22,110,143,993,995 -m recent --update --seconds 3600 --name BANNED --rsource -j DROP
-A INPUT -p tcp -m multiport --dports 21,22,110,143,993,995 -m state --state NEW -j ATTK_CHECK

#OTHER PRE-EXISTING RULES
#...

-A ATTACKED -m limit --limit 5/min -j LOG --log-prefix "IPTABLES (Rule ATTACKED): " --log-level 7
-A ATTACKED -m recent --set --name BANNED --rsource -j DROP
-A ATTK_CHECK -m recent --set --name ATTK –-rsource
-A ATTK_CHECK -m recent --update --seconds 600 --hitcount 16 --name ATTK --rsource -j ATTACKED
-A ATTK_CHECK -m recent --update --seconds 60 --hitcount 6 --name ATTK --rsource -j ATTACKED
-A ATTK_CHECK -j ACCEPT

i will leave fail2ban out for now to avoid banning machines that have been compromised because they may be ok in the furture.

[LiroyvH]

i will leave fail2ban out for now to avoid banning machines that have been compromised because they may be ok in the furture.

Then purge it later. I think fail2ban can also ban IP's for x amount of time...
Blocking brute-force attacks is really a rather good idea... Though stuff like fail2ban can present a security issue of its own, at least: on shared servers. Implementing something like it is usually absolutely recommended.

[青山 素子]

I think fail2ban can also ban IP's for x amount of time...

It does. The default configuration is a time-limited ban.

[aegersz]

will a mass mailout trigger unwanted banning with the iptables I set in play ?

I need to send about 5000 mail items.

[LiroyvH]

From a really quick glance: no it shouldn't, because it's looking at destination ports; not source.

[6TiME6]

Your iptables rules use the outdated "state" module, which has been replaced by "ctstate". Also the limits are a bit too strict imo if you use POP3 clients that frequently check for e-mails. Also it covers POP3S ports as well, where you shouldn't receive any bruteforce attacks to anyway. No matter which iptables ruleset you decide to use, you should also use fail2ban in addition, because botnets that consist of a larger number of infected hosts could still crash your mail server. The bans will expire fairly quickly, so you really don't have to worry about banning servers that could later get cleaned up. Most are HiChina IPs anyway and I don't think I've ever seen a legit mail from their network.

[aegersz]

I will look into fail2ban. thank you.

[aegersz]

Your iptables rules use the outdated "state" module, which has been replaced by "ctstate". Also the limits are a bit too strict imo if you use POP3 clients that frequently check for e-mails.

Also it covers POP3S ports as well, where you shouldn't receive any bruteforce attacks to anyway. No matter which iptables ruleset you decide to use, you should also use fail2ban in addition, because botnets that consist of a larger number of infected hosts could still crash your mail server.

The bans will expire fairly quickly, so you really don't have to worry about banning servers that could later get cleaned up. Most are HiChina IPs anyway and I don't think I've ever seen a legit mail from their network.

1. ... but can i leave my iptables the way they are for now if i seldom use mail ?

2. I did implement fail2ban for dovecot, as you suggested and config'ed straight from wiki.\

thanks for making me finally tighten things up even more. marking as solved until the next attack happens, which i expect to never know about it because everything functioned so well

[aegersz]

in case anybody is interested in my Postfix tighten-up, i added the following to /etc/postfix/main.cf:

disable_vrfy_command = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
     reject_non_fqdn_hostname,
     reject_invalid_hostname,
     permit
smtpd_error_sleep_time = 1s
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20