Hello all I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample: Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189 Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache. I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html It describes the use of a shell script, run once per minute using a cron job, that parses information from /var/log/messages and adds offending IP addresses to /etc/hosts.deny. I saved the script as ssh-block.sh in my home folder, in a subdirectory named cronjobs. I used su to become root and ran crontab -e, and added the script to run once per minute. Entries in /var/log/messages confirm that the shell script is indeed being run every minute, but the contents of /etc/hosts.deny hasn't changed at all, despite the presence of failed sshd log-ins (also written to /var/log/messages). Can someone knowledgeable about shell scripts take a look at the URL above and see if there is a problem with the script? If not, what did I do incorrectly? What's the proper way to run this job regularly? I assume it must be run as root, both to read /var/log/messages and to write to /etc/hosts.deny. Dan
On Monday 07 November 2005 07:52 pm, Dan Abernathy wrote:
Hello all
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189
Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache.
I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html
It describes the use of a shell script, run once per minute using a cron job, that parses information from /var/log/messages and adds offending IP addresses to /etc/hosts.deny.
I saved the script as ssh-block.sh in my home folder, in a subdirectory named cronjobs. I used su to become root and ran crontab -e, and added the script to run once per minute.
Entries in /var/log/messages confirm that the shell script is indeed being run every minute, but the contents of /etc/hosts.deny hasn't changed at all, despite the presence of failed sshd log-ins (also written to /var/log/messages).
Can someone knowledgeable about shell scripts take a look at the URL above and see if there is a problem with the script? If not, what did I do incorrectly? What's the proper way to run this job regularly? I assume it must be run as root, both to read /var/log/messages and to write to /etc/hosts.deny.
Dan
Since you didn't give us your cron entry, I can only assume you used the full path to the script in the cron line.... Also, what are the permissions on the script? Did you chmod it for execution?
On Monday 07 November 2005 07:52 pm, Dan Abernathy wrote:
Hello all
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189
Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache.
I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html
It describes the use of a shell script, run once per minute using a cron job, that parses information from /var/log/messages and adds offending IP addresses to /etc/hosts.deny.
I saved the script as ssh-block.sh in my home folder, in a subdirectory named cronjobs. I used su to become root and ran crontab -e, and added the script to run once per minute.
Entries in /var/log/messages confirm that the shell script is indeed being run every minute, but the contents of /etc/hosts.deny hasn't changed at all, despite the presence of failed sshd log-ins (also written to /var/log/messages).
Can someone knowledgeable about shell scripts take a look at the URL above and see if there is a problem with the script? If not, what did I do incorrectly? What's the proper way to run this job regularly? I assume it must be run as root, both to read /var/log/messages and to write to /etc/hosts.deny.
Dan
BTW, why not put ssh on a high port (line 12017) and be done with it...? No script-kiddies will find it there or at least it would take them a very long time. Solves a lot of problems at no overhead... unlike running a script every minute. -- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 11/07/05 20:39 + +----------------------------------------------------------------------------+ "The bible shows the way to go to heaven, not the way the heavens go." - Galileo
On Monday 07 November 2005 4:52 pm, Dan Abernathy wrote:
Entries in /var/log/messages confirm that the shell script is indeed being run every minute, but the contents of /etc/hosts.deny hasn't changed at all, despite the presence of failed sshd log-ins (also written to /var/log/messages).
So, what happens when you su to root and run the script manually? Does /etc/hosts.deny get updated? Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.9-default x86_64 SuSE Linux 9.3 (x86-64)
On Monday 07 November 2005 4:52 pm, Dan Abernathy wrote:
Entries in /var/log/messages confirm that the shell script is indeed being run every minute, but the contents of /etc/hosts.deny hasn't changed at all, despite the presence of failed sshd log-ins (also written to /var/log/messages).
It might be an idea to have a look at the following site. BlockHosts - automatic blocking of abusive ssh hosts Script to record how many times "sshd" or "proftpd" is being attacked, and when a particular IP address exceeds a configured number of failed login attempts, that IP address is added to /etc/hosts.allow (or optionally to any other file). http://www.aczoom.com/cms/blockhosts/ -- Regards, Graham Smith
* Dan Abernathy <dapub@charter.net> [11-07-05 19:55]:
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189
Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache.
I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html
It describes the use of a shell script, run once per minute using a cron job, that parses information from /var/log/messages and adds offending IP addresses to /etc/hosts.deny.
Look closely at http://sf.net/projects/denyhosts I have been using it for about a month and it appears to work very well. added to root's crontab */6 * * * * /usr/bin/denyhosts.py -c /etc/denyhosts.cfg has it's own annotated config file -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
Patrick Shanahan wrote:
* Dan Abernathy <dapub@charter.net> [11-07-05 19:55]:
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189
Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache.
I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html
It describes the use of a shell script, run once per minute using a cron job, that parses information from /var/log/messages and adds offending IP addresses to /etc/hosts.deny.
Look closely at http://sf.net/projects/denyhosts
I have been using it for about a month and it appears to work very well.
I created my own using Perl and fileschanged (http://fileschanged.sourceforge.net/). The fileschanged monitors the secure log and when the log changes calls my Perl script. My script determines if new entries are like Nov 7 13:37:15 hostname sshd[9847]: Did not receive identification string from 221.253.105.173 or Nov 7 13:49:35 hostname sshd[9992]: Illegal user james from 61.144.56.34 If I get a match an entry is added using iptables to reject the host. The script traps the dictionary attacks within a few seconds. A side effect of using iptables is the incoming connection hangs waiting for a timeout. When I mentioned this script to friend at work, his response was to block everyone except IPs or domains where you expect connection to come from instead of being reactive. Tom
Thomas A. Lowery wrote:
When I mentioned this script to friend at work, his response was to block everyone except IPs or domains where you expect connection to come from instead of being reactive. Just recently I noticed on my SuSE 9.0 computer a similar problem with vsftpd attacks. I remember having read this thread so I searched for it to give me some ideas on how to respond. I mentioned my problem to an admin at work and he also thought the above approach was a good idea especially since I only run that for a few family and friends.
With a little Googling and man page reading I figured out how to configure the hosts.allow and deny. In hosts.deny I have ALL : ALL and in hosts.allow I have something like ALL : somedomain.com. The problem is that the connecting client times out trying to connect. I remember reading somewhere that I had to put the host in hosts or the DNS lookup would timeout so I suppose that is what is happening. If somedomain.com was a fixed address host, then putting it in hosts would be no problem. Since my family and friends all have dynamic addresses, this is a problem. We all use the free name from www.noip.com but I can't put those in hosts since the address is not fixed. How can I get the tcp_wrappers stuff to work with DNS so I can use the dynamic addresses? So far, all the Googling I have done has led me to a few pages that give some basic info about setting up the hosts.allow and hosts.deny files but I haven't found anything about this DNS problem. Damon Register
On Saturday 25 March 2006 12:24, Damon Register wrote:
Thomas A. Lowery wrote:
When I mentioned this script to friend at work, his response was to block everyone except IPs or domains where you expect connection to come from instead of being reactive.
I put ssh and a few other things on high ports (>12000) Would take the kiddies a little while longer to find it but it stops the major part of any attempts. Why make it easy for them?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-03-25 at 12:24 -0500, Damon Register wrote:
Just recently I noticed on my SuSE 9.0 computer a similar problem with vsftpd attacks. I remember having read this thread so I searched for it to give me some ideas on how to respond. I mentioned my problem to an admin at work and he also thought the above approach was a good idea especially since I only run that for a few family and friends.
When possible, yes.
With a little Googling and man page reading I figured out how to configure the hosts.allow and deny. In hosts.deny I have ALL : ALL and in hosts.allow I have something like ALL : somedomain.com. The problem is that the connecting client times out trying to connect. I remember reading somewhere that I had to put the host in hosts or the DNS lookup would timeout so I suppose that is what is happening. If somedomain.com was a fixed address host, then putting it in hosts would be no problem. Since my family and friends all have dynamic addresses, this is a problem. We all use the free name from www.noip.com but I can't put those in hosts since the address is not fixed.
How can I get the tcp_wrappers stuff to work with DNS so I can use the dynamic addresses? So far, all the Googling I have done has led me to a few pages that give some basic info about setting up the hosts.allow and hosts.deny files but I haven't found anything about this DNS problem.
I don't think it is a timeout problem. The problem is that you need reverse name solving to work. I mean, you need to resolve the IP your friends are comming in to the name you allowed in the hosts.allow. At the time of the connection, the only thing known is the IP. From the IP the system finds out a name... that will not be that of noip.com, but one from their ISP, or none at all. Bad luck. You could setup a complicated mail robot. Your friend sends a gpg authentificated email saying the IP that he is comming from. The robot, fired by procmail, interprets that, adds the IP to the hosts.allow file, and then your friend can connect. The robot can also program an "at" command to remove the IP after an hour, for instance. But no, don't ask me for such a robot, I don't have it! Another idea: use the "recent" module of iptables to automatically block repeated "polls". There was a brief thread in the security list time ago. I I use this in SuSEfirewall2-custom, function fw_custom_before_antispoofing(): iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix SSH attack: ' iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j REJECT On the sixth attempt to connect to port 22 within 60 seconds, that IP is rejected. It is simple to modify. Don't ask me much about it, I'm no expert on iptables ;-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEJamAtTMYHG2NR9URAgQOAKCKjqGAiCE6ovoiNlkydHJkTEJuQQCggJSl XO88qQRab/d6B1SZeyl/Y4g= =XbpO -----END PGP SIGNATURE-----
time of the connection, the only thing known is the IP. From the IP the system finds out a name... that will not be that of noip.com, but one from their ISP, or none at all.
Carlos E. R. wrote: that is embarassing. I should have thought of that. I just tried nslookup of my dad's hopto address. I put the number it gave into nslookup to get the name that his ISP gives. I put that name into hosts.allow and my dad was able to ftp a file with no trouble
Bad luck. yes.
authentificated email saying the IP that he is comming from. The robot, fired by procmail, interprets that, adds the IP to the hosts.allow file, That could work but too complicated for me. I was thinking I could make a script that does what I just did manually with my dad's address.
Another idea: use the "recent" module of iptables to automatically block repeated "polls". There was a brief thread in the security list time ago. I think I stumbled on that in googling around today. That sounds interesting but I suppose that I would have to use something newer than SuSE 9.0. The one thing that was holding me back on upgrading is a strange problem with Western Digital drives which one post I saw refered to as the winmodems of the hard drive world. In previous experimenting, they seemed to have real trouble with the 2.6 kernel. Since I am not using those drives any more, I could upgrade SuSE although my real goal is to create a similar router/server setup with Solaris 10 (a learning experience, not because I have to).
Thanks for your help Damon Register
Damon Register wrote:
Another idea: use the "recent" module of iptables to automatically block repeated "polls". There was a brief thread in the security list time ago. I think I stumbled on that in googling around today. That sounds interesting but I suppose that I would have to use something newer than SuSE 9.0.
I've just now set it up on my gateway to see how it works - I haven't really been too bothered by the ssh dictionary-attacks, but what Carlos describes looks interesting and quite elegant. Oh, and this gateway is running SuSE 7.1 with kernel 2.4.27. So your SUSE 9.0 should be perfectly fine - maybe with a kernel and/or iptables update. /Per Jessen, Zürich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-03-26 at 11:23 +0200, Per Jessen wrote:
I've just now set it up on my gateway to see how it works - I haven't really been too bothered by the ssh dictionary-attacks, but what Carlos describes looks interesting and quite elegant.
Just for the record, the idea was not mine, but from somebody in the suse-security list. I just adapted it a bit. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEJt8vtTMYHG2NR9URAgq9AJ945CbEiFIXAGXCZOANU/1M0SYEtQCfb8sI 3ztB6ffzAP5AFK8yYJZ9/dg= =pPjB -----END PGP SIGNATURE-----
Per Jessen wrote:
Damon Register wrote:
Another idea: use the "recent" module of iptables to automatically block repeated "polls". There was a brief thread in the security list time ago. I think I stumbled on that in googling around today. That sounds interesting but I suppose that I would have to use something newer than SuSE 9.0.
I've just now set it up on my gateway to see how it works - I haven't really been too bothered by the ssh dictionary-attacks, but what Carlos describes looks interesting and quite elegant.
There is a problem with the recent module and its interpretation of Jifies. ssh login does not work when one has just booted, until jifie gets 0 and starts incrementing, then it works. (That's roughly 5 minutes.) There is a bug report in Debian about this. (A friend of mine stumbled over that problem, we used that technique for a while for the German CTAN node.) If this is really of interest, I can look up the details of the Jifie problem and post them here. We have now abandoned that approach, also for other reasons. Let me see, maybe the following is of interest... ----- snip snap -------------------------------------------- THE PROBLEM: We need open ssh connections from the outside. We can not turn off password authentication for all users; it must be possible to log in from a customer or a friend's system when one doesn't have one's private ssh key. Lots of password attacks are run against open ssh ports. We want to defend against these attacks in a reasonable way. THE REQUIREMENTS: It would be best to react only on attacks, and not on arbitrary ssh connections. Alternatively, reacting on lots of ssh connections from the same IP address in a short time frame is possible and can be used as an approximation for an attack situation. Manually mantained configuration files should not be changed permanently by automatic procedures. This makes those file hard to maintain and makes them differ from their committed version. (Most configuration files are under version control.) If the protection mechanism needs to keep state, it shall do so in its own file. The ssh server is not necessarily run on the firewall. I.e., the firewall may forward ssh connection to a system in the DMZ. The solution must be integrated into the operations environment. I.e., proper integration into boot procedures, monitoring, log rotation, and other operation processes is mandatory. False positives may happen, i.e., categorization of ssh requests as attacks that aren't. It must be possible to manually correct false positives. Observation has detected that attacks from the same IP address are rare for a longer duration. Using all IP addresses where any attack has ever happened for ssh request rejection is therefore overshoot. It reduces performance and is not good for manual inspection in case of connection problems or false positives. As risk mitigation strategy, it is sufficient to keep connection reject lists for the duration of server uptime, i.e., the list can and should be discarded at boot time. SOLUTION APPROACHES: There are several scripts available that parse log files for failed password attempts and modify /etc/hosts.deny after an attack has been detected. These scripts modify a manually maintained configuration file. The deny rules in this file grow without bounds, no purging is ever done. Integration in boot and log rotation processes does not exist. Therefore we have chosen to skip this approach. The ipt_recent module for iptables allow to specify thresholds for amount of connections in a given time, specific for IP addresses and protocols. That solution would be a very good choice -- if it would work. ipt_recent doesn't work correctly when Jifies in the Linux kernel overflow. Then it blocks every request, even though they didn't pass the threshold. Therefore we have chosen to skip this approach. CHOSEN SOLUTION: We combine the log parsing approach with transient firewall rules that exist only until the next boot. For that, -- An iptables chain inet_ssh is established that is used for all incoming ssh traffic. -- logsurfer is used to parse syslog message files for sshd failed password entries. -- If more than three failed passwords from one IP address appear within 10 minutes, a drop rule for that IP address is added to the inet_ssh chain. -- Failed password attempts from trusted hosts are ignored. Technically, logsurfer is used because I don't know a better log watching and event creation system. I would prefer to have a better one; it is not really suited for the task, as explained below. The logsurfer configuration ignores failed password messages for IP addresses that are known to belong to the Intranet. (If somebody broke in there already, we have other problems than ssh attacks.) Then the logsurfer configuration triggers execution of the command check-ssh-attack if more than three other failed password messages occurs, or if more than 10 minutes passed since such a message occured. This is a serious deficiency of logsurfer that it does only support timeouts and message limits, but no threshold specifications. I.e., I would need `do action <a> after $n$ events in timespan $t$' but logsurfer does not support such typical threshold-triggered event creation. As a work-around, the messages are passed to check-ssh-attack on stdin. That script can now count the messages and can add the iptables drop rule if three messages are received, or ignore them at will. Adding the iptables drop rule is done by an ssh call. This supports the requirement that the ssh daemon and thus the log file can be on a different host than the firewall. The script sshdeny that does the drop rule addition is careful that each IP address is listed only once in that chain (for maintainability) -- multiple invocations of that script can be run in parallel for the same IP address if multiple hosts are attacked at the same time. For that, shlock from the inn distribution is utilized. This has also the advantage that logsurfer may not be run as root. We introduce the new user logsurf:root (group rights appropriate to read /var/log/messages), the ssh key of that user is placed in root's authorized key files. Access with that ssh key is restricted to IP addresses where logsurfer-ssh-depend runs on. (Too bad that one can only specify a command for specific ssh keys, but is not allowed to add an argument.) A better solution would be that sshdeny reads the IP address from stdin and that ssh key is bound to always execute sshdeny. Two management commands are supplied: -- sshdeny-status lists the current content of the inet_ssh chain. -- sshdeny-reset empties the chain. PROBLEMS: I had the case that attack connections are opened and quite some time is waited before the authentication is tried. When we notice the third authentication failure, there are already other attack connections established. These connections are not blocked, of course. So, in practice, an attacker might have more than three tries to guess an account and a password. -------------------- snip snap -------------------------------- (That's from the README of software that I wrote to handle the case.) I hope that some of the discussions and thoughts above are interesting for some of you. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Joachim Schrod wrote:
There is a problem with the recent module and its interpretation of Jifies. ssh login does not work when one has just booted, until jifie gets 0 and starts incrementing, then it works. (That's roughly 5 minutes.) There is a bug report in Debian about this.
That particular problem I can live with, but you mention another one concerning jiffies further down.
We have now abandoned that approach, also for other reasons. Let me see, maybe the following is of interest...
Yes, thanks - very much worth a read.
The ssh server is not necessarily run on the firewall. I.e., the firewall may forward ssh connection to a system in the DMZ.
Yes, this is the case in my setup.
That solution would be a very good choice -- if it would work. ipt_recent doesn't work correctly when Jifies in the Linux kernel overflow. Then it blocks every request, even though they didn't pass the threshold.
Umm, that's a showstopper alright. I found these: https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=415 http://blog.blackdown.de/2005/05/09/fixing-the-ipt_recent-netfilter-module/ which seems to suggest that the jiffies problem is fixed in recent 2.6 kernels. I wonder if any of it got backported to 2.4.
Therefore we have chosen to skip this approach. CHOSEN SOLUTION:
I sort of like your alternative solution, although it is a little too complicated/over-engineered for my own needs. For various reasons we must have ssh access externally, but it is not used very much - less than once per month. We should undoubtedly just switch to not using passwords, but changing it is not a high priority.
logsurfer is used because I don't know a better log watching and event creation system. I would prefer to have a better one; it is not really suited for the task, as explained below.
I don't know logsurfer, but syslog-ng has some pretty neat features for diverting log-entries to different files and/or pipes, even a database. That has been quite helpful to me a number of times. /Per Jessen, Zürich
Per Jessen wrote:
That solution would be a very good choice -- if it would work. ipt_recent doesn't work correctly when Jifies in the Linux kernel overflow. Then it blocks every request, even though they didn't pass the threshold.
Umm, that's a showstopper alright. I found these:
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=415 http://blog.blackdown.de/2005/05/09/fixing-the-ipt_recent-netfilter-module/
Thanks for pointing them out. I haven't followed that lead for some time now, and it's good to know that this opportunity exists as well.
I sort of like your alternative solution, although it is a little too complicated/over-engineered for my own needs.
I know that it's too complex for most installations, that's why I don't spend the effort to release the software. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-03-27 at 16:40 +0200, Joachim Schrod wrote:
We have now abandoned that approach, also for other reasons. Let me see, maybe the following is of interest...
Really interesting, thank you :-) ... ...
logsurfer is used because I don't know a better log watching and event creation system. I would prefer to have a better one; it is not really suited for the task, as explained below.
If what you need is simply isolating certain messages, that can be easily done with syslog-ng: it has regexp filters, so that you can send the isolated messages to a file, socket or network destination. What I wouldn't know right now is how to trigger execution of an script, though, I'd have to think about it; I'm not a linux programmer. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEKcectTMYHG2NR9URArODAJ9gUHjtcR3NbgNBDQSvItAPRUa/wgCfXH+i FDsjKwrfQKQNF7L3A9veU7U= =SE4H -----END PGP SIGNATURE-----
Carlos E. R. wrote:
If what you need is simply isolating certain messages, that can be easily done with syslog-ng: it has regexp filters, so that you can send the isolated messages to a file, socket or network destination. What I wouldn't know right now is how to trigger execution of an script, though, I'd have to think about it
One option would be to select the needed messages and feed them to a named pipe, then have a script waiting to read from that pipe. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
Per Jessen wrote:
Carlos E. R. wrote:
If what you need is simply isolating certain messages, that can be easily done with syslog-ng: it has regexp filters, so that you can send the isolated messages to a file, socket or network destination. What I wouldn't know right now is how to trigger execution of an script, though, I'd have to think about it
One option would be to select the needed messages and feed them to a named pipe, then have a script waiting to read from that pipe.
logsurfer is exactly such a system that reads messages and triggers events. syslog-ng is not an appropriate tool for that because it has no state. Yes, you can divert all ssh messages to one I/O stream, but that's not the problem to solve. The problem is triggering an action after $n$ messages with the same IP address have been seen in a given time frame. I.e., when one sees an IP address for the first time, one must create a new regex pattern and count the messages that arrive with that pattern in the given time frame, triggering execution of a command if that happens. Using syslog-ng w/ named pipes would ease the handling of log-file rotation; but that's not as big an issue since logrotate solves that nicely. Nevertheless, that's an aspect that I should add to my README file... :-) Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Carlos E. R. wrote:
Another idea: use the "recent" module of iptables to automatically block repeated "polls". There was a brief thread in the security list time ago. I just re-read your post and decided it looks interesting. I want to give it a try
I I use this in SuSEfirewall2-custom, function fw_custom_before_antispoofing(): before your post, I didn't even know of the existence of this file.
On the sixth attempt to connect to port 22 within 60 seconds, that IP is rejected. It is simple to modify. Don't ask me much about it, I'm no expert on iptables ;-) That's ok, I barely understand it. I am looking at the SuSEfirewall2-custom file and am a little confused. The text at the top says there is no help and I can accept that. I suppose I just plug in custom rules in the places where I want them to happen. The last item in each section is "true". Is this always there regardless whether I have custom rules in that section? should it always be true?
Damon Register
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-03-30 at 08:11 -0500, Damon Register wrote:
On the sixth attempt to connect to port 22 within 60 seconds, that IP is rejected. It is simple to modify. Don't ask me much about it, I'm no expert on iptables ;-)
That's ok, I barely understand it. I am looking at the SuSEfirewall2-custom file and am a little confused. The text at the top says there is no help and I can accept that. I suppose I just plug in custom rules in the places where I want them to happen. The last item in each section is "true". Is this always there regardless whether I have custom rules in that section? should it always be true?
What I do is modify one of the existing functions. Yes, the last line there reads "true". I assume that will be the exitcode of the function, but I really don't know, I haven't examined it. Ah, you have to enable the script in /etc/sysconfig/SuSEfirewall2: FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom" And of course, reload the firewall with "SuSEfirewall2". - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEK/I3tTMYHG2NR9URAlf8AJ4i6GgXbq+5GbIW+Jzl1tPRuZSpWwCffH5T ncQUGJE0EXjWXrcfYatBXpM= =qBY3 -----END PGP SIGNATURE-----
On Tue, 8 Nov 2005 11:52 am, Dan Abernathy wrote:
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189
Hundreds of entries like the above,
I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html
We had a similar thread "SSH attack" on the Canberra Linux list linux@lists.samba.org recently. This is the upshot. Here is an iptables based approach, I am about to try to add it to Susefirewall. This will cope with the inpatient attackers who keep trying. Even when they get smarter and spread the attack, only hitting your sshd occasionally, this serves to slow the attack so parsing the logs hourly or daily would be enough. http://blog.andrew.net.au/2005/02/17#ipt_recent_and_ssh_attacks Here is another log-parsing script: http://www.lumiere.net/~j/login_sentry/ There was also a suggestion to hack sshd to make it aware of brute-force attacks. Don't think anything's happened yet. michaelj -- Michael James michael.james@csiro.au System Administrator voice: 02 6246 5040 CSIRO Bioinformatics Facility fax: 02 6246 5166 No matter how much you pay for software, you always get less than you hoped. Unless you pay nothing, then you get more.
On 11/8/05, Dan Abernathy <dapub@charter.net> wrote:
Hello all
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189<http://71.129.198.189> Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189 <http://71.129.198.189>
Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache.
It might be worth your while to take a look at using swatch (it is a PERL module) to defend against these attacks. An example of the config file might be: ------ # # Swatch configuration file for constant monitoring # # assume inside your.org <http://your.org> is OK ignore /10./ # Attempted root logins watchfor /Failed password for root/ echo bold exec "/usr/local/bin/block_ip $11`" mail address=sysadmin\@your.org,subject="Swatch message from GATEWAY: sshd bad root login" watchfor /Failed password for illegal user/ echo exec "/usr/local/bin/block_ip $13`" mail address=sysadmin\@your.org,subject="Swatch message from GATEWAY: ssh illegal user" ----- where the block_ip script is something like: ---- #!/bin/sh /usr/sbin/iptables -I INPUT -s `perl -e '$bad_ip=$ARGV[0];$bad_ip =~ s/::ffff://;print $bad_ip;' $1` -p tcp --dport 22 -j DROP ---- Mark
On Tue, 8 Nov 2005 11:52 am, Dan Abernathy wrote:
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Just to follow up on my last post, to implement rate limiting on SSH attacks I pasted Andrew Pollock's rules into /etc/sysconfig/Susefirewall2-custom Edit /etc/sysconfig/Susefirewall2 and uncomment FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom" /etc/init.d/Susefirewall2_setup reload See how it goes! Here is the /etc/sysconfig/Susefirewall2-custom file. Any line that begins with "--" has been wrapped and needs to be appended to the line before. # # /etc/sysconfig/Susefirewall2-custom # ###################################################### # Rate limit brute force SSH attacks, rules by Andrew Pollock # # # # http://blog.andrew.net.au/2005/02/17#ipt_recent_and_ssh_attacks # #-----------------------------------------------------------------------# # First whitelist a few hosts iptables -N SSH_WHITELIST iptables -A SSH_WHITELIST -s trusted.host -m recent --remove --name SSH -j ACCEPT iptables -A SSH_WHITELIST -s also.reliable -m recent --remove --name SSH -j ACCEPT iptables -A SSH_WHITELIST -s alianet.alia.org.au -m recent --remove --name SSH -j ACCEPT iptables -A SSH_WHITELIST -s flat.alia.org.au -m recent --remove --name SSH -j ACCEPT # Then implement the "recent" based filter iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
###################################################### # Rate limit brute force SSH attacks, rules by Andrew Pollock # # # # http://blog.andrew.net.au/2005/02/17#ipt_recent_and_ssh_attacks # #-----------------------------------------------------------------------#
# First whitelist a few hosts iptables -N SSH_WHITELIST iptables -A SSH_WHITELIST -s trusted.host -m recent --remove --name SSH -j ACCEPT iptables -A SSH_WHITELIST -s also.reliable -m recent --remove --name SSH -j ACCEPT iptables -A SSH_WHITELIST -s alianet.alia.org.au -m recent --remove --name SSH -j ACCEPT iptables -A SSH_WHITELIST -s flat.alia.org.au -m recent --remove --name SSH -j ACCEPT
# Then implement the "recent" based filter iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
With all this you mise well just use tcpwrappers. vi /etc/hosts.deny (Ip's to deny by default. All in this case) sshd: ALL vi /etc/hosts.allow (Ip's to allow to SSH) sshd: <ips to allow> Example: sshd: 192.168.1. 10.10.0.100 Brad Dameron SeaTab Software www.seatab.com
On Tuesday 08 November 2005 01:52, Dan Abernathy wrote:
Hello all
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189
You could use public key authentication only and disable password logins. That way you could sleep better and all the other methods described would serve that these attacks don't fill up your logs. Ulf
On Mon, Nov 07, 2005 at 06:52:06PM -0600, Dan Abernathy wrote: [...]
What's the proper way to run this job regularly?
By putting an OpenBSD firewall in front of that machine, where pf can automatically block any machine that tries to connect more often than a given rate to ssh... (since 3.7). ;-) SCNR, Thomas P.S.: For the curious: Here's how some guy solved this with OpenBSD: http://data.homeip.net/projects/ssh_wall.php I find this extremely elegant - can iptables/netfilter do something like that?
I would recommend DenyHosts project (http://denyhosts.sourceforge.net/) Seems to work pretty well in my case... Dmitry
On Tuesday 08 November 2005 08:52, Dan Abernathy wrote:
Hello all
I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample:
Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189
snip Not only on ssh, but since about a week also massive attempts on the ftp port, although I don't see what it is good for, as anyone can get all the data there by anonymous login and what is shared out on ftp is a dvd read-only media. Nov 15 18:34:52 basilisk vsftpd: Tue Nov 15 18:34:50 2005 [pid 5345] [anyone] FAIL LOGIN: Client "172.178.161.19" Nov 15 18:35:00 basilisk vsftpd: Tue Nov 15 18:34:58 2005 [pid 5349] [admin] FAIL LOGIN: Client "172.178.161.19" Peter
participants (18)
-
Brad Dameron -
Bruce Marshall -
Carlos E. R. -
Damon Register -
Damon Register -
Dan Abernathy -
Dimych -
Graham Smith -
Joachim Schrod -
Mark Keir -
Michael James -
Patrick Shanahan -
Per Jessen -
Peter Sutter -
Scott Leighton -
T. Ribbrock -
Thomas A. Lowery -
Ulf Rasch