home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2016 / linuxmafia.com.tar / linuxmafia.com / pub / linux / security / sshd_sentry / README next >
Internet Message Format  |  2004-10-28  |  5KB
  1. Date: Tue, 12 Oct 2004 11:29:30 -0400 (EDT)                                     
  2. From: Victor Danilchenko <danilche@cs.umass.edu>                                
  3. To: secureshell@securityfocus.com                                               
  4. Subject: Re: OpenSSH -- a way to block recurrent login failures?                
  5.                                                                                 
  6.         Further update, in case anyone cares:                                   
  7.                                                                                 
  8.         I have implemented the client/server functionality, via                 
  9. server-push. It won't scale well for large installations, but for medium        
  10. or small ones, server-push will work much better than client-pull.              
  11. basically the clients try to contact the server each time they blacklist        
  12. a new host, and the server maintains an aggregated blacklist. Each time         
  13. the aggregated blacklist is updated (when a blacklisting request is made        
  14. by three individual clients), the updated blacklist is pushed out to all        
  15. the clients -- the server splits the list of clients into a number of           
  16. queues, and forks a child to handle the distribution to each queue. The         
  17. list of clients is constructed by the expedient of simply registering           
  18. the IP of every host that attempts a connection to the server. It's             
  19. rather simplistic, but it's been working fine on my network.                    
  20.                                                                                 
  21.         Note that this is an alpha-grade release, and the server will           
  22. dump a good deal of info (I run it in a terminal in foreground). I              
  23. haven't even gotten around to writing in the explicit verbosity flag            
  24. into it.                                                                        
  25.                                                                                 
  26.         The code is at http://phobos.cs.umass.edu/~danilche/sshd_sentry         
  27. -- there's the server code, the client code, and also the SRPM                  
  28. containing the client and the startup script. Note that my SRPM symlinks        
  29. the client into /etc/cron.hourly -- this is for our specific 
  30. installation; feel free to remove that line from the spec filebefore
  31. building your own, should you wish to use the RPM.
  32.  
  33. On Mon, 27 Sep 2004, Victor Danilchenko wrote:
  34.  
  35. >On Tue, 21 Sep 2004, Victor Danilchenko wrote:
  36. >
  37. >>      Hi,
  38. >>
  39. >>      We are looking for a way to temporarily block hosts from which
  40. >>we receive a given number of sequential failed login attempts, not
  41. >>necessarily within the same SSH session (so MaxAuthTries is not
  42. >>enough).
  43. >>The best solution I could come up with so far would be to run OpenSSH
  44. >>through TCPWrappers, and set up a log watcher daemon which would edit
  45. >>/etc/hosts.deny on the fly based on the tracked number of failed
  46. >>logins
  47. >>for each logged host.
  48. >>
  49. >>      Is there a better solution known for the sort of problems we
  50. >>have been plagued with lately -- repeated brute-force crack attempts
  51. >>from remote hosts? I looked on FreshMeat and I searched the mailing
  52. >>lists, only to come up empty-handed.
  53. >>
  54. >>      Thanks in advance,
  55. >
  56. >       Thanks to all who replied with the suggestions. Alas, none of
  57. >them were quite suitable.
  58. >
  59. >       The IPTables manipulation is a fine idea, but we need a solution
  60. >that runs in a very heterogeneous environment. At the very least, we
  61. >are
  62. >looking at protecting Redhat Linux, OS/X, and Solaris systems.
  63. >
  64. >       Portsentry is IMO a little too complicated to easily deploy on a
  65. >wide number of systems -- we need a fire-and-forget solution (ideally a        
  66. >simple modification to the sshd_config file, but that obviously is not
  67. >in the cards).
  68. >
  69. >       In the end, I wrote a perl script that did solved the problem
  70. >the brute way -- trail the SSHD logs, and modify /etc/hosts.deny on the
  71. >fly. Attached in this script, should anyone here find it useful. The
  72. >next logical step would be to turn this into a distributed solution
  73. >where blacklists could be shared among individual nodes. Would be nice
  74. >to have a DNS-based blacklisting solution eventually, similar to how
  75. >SPAMming can be handled by MTAs...
  76. >
  77. >       Note that the attached script has been stripped of our
  78. >information before being posted, so a typo or two may have crept in
  79. >somewhere during the cleanup editing. It currently works on OS/X and
  80. >Linux, I haven't yed added the code to make it work on Solaris.
  81. >
  82. >
  83.  
  84.  
  85.