automatic banning

[jln]

Hi everyone,

I have a concern about brute force. My server is up 24/7 (I try) and it's
protected in ipv4 by fail2ban. But, fail2ban is not working in ipv6.
Chinese's seem very aggressive nowadays and I won't let my server
that vulnerable to a brute force attack.
So, I am seeking something like fail2ban working with ipv6.
Any suggestion?

Thank you.

Jean-Louis

[cholzhauer]

Are you using it for Apache or just your system in general?  Denyhosts works well for SSH and I thought it could be configured to monitor other services.

[jln]

For everything!
SSH, telnet, SMTP, POP, Phones, ...

[jln]

I know, SMTP risks almost nothing in ipv6 ;D
But, port 587 is open!

[kasperd]

So, I am seeking something like fail2ban working with ipv6.

I don't know specific software to suggest, but I can point out some of the design requirements for such software. Knowing this is important in order to evaluate any solutions.

An important challenge is the wide range of possible prefix sizes an attacker could have access to. An attacker with access to an entire /32 range is not the most common scenario, but it is certainly possible. A lot of /32s have been handed out already, it only takes one of them having an administrator with shady intentions, or simply a network configured in such a way that customers/users effectively have access to use addresses from all over the /32 allocated to the ISP. OTOH there may also be attacks with access to just a single IPv6 address where the neighboring IPv6 address belongs to a legitimate user.

A working solution need to be able to apply meaningful throttling if an attacker jumps all over a /32. Meanwhile an attacker with only a /128 must not be able to perform a DoS attack against legitimate users on the same /124.

The solution thus must be something, which applies different blocking thresholds for different prefix lengths. Thresholds that are exponential in the prefix length could give a way too high threshold for a /32. OTOH linear thresholds could end up in a situation, where it takes just two /64s to cause blocking of a /32.

One example strategy could be that a /128 gets to do 2 attempts before blocking happens, a /127 gets to do 4 attempts, a /126 gets 6 attempts, etc. A /64 would then be permitted 130 attempts and a /32 would be permitted 194 attempts. But two /64s using their 130 attempts each would then be more than enough to use the 194 attempts quota for the /32. In fact extrapolating this linear strategy would mean two /64s would hit the quota for 2000::/3 before they each had used their quota.

A better strategy could be to use a slower linear growth from /128 through /64 and quadratic growth for prefixes shorter than that. For example a /128 gets 2 attempts, a /127 gets 3, etc. with a /64 getting 66 attempts. Then you start adding increasing numbers such that a /63 gets 66+2 attempts, a /62 gets 66+2+3 attempts, etc. and a /32 gets 66+2+3+...+33 = 626 attempts before you block the entire /32.

SSH, telnet, SMTP, POP, Phones, ...

What are you trying to protect against? Software vulnerabilities or password brute forcing?

Many software vulnerabilities can be exploited using only a single connection, so you'd be compromised before even realizing you were under attack. For such cases keeping software updated is the way to go, blocking failed logins will do you no good.

Protecting against password brute force is something for which rate limiting does help. But enforcing stronger passwords may be a more useful solution. With ssh you can even disable password authentication completely. I usually configure sshd to only accept public key authentication.

[jln]

> What are you trying to protect against? Software vulnerabilities or password brute forcing?

Password brute force attacks.
I'll fix software vulnerabilities!
They are trying to be root really!
And if you let them trying for ages they could succeed!

[jhanson]

You could write a perl script to scan the logs yourself and insert the rules into iptables.

[jln]

> I usually configure sshd to only accept public key authentication.
Yes, that helped very much!
Almost nothing this morning thanks.

It leads at some disappointment:
==========
Mar 31 02:20:37 ns sshd[14716]: Invalid user shit from 66.11.12.129
Mar 31 02:20:37 ns sshd[14716]: input_userauth_request: invalid user shit [preauth]
Mar 31 02:20:37 ns sshd[14716]: Received disconnect from 66.11.12.129: 11: Bye Bye [preauth]
==========
;D

Bye,
Jean-Louis

[sebastiannielsen]

Another good idea is to configure administrative services to be behind a firewall, which does only allow administrative tasks over a VPN, or only originate from approved IP adresses.

Eg, instead of banning bad hosts, you only approve the good hosts.

And if the locations you are using for administrative tasks are dynamic, it can be a good idea to put the whole subnet in whitelist. That would still cut down attacks since only users from the same ISP as your administrative locations, are allowed to connect at all.

I would never expose administrative ports (SSH, FTP, POP3, IMAP, Telnet) to the whole internet. It just like being asked for being bruteforced.

Only ports that should be "visible" to the internet is:
SMTP (Incoming mail) - configure it to only allow mail to your domain from "unknown" hosts - eg do NOT accept authentication at all.
HTTP - Of course, a website. A good thing with HTTP is that you can hide administrative tasks behind a login which uses a CAPTCHA, and behind a hidden URL, so your login form will experience no bruteforce at all.
In HTTP, you can use webmail, web-SSH, web-upload (FTP) and such to do administrative tasks.
HTTPS - Same as HTTP
DNS - Of course so clients can do DNS lookups.

