Did you restart the ssh daemon after the changes (not sure I mentioned it)? It can be done a couple of ways, for me, I just go to sharing preferences and disable then re-enable remote login, but this may be less than desirable on a production machine. I'll keep an eye out for your files, but haven't seen them yet. --Robert
Re: > If multiple attacks occur between when it goes to sleep and when it > wakes up, then it will start blocking attacks after it wakes up, > correct? In other words, its possible to have several failed login > attempts while its asleep, but when it wakes up, as soon as it sees a > single failed attempt as root, it will block that IP, correct? The answer is yes. I'm not exactly sure on the math, but it will either block after one failed attempt or two, in either case, denyhosts should have seen yours, added the IP to /etc/hosts.deny and then the next time that user connected SSHD should have blocked the IP and your log should show "refused connect from <someIP>". Like so (attack lasted for four minutes before it was picked up). The last entry here is sshd refusing the connection based on the IP address that denyhosts added to /etc/hosts.deny: from secure.log Dec 26 22:30:10 reg066 sshd[30580]: Connection from 195.31.247.11 port 59320 Dec 26 22:30:10 reg066 sshd[30580]: Did not receive identification string from 195.31.247.11 Dec 26 22:33:46 reg066 sshd[30594]: Connection from 195.31.247.11 port 35711 Dec 26 22:33:48 reg066 sshd[30594]: Invalid user PlcmSpIp from 195.31.247.11 Dec 26 22:33:49 reg066 sshd[30596]: Connection from 195.31.247.11 port 35758 Dec 26 22:33:50 reg066 sshd[30596]: Invalid user plcmspip from 195.31.247.11 Dec 26 22:33:51 reg066 sshd[30598]: Connection from 195.31.247.11 port 35829 Dec 26 22:33:52 reg066 sshd[30598]: Invalid user plcmspip from 195.31.247.11 Dec 26 22:33:53 reg066 sshd[30600]: Connection from 195.31.247.11 port 35895 Dec 26 22:33:54 reg066 sshd[30600]: Invalid user db2inst1 from 195.31.247.11 Dec 26 22:33:55 reg066 sshd[30602]: Connection from 195.31.247.11 port 35955 Dec 26 22:33:56 reg066 sshd[30602]: Invalid user dasusr1 from 195.31.247.11 Dec 26 22:33:57 reg066 sshd[30604]: Connection from 195.31.247.11 port 36016 Dec 26 22:33:58 reg066 sshd[30604]: Invalid user ts from 195.31.247.11 Dec 26 22:33:59 reg066 sshd[30606]: Connection from 195.31.247.11 port 36077 Dec 26 22:34:00 reg066 sshd[30606]: Invalid user TeamSpeak from 195.31.247.11 Dec 26 22:34:01 reg066 sshd[30608]: refused connect from 195.31.247.11 meanwhile from my denyhosts daemon_log: 2010-12-26 22:33:59,786 - denyhosts : INFO new denied hosts: ['195.31.247.11'] So it is actually your sshd that does the blocking, denyhosts facilitates this by populating /etc/hosts.deny for you. My DENY_THRESHOLD_INVALID is set to 1 and my DAEMON_SLEEP is set to "15" which I thought meant 15 seconds (not sure why it took four minutes to catch the IP). At any rate, it is a good sign that your secure.log output appears to be in the necessary format so if we can figure out which regexes are being used, make sure that the correct log file is being evaluated, that hosts.deny is being populated (by the way, have you looked at /etc/hosts.deny to make sure that it exists and isn't empty?--I would use "sudo touch /etc/hosts.deny" to create the file if it doesn't exist), and that the daemon_sleep settings are sane, then we should be getting very close to getting it working. Here's some of my secure.log for comparison (I think yours and mine are identical formats at this point, but another pair of eyes couldn't hurt): Dec 18 08:01:56 reg066 com.apple.SecurityServer[21]: getpwnam() failed for user vbox, creating invalid credential Dec 18 08:01:56 reg066 com.apple.SecurityServer[21]: Failed to authorize right system.login.tty by client /usr/sbin/sshd for authorization created by /usr/sbin/sshd. Dec 18 08:01:56 reg066 sshd[71490]: error: PAM: Authentication failure for illegal user vbox from 67.205.89.136 Dec 18 08:01:56 reg066 sshd[71490]: Failed keyboard-interactive/pam for invalid user vbox from 67.205.89.136 port 33709 ssh2 Dec 18 08:01:56 reg066 com.apple.SecurityServer[21]: getpwnam() failed for user xbox, creating invalid credential Dec 18 08:01:56 reg066 com.apple.SecurityServer[21]: Failed to authorize right system.login.tty by client /usr/sbin/sshd for authorization created by /usr/sbin/sshd. Dec 18 08:01:56 reg066 sshd[71493]: error: PAM: Authentication failure for illegal user xbox from 67.205.89.136 Dec 18 08:01:56 reg066 sshd[71493]: Failed keyboard-interactive/pam for invalid user xbox from 67.205.89.136 port 37787 ssh2 Jonathan S. Abrams wrote: > On Mon, Jan 3, 2011 at 6:07 PM, Robert Wyatt <chupacerv...@gmail.com > <mailto:chupacerv...@gmail.com>> wrote: > > Okay, so I'm looking at my 10.5 installation right now and I have > the following lines at the very bottom of my .cfg file: > > #Added for Mac OS X > #SSHD_FORMAT_REGEX=.* \[Sender sshd\] \[PID \d*(\} \[Message .* PAM: > (?P<message>.*?)\].*? > # > > ####################################################################################################### > > > Those lines are definitely not at the bottom of my .cfg file. > > The "#" at the beginning of the SSHD line is the one that needs to > be added. If these lines aren't present in your installation, I > wonder where your version of DH came from; that is, it's possible > that the person who put yours together has already removed this line > and so you don't need to worry about it. > > > I downloaded DenyHosts-2.6.tar from sourceforge.net > <http://sourceforge.net>. I modified the included .cfg file. > > Regarding the addition of private/ at the beginning of your path, I > think it should be /private/, right? But it should work either way, > I believe, so long as DH is running with root permissions (that is, > either being invoked as a daemon, or running under sudo, or simply > being run by root). > > > I am invoking it as a daemon. > > Now about the DAEMON_SLEEP, it is true that DH won't pick up the > attack until it wakes back up, however, it will read the log from > where it left off the last time, then it should identify your host, > add the IP to hosts.deny, and sshd should see it the next time that > remote computer attempts to ssh to your box (regardless of which > user is trying to log on from that machine). That is, the IP should > be locked out based on your DENY_THRESHOLD_ROOT = 1 when DH wakes up > and reads the log. > > > If multiple attacks occur between when it goes to sleep and when it > wakes up, then it will start blocking attacks after it wakes up, > correct? In other words, its possible to have several failed login > attempts while its asleep, but when it wakes up, as soon as it sees a > single failed attempt as root, it will block that IP, correct? > > *Things that might be worth checking out are any valuable > information in your DAEMON_LOG (as set in .cfg), and whether your > SSHD settings are as they need to be.* Reread the information at the > link I sent you very closely to check whether you have set up SSHD > as recommended for the 10.5 installation. The issue here is that > Phil Schwartz, who wrote denyhosts, relies on us Mac users to help > him help us and Apple has made tiny changes to the SSH functionality > from 10.3, to 10.4, 10.5, and 10.6, all of which have their little > tweaks that need to be made for the REGEXes to work correctly. > > "Fixing" sshd_config is described here (for 10.4, originally, but > still true for 10.5): > http://permalink.gmane.org/gmane.os.apple.fink.beginners/19292/ > > > Maybe I don't have the lines you referenced above because I did not use > FINK to obtain DenyHosts? I made the changes noted at the link you > supplied. > > I'd be happy to send you my denyhosts.cfg for you to review or > modify for your needs (changing /sw to /private as appropriate) if > you'd like, I can verify that my installation is catching and > reporting attacks as advertised. > > The next thing I would ask for is either (or both) your .cfg file or > your output in your DAEMON_LOG--these could be sent to me privately > in order to avoid anything sensitive from being displayed to the > world. I'm leaving the office now but will be available again later > this evening. > > > Please check your email. > > -- > Jonathan S. Abrams, CEA, CBNT > Apple Certified Technical Coordinator (v10.5), Xsan 2 Admin > Treasurer, NY Section, AES > > --Robert > > > Jonathan S. Abrams wrote: >> I could not find the string SSHD_FORMAT_REGEX= in the .cfg file, >> and the few REGEX entries I did find were already commented out. >> >> If the .cfg file is already looking at private/var/log/secure.log, >> how is that different from var/log/secure.log? Both paths point >> to the same file. Is the "private/" throwing off DenyHosts? >> >> DAEMON_SLEEP = 30s This could be where the problem is, as the >> time stamp of the first attack and the last attack are 30s apart. >> What do you think? Does the daemon not know that a host has >> attempted to login as root and failed until it wakes from sleep >> and checks the secure.log file? If this is true, does that >> explain what I reported at the start of this thread? >> >> -- >> Jonathan S. Abrams, CEA, CBNT >> Apple Certified Technical Coordinator (v10.5), Xsan 2 Admin >> Treasurer, NY Section, AES >> >> On Mon, Jan 3, 2011 at 4:31 PM, Robert Wyatt >> <chupacerv...@gmail.com <mailto:chupacerv...@gmail.com>> wrote: >> >> I'll bet it's your regex. From some notes specific to 10.5 (a >> while back) you'll want to make sure that you have >> >> >>> 2) In /sw/etc/denyhosts-py25 edit the denyhosts.cfg file by >> changing >> >>> >> >>> SECURE_LOG = /var/log/asl.log to SECURE_LOG = >> /var/log/secure.log >> >>> >> >>> and comment out the statement SSHD_FORMAT_REGEX= >> >> >> [this is from here:] >> >> http://www.mail-archive.com/fink-beginners@lists.sourceforge.net/msg22454.html >> >> Note that *the path is specific to a fink installation (in >> /sw)*, but your regex still probably needs to be commented out >> from the config file (since it was originally added for >> earlier versions of MacOSX and doesn't apply to 10.5). >> >> If it's not that, then we'd wish to look at (only) the >> pertinent parts of denyhosts.cfg to see what's going on; for >> instance the SECURE_LOG path, sleep settings (that is, how >> often does DH wake up to check the log?), and whatever regexes >> you have. >> >> --Robert >> >> >> >> Jonathan S. Abrams wrote: >>> Thanks for responding. >>> >>> private/var/log/secure.log >>> >>> These are the corresponding entries in the >>> orivate/var/log/secure.log file. >>> >>> Jan 2 14:44:42 clients sshd[22767]: Did not receive >>> identification string from 92.246.211.245 >>> Jan 2 14:44:56 clients sshd[22772]: Failed none for invalid >>> user root from 92.246.211.245 port 3206 ssh2 >>> >>> Jan 2 14:44:57 clients sshd[22772]: error: PAM: >>> Authentication failure for illegal user root from 92.246.211.245 >>> Jan 2 14:44:57 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> >>> Jan 2 14:44:58 clients sshd[22772]: error: PAM: >>> Authentication failure for illegal user root from 92.246.211.245 >>> Jan 2 14:44:58 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> >>> Jan 2 14:44:59 clients sshd[22772]: error: PAM: >>> Authentication failure for illegal user root from 92.246.211.245 >>> Jan 2 14:44:59 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> >>> Jan 2 14:45:03 clients sshd[22772]: error: PAM: >>> Authentication failure for illegal user root from 92.246.211.245 >>> Jan 2 14:45:03 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> >>> Jan 2 14:45:08 clients sshd[22772]: error: PAM: >>> Authentication failure for illegal user root from 92.246.211.245 >>> Jan 2 14:45:08 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> >>> Jan 2 14:45:12 clients sshd[22772]: error: PAM: >>> Authentication failure for illegal user root from 92.246.211.245 >>> Jan 2 14:45:12 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> >>> -- >>> Jonathan S. Abrams, CEA, CBNT >>> Apple Certified Technical Coordinator (v10.5), Xsan 2 Admin >>> Treasurer, NY Section, AES >>> >>> On Mon, Jan 3, 2011 at 2:46 PM, Robert Wyatt >>> <chupacerv...@gmail.com <mailto:chupacerv...@gmail.com>> wrote: >>> >>> Which log file is denyhosts set up to look at in your >>> installation? >>> >>> >>> Jonathan S. Abrams wrote: >>> >>> Hello, >>> >>> I have installed DenyHosts on a Mac OS X v10.5.8 >>> server. I noticed the following entries in the >>> server's system.log file. >>> >>> Jan 2 14:44:56 clients sshd[22772]: Failed none for >>> invalid user root from 92.246.211.245 port 3206 ssh2 >>> Jan 2 14:44:57 clients com.apple.SecurityServer[35]: >>> checkpw() returned -2; failed to authenticate user >>> root (uid 0). >>> Jan 2 14:44:57 clients com.apple.SecurityServer[35]: >>> Failed to authorize right system.login.tty by client >>> /usr/sbin/sshd for authorization created by >>> /usr/sbin/sshd. >>> >>> Jan 2 14:44:57 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> Jan 2 14:44:58 clients com.apple.SecurityServer[35]: >>> checkpw() returned -2; failed to authenticate user >>> root (uid 0). >>> Jan 2 14:44:58 clients com.apple.SecurityServer[35]: >>> Failed to authorize right system.login.tty by client >>> /usr/sbin/sshd for authorization created by >>> /usr/sbin/sshd. >>> >>> Jan 2 14:44:58 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> Jan 2 14:44:59 clients com.apple.SecurityServer[35]: >>> checkpw() returned -2; failed to authenticate user >>> root (uid 0). >>> Jan 2 14:44:59 clients com.apple.SecurityServer[35]: >>> Failed to authorize right system.login.tty by client >>> /usr/sbin/sshd for authorization created by >>> /usr/sbin/sshd. >>> >>> Jan 2 14:44:59 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> Jan 2 14:45:01 clients com.apple.SecurityServer[35]: >>> checkpw() returned -2; failed to authenticate user >>> root (uid 0). >>> Jan 2 14:45:03 clients com.apple.SecurityServer[35]: >>> Failed to authorize right system.login.tty by client >>> /usr/sbin/sshd for authorization created by >>> /usr/sbin/sshd. >>> >>> Jan 2 14:45:03 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> Jan 2 14:45:06 clients com.apple.SecurityServer[35]: >>> checkpw() returned -2; failed to authenticate user >>> root (uid 0). >>> Jan 2 14:45:08 clients com.apple.SecurityServer[35]: >>> Failed to authorize right system.login.tty by client >>> /usr/sbin/sshd for authorization created by >>> /usr/sbin/sshd. >>> >>> Jan 2 14:45:08 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> Jan 2 14:45:10 clients com.apple.SecurityServer[35]: >>> checkpw() returned -2; failed to authenticate user >>> root (uid 0). >>> Jan 2 14:45:12 clients com.apple.SecurityServer[35]: >>> Failed to authorize right system.login.tty by client >>> /usr/sbin/sshd for authorization created by >>> /usr/sbin/sshd. >>> >>> Jan 2 14:45:12 clients sshd[22772]: Failed >>> keyboard-interactive/pam for invalid user root from >>> 92.246.211.245 port 3206 ssh2 >>> >>> Someone (or something) at 92.246.211.245 attempted to >>> login as root at least six (6) times. The >>> denyhosts.cfg file has DENY_THRESHOLD_ROOT = 1. The >>> IP associated with these login attempts did get added >>> to hosts.deny, but it should it not have been added >>> after the first failed login attempt? Should I be >>> looking for some other setting in the .cfg file? Is >>> this normal and expected behavior? >>> >>> Thanks for reading! >>> >>> -- >>> Jonathan S. Abrams, CEA, CBNT >>> Apple Certified Technical Coordinator (v10.5), Xsan 2 >>> Admin >>> Treasurer, NY Section, AES > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Denyhosts-user mailing list Denyhosts-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/denyhosts-user
