Stopping bruteforcing

[fisk]

I've got TONS of:

[Roguelazer]

Make a shell script that cron runs which parses the log file and bans repeat offenders? If you give me a few minutes, I'll come up with something in Ruby, but awk would probably be faster...
_________________
Registered Linux User #263260

[Shadus]

[fisk]

Hmm... can't I instead do something like this:

(I don't really know bash_scripts, I just took a few lines out of a firewall_script I run)

I take the ip.blacklist generated by ie. awk from the /var/log/messages and somehow:

[Roguelazer]

I just finished writing a ruby script that uses iptables and maintains a state list and can be run as a cron job. It also automatically removes blocked users after a set delay (30 days by default, but you can set it to 300 years if it so suits you), and does all sorts of other neat stuff. However, I'd like some people to test it privately before I post it to all the world. If you're interested, private message me here or e-mail me at Roguelazer.gmail@com (yes, fix the punctuation).
_________________
Registered Linux User #263260

[jamapii]

I have a lot of these log entries, too, but I'm not aware of any bruteforce attack. They never try more than 1 or 2 passwords per user, they try about 10 for root which probably rarely has ssh access.

The simplest way to counter more serious attacks would be to disable password authentication.

The defense of blocking IPs after a few failed attempts can be abused for a DOS attack.

"wc -l /usr/share/dict/words" says "234937" for me, and a single try uses 5-6 seconds, this makes 13.5 days for a complete dictionary attack - per user.

Blocking IPs after 1000 failed attempts makes a DOS attack take more than an hour per IP, and would't hit for the current attempts to find "guest" accounts. If they really try a bruteforce attack, and use a new IP for each try, they can save IP addresses this way, so you might want to calculate a good treshold from possible scenarios... Just using strong passwords will enhance your security in any case.

[Shadus]

[m.b.j.]

Currendly all this scripts do scanning over the logfiles, maybe the opensshd provides the ability to run scripts for evry n failed login?

If not it would be a nice feature request...
_________________
root@mbj # echo "sys-pizza/calzone -tunfish" >> /etc/paludis/use.conf
root@mbj # paludis -i calzone --dl-blocks discard

[bigfunkymo]

making a script that automagically bans ip addresses based on brute force attempts opens you up to the easiest denial of service attack ever. All someone has to do is spoof the source IP address to something like google.com and launch an attack that would appear to be a brute force attempt. Your script picks that up and bans google's IP and now you can no longer connect to google from that machine.

such a script or feature is a *VERY BAD IDEA*

configuring ssh to only allow certian users to connect and denying password-based authentication all together in favor of public key authentication are much better ideas.
_________________
[No package... Grabbing a set.]

[fisk]

Is there some simple way to let ie. IPTABLES to DROP a certain IP for an amount of time then? That way if the source-IP indeed is spoofed, you could just ban it for ... let's say 20 minutes, and then open it again...

so sort of like this:

1. User runs dictionary bruteforcing

2. After 5 failed attempts, the IP is temporarily banned

3. 20 minutes later the ban is removed

---

This would make it basically a lifetime effort to bruteforce a host.
_________________
-doh

[bigfunkymo]

not allowing passwords in the first place defeats 100% of brute force attempts
_________________
[No package... Grabbing a set.]

[fisk]

Yes, I hear the words, but I understand Jack and Sh** ... and Jack just left town.

How do I go about and configure that?

Also, does this still allow me to remotely connect from ie. servers at my school?
_________________
-doh

[_dA_CyANIDe]

Hi man,

i'm using this IPTABLES rules for SSH. You can try it too.

echo -n "Setting SSH security"
$IPTABLES -N SSH-HACKER
$IPTABLES -A SSH-HACKER -m recent --name badSSH --set -j LOG \
--log-level DEBUG --log-prefix "hacker SSH user :>"
$IPTABLES -A SSH-HACKER -j REJECT

$IPTABLES -N SSH
$IPTABLES -A SSH -p tcp ! --syn -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -A SSH -p tcp --syn -m recent --name badSSH --rcheck \
--seconds 300 -j REJECT
$IPTABLES -A SSH -p tcp --syn -m recent --name sshconn --rcheck \
--seconds 60 --hitcount 5 -j SSH-HACKER
$IPTABLES -A SSH -p tcp --syn -m recent --name sshconn --set
$IPTABLES -A SSH -p tcp --syn -j ACCEPT
echo -n "...done!"

$IPTABLES -A INPUT -i $NET_IFACE -p TCP --dport 22 -j SSH #SSH server
_________________
AMD64 X2 3800+, 1GB RAM, Gigabyte GF7600
-----
Firewalls cannot block stupidity!

[DNAspark99]

knock knock.

port knocking is the way to go. several options out there.
Also only allow key authentication in sshd, to be even more secured.

if you're creating scripts to ban brute offenders, if one of them actually happens to find a valid user/pass before your script swings into action, then it's probably allready TOO LATE!!

[_dA_CyANIDe]

Yes, yes, you have right. No user/pass.
_________________
AMD64 X2 3800+, 1GB RAM, Gigabyte GF7600
-----
Firewalls cannot block stupidity!

[Shadus]

[Spockmeat]

All I did for mine (and I don't claim it to be correct or finished, but it seems to be working properly) was the following, and you can just run these command as is from the command line to add the rules to your iptables.

[Syzygy]

I'm going to go ahead and /bump this. I would like to add my thoughts and question:

- Like everyone else I am constantly brute-forced
- I have taken the smart route and disabled logins for all but a single non-root user, who has a strong password.

I would still like a program that temporarily bans "login-happy" IP's. ... Not because I am paranoid about security, but because it gets rather tedious, waiting for mutt to load up 10,000 e-mails every day, most of which are titled "Warning (program: sshd)". So I would like a solution to stop the problem at its source (i.e., autoban chatty IP's) or somewhere downstream (i.e., suppress cron e-mailing of those particular warning messages).

Running sshd on a port other than 22 seems like a good solution to the problem, but I wanted to see what other people suggested.
_________________
Tim Morgan
DP G5/1.8GHz, no working Gentoo (yet...)

[alsuren]

okay, here's something:

When people do brute force attacks, they'll probably be doing it from a compromised box (one would assume) so would it be possible to do a "return fire" attack, with the intention of getting rid of whatever is running on the system to automatically brute force you (and maybe even run something on the compromised system so if someone (possibly the cracker who compromised the box in the first place?) tries to log in, it'll lock him out too.

*shrug*

I don't know how this would work really, but it would be nice if we could set up a load of booby trap boxes out there on the net that are locked down so that nobody can break in, and will return fire only when attacked. Then we might see the numbers of compromised boxes going *down*

Trouble is if the compromised boxes are windows ones, you couldn't simply make it run a bash script :P

This is probably not the most useful of posts, but it'd be a cool idea, no?
_________________
<alsuren 22:07:55> I thought it was 42
<ladymauv 22:08:19> Maybe it's really 69

[marslander]

bah i'm running a deny host script and ahave only one user that can login to the server
and moslty bans stay for a while say till i get the mood of cleaning them out or say a month ban i think for each ip

kidan less trouble if they can find the right user and theright pass

they realy arent bad

since in brute force hm start by A kidna or say depending on there dictionary and the change they find right user and pass
is one out of i dunno and since htye gat banned after 5 wrong login attempts

would take thema while to get there

[nevynxxx]

How about the easier way.

1) how often do you connect from the outside?