Thats the only types of services that your hosts needs to provide to the whole internet for they to have any meaningful usage.


The bad things with "native" protocols like POP3, IMAP, FTP, SSH and such, is that they do not support CAPTCHA.
By "webifying" these protocols, running them all as web services (webmail-IMAP, web-FTP, web-SSH), you can protect logins with a captcha.

Another great solution is to have a webpage, where you have to enter your username, password and captcha. This then temporarly opens the firewall at ports 21 (FTP), 22 (SSH), 110 (POP3) and 143 (IMAP), for the source IP you are coming from. Thus, it will not be possible to bruteforce if your bruteforcer cannot solve captchas, which will atleast cut down on all automatic attacks.

[hvdkooij]

I would never expose administrative ports (SSH, FTP, POP3, IMAP, Telnet) to the whole internet. It just like being asked for being bruteforced.

IMAP/POP3 is never admin traffic. It's users with email accounts.

So you must block them very selectively.

[kcochran]

Captcha's are not a silver bullet.  They're useful in certain cases, and only until the mechanism remains unbroken.  If you really want to lock things down, create a local CA, and issue user certs from that, and require those for login where applicable.

[n2xu]

I have NOT tried using IPv6 only but IPSET works great on IPv4 and I think it's supported on IPv6.  I wrote up an article titled self-blocking script kiddies... You should be able to find it through google.  It basically works by adding IPs to a "set" and the set is in my rules...  I'll do some experimentation on the IPv6 side an see if it works...

I recently started using the xtables-addons module to block ipv4 by country code, I'm pretty sure there's support there for IPv6 too.  I guess I should try and see if I can build some rules for IPv6, but I haven't seen ANY inbound IPv6 SSH brute force traffic in my logs... Considering how large the address space is for s /64 they haven't yet tried to brute force my IPv6, but security by obscurity isn't the best practice.

[snarked]

IPset and xtables both work for IPv6 if one has the latest versions of these tools.

Scanning a /64 for an open SSH port is too resource intensive.  What is more likely is that hackers will scan for an "ssh" label in the DNS and see if an AAAA record is returned.  Regardless, my defaults for trying the SSH port (TCP SYN packet) is a TCP tarpit, and the way to avoid that is:  1)  The source IP must be within my assigned subnet(s), or 2)  The appropriate resource-knocking sequence is followed so as to place the source IP into an iptables "recent" list (with a timeout value of 30-90 seconds).  Note also that a second knock within another reasonable time period will REMOVE the source IP from the SSH-access recent list (in the event that someone is randomly trying certain things, if they hit twice, it screws them), and thus send them to the tarpit.  Limiting a source IP from the SSH-recent list to a single session also helps.

I state "resource-knocking" because it can be any combination of TCP/UDP port sequences, ICMP packets, other IP packets, or even HTTP requests (as examples), and I am being intentionally ambiguous as to what I use for my collocated machines.

[sebastiannielsen]

.

As I said, you could have a web authentication solution, that temporarly opens a port in firewall.

Lets say you have a user with IMAP and SMTP send access on a rogue net over the internet. To protect the IMAP and SMTP authentication against bruteforce, you have a login form on webpage, like:
http://www.example.org/preauth.php

This page, will then require like username, password, maybe a 2FA token code, and a captcha, to login.

preauth.php then connects to your firewall through a WELL DEFINED interface, and opens the IMAP port in the firewall for the source IP that authenticated at preauth.php
It also notifyes the SMTP server to accept authentication and relaying from this source IP.
If you can limit this to one session, its a good idea, since then the port will auto-Close once the user is done.

With WELL DEFINED, I mean a interface so your firewall isnt exposed to additional security risks.
This can be accomplished by having a hardware firewall in front of your server, that hard-limits the ports to like 25, 53, 110, 443 etc.
Then you use a software firewall, like iptables on the server itself, to Control the opening of lets say port 110, to clients.
If the server firewall is malicious taken over by hacking the preauth.php script, the attacker wont be able to do more than open 110 to the whole World.

A good idea can also be to lock down any sensitive ports to a specific country, by geoIP, thus adding a additional security barrier, since those that dont come from the correct country, cannot connect to 110, not even if they pass preauth.php.

This system of authentication is often called a "reverse captive portal". (A captive portal is a web solution which opens port for a internal client to be able to access the internet. A reverse one is the reverse idea, where a web solution opens port for a external client to be able to access internal services)

Note that it will be cumbersome for your users to have to authenticate at a "reverse captive portal" Before gaining access to IMAP and POP3 and such services.
Thats why you should whitelist the IPs that your end users regularly use, for example home IP and work IP.