2) how often do you connect from a subnet other than your work/favorite cafe?

Step one, block all ssh connection on the external interface.

If the answer to 1) is never. Stop here, your done. If the answer to two is never, add rules to allow from the apropriate subnet(s). Otherwise implement port knocking.
_________________
My Public Key

Wanted: Instructor in the art of Bowyery

[isilia]

There are LOADS of invalid user errors (sshd) in /var/log/auth.log, example:

[erik258]

It's probably the Bot Net. That's just speculation, but it's unlikely that somebody's trying to log into your computers manually. Instead, I would think that it's an automated system that uses already compromised computers to try to compromise new systems by finding accounts with guessable passwords and logging in with ssh, in an effort to grow the ranks of the compromised servers.

I have seen these logins ever since I put my boxes on broadband. I don't worry about it because I use strong passwords and have few users. However, I would recommend you look into Fail2Ban which uses IPTables and/or log files to temporarily or permanently firewall access from abusive IPs. I have seen it configured, and was impressed with the results.

You can also have SSH listen on a port other than 22, the standard SSH port. 222 and 223 used to be forwarded through the router to internal servers, and my logs don't show anyone unauthorized ever tried to log in to an SSH server listening on a nonstandard port (although it is technically possible to identify an SSH server running on a nonstandard port, it takes substantially longer, and therefore is probably a much less efficient attack vector than simply hitting the standard port).

I have always wanted to set up a honey pot on 22, so that I could turn around the username/password combinations I collected and use them to start fighting back against these bot nets. But I ran into difficulties getting the supplied password out of the SSH server from openSSH; I am not a skilled hacker. But I digress.

In conclusion, I do not worry about these failed logins, but some of my friends do; I usually recommend listening on a nonstandard port because fail2ban is more difficult to configure, but both are good solutions, and fail2ban requires no outside knowledge client-side (which port to connect to) and avoids possible attacks that have found your nonstandard SSH ports using smarter service identification, so it's probably a better choice all around. Of course, you can always use RSA certs rather than passwords to log in, making it absurd to try to guess the authentication info. And nothing is a replacement for strong passwords.

And remember, the originating IP of these attacks is probably not owned by an attacker, but rather to the poorly secured server of a more or less benevolent internetzien. (I like to look up the admin of the IP range if driven to action, and send them an informative email about the problem, but I have never once heard back from them. They are usually overseas).

Good luck.
_________________
Configuring a Firewall? Try my iptables configuration
LinuxCommando.com is my blog for linux-related scraps and tidbits. Stop by for a visit!

[nixnut]

merged above two posts here
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

talk is cheap. supply exceeds demand

[isilia]

erik258: Thank you for your (lengthy) reply! Running SSH on a non standard port isn't an option for me, so I'll configure fail2ban. Thanks again.