Hi, today I had about 1.000 Authentication Failures to ssh and I had time to think about how to limit and secure this issue. So I found the "Port Knocking and Other Uses of ''Recent Match''" doc and liked to ask if I simply have to add the example rule: Limit:info:SSHA,3,60 net $FW tcp 22 to my rules and things are more fine. Thanks for clarification the facts. Best regards Götz Reinicke -- Götz Reinicke IT Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke@filmakademie.de Filmakademie Baden-Württemberg GmbH Mathildenstr. 20 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzender des Aufsichtsrats: Dr. Christoph Palmer, MdL, Minister a.D. Geschäftsführer: Prof. Thomas Schadt ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 12, 2007 at 09:19:07AM +0200, G?tz Reinicke wrote:> today I had about 1.000 Authentication Failures to ssh and I had time to > think about how to limit and secure this issue.Hint: don''t bother. Those were all authentication *failures*, so your system is already secure. You don''t have an issue. (If any of them did get through, then you have an easily guessable password somewhere, and nothing that you do will shorewall will help you) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 10/12/07, Andrew Suffield <asuffield@suffields.me.uk> wrote:> Hint: don''t bother. Those were all authentication *failures*, so your > system is already secure. You don''t have an issue.Simple trick, change the port.. Works against most of the port scanning bots. Also, don''t have root account allowed to ssh in. Prasanna. -- www.elinanetworks.com Seamless, secure delivery of applications. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
>today I had about 1.000 Authentication Failures to sshIs that all !> and I had time to >think about how to limit and secure this issue.fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page Works a treat, you set how many failed attempts are allowed, after that, they get banned. Effectively, it gives an attacker only one or two attempts to guess both an account AND a password. Occasionally they''ll come back again, but in practice I tend not to see the same address banned twice in a day. There is one thing though, add a command to restart fail2ban after Shorewall starts - because Shorewall will remove the iptables chains that fail2ban uses. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 12, 2007 at 02:05:23PM +0530, Prasanna Krishnamoorthy wrote:> On 10/12/07, Andrew Suffield <asuffield@suffields.me.uk> wrote: > > Hint: don''t bother. Those were all authentication *failures*, so your > > system is already secure. You don''t have an issue. > > Simple trick, change the port.. Works against most of the port > scanning bots. Also, don''t have root account allowed to ssh in. >And if at all possible, eliminate password logins. Only allow logins to people with ssh keys or Kerberos tickets. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
The other thing to consider is to limit the source IP On 10/12/07, Roberto C. Sánchez <roberto@connexer.com> wrote:> > On Fri, Oct 12, 2007 at 02:05:23PM +0530, Prasanna Krishnamoorthy wrote: > > On 10/12/07, Andrew Suffield <asuffield@suffields.me.uk> wrote: > > > Hint: don't bother. Those were all authentication *failures*, so your > > > system is already secure. You don't have an issue. > > > > Simple trick, change the port.. Works against most of the port > > scanning bots. Also, don't have root account allowed to ssh in. > > > And if at all possible, eliminate password logins. Only allow logins to > people with ssh keys or Kerberos tickets. > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > http://people.connexer.com/~roberto > http://www.connexer.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHD2Wy5SXWIKfIlGQRAsIEAKCbsHXh9s1N0ogivCiPVcq5GF3Q2wCgutl3 > BgB7GKajHHNEl/ktXlhj0k8> =2hgh > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
I''m not really sure how to ask this question so I''ll just give
you some details of my system and Shorewall configuration.
This is a server connected to the internet 24/7 with a public IP only. This
server has a RAC (Remote Access Card) and a dialup modem for remote access as
well (which is my problem I guess). Here is my shorewall log which contains the
following reject:
Oct 12 10:16:13 ip-93 kernel: Shorewall:OUTPUT:REJECT:IN= OUT=ppp0
SRC=192.168.234.235 DST=192.168.234.236 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4756
DF
PROTO=TCP SPT=60154 DPT=5860 WINDOW=5840 RES=0x00 SYN URGP=0
My ifconfig shows the following:
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.234.235 P-t-P:192.168.234.236 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:62 (62.0 b) TX bytes:62 (62.0 b)
My question is how do I enable the "ppp0" so there are no more
rejections. I admit I have no idea how everything in Shorewall works. I use
Shorewall to do nothing more than allow or dissallow connections from the
outside (NET) world to specific ports (ie, http, https, ssh). That setup was
easy to configure and works just fine. I''m just trying to get the rest
of things to work. Here are what I believed to be the shorwall config files that
needed to be modified to allow this connection:
Interfaces File:
loc ppp0 detect
Zones File:
loc ipv4
Rules File:
ACCEPT loc:192.168.234.235 loc:192.168.234.236 tcp
Obviously this is not correct or I''m missing someting else because the
logs still show a rejection.
Sorry I''m no Shorewall or firewall expert.
John
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
J and T wrote:> Interfaces File: > loc ppp0 detect > > Zones File: > loc ipv4 > > Rules File: > ACCEPT loc:192.168.234.235 loc:192.168.234.236 tcp > > Obviously this is not correct or I''m missing someting else because the logs still show a rejection.Forget the rule and just add these two policies: fw loc ACCEPT loc fw ACCEPT -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 12, 2007 at 12:35:29PM -0700, J and T wrote:> > I''m not really sure how to ask this question so I''ll just give you some details of my system and Shorewall configuration. >Tom has already answered your question, so I will simply say: please don''t thread hijack. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
What do you mean "thread hijack"? If that is what I did I surely don''t know about it. ----------------------------------------> Date: Fri, 12 Oct 2007 16:42:41 -0400> From: roberto@connexer.com> To: shorewall-users@lists.sourceforge.net> Subject: Re: [Shorewall-users] Question regarding access and remote login>> On Fri, Oct 12, 2007 at 12:35:29PM -0700, J and T wrote:>>>> I''m not really sure how to ask this question so I''ll just give you some details of my system and Shorewall configuration.>>>> Tom has already answered your question, so I will simply say: please> don''t thread hijack.>> Regards,>> -Roberto> --> Roberto C. Sánchez> http://people.connexer.com/~roberto> http://www.connexer.com _________________________________________________________________ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
J and T wrote:> What do you mean "thread hijack"? If that is what I did I surely don''t know about it.You replied to Nico Pagliaro''s last post in the thread entitled "Limiting SSH Loginattemps" (sic) and changed the subject to "Question regarding access and remote login". That''s "hijacking a thread" and is considered rude behavior on mailing lists because it messes up the threads when the list posts are viewed in threaded mode. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> today I had about 1.000 Authentication Failures to > ssh and I had time to think about how to limit and > secure this issue.The first thing I do is make sure my network is _not_ pingable from the Internet. If you "pong", they know you exist, and they''ll start hunting for your SSHD. The second thing I do is only make the SSHD port visible if the _other_ end seems legit (i.e. it''s in a local ISP''s range). My "rule" is similar to ACCEPT net:1.2.3.4/16,5.6.7.8/24 loc tcp 22 If that doesn''t catch, it falls through to my default policy for net->loc, which is DROP ...i.e. stealth. Just these two things have cut the number of SSH probes in my logs nearly to zero. I''d still be vulnerable to port scans _from_zombies_, but my experience is hackers don''t do that (yet:-). Of course I do other things too: use DNAT rather than ACCEPT so `sshd` actually runs on a separate host _not_ on the firewall itself; completely disallow "root" login (adds an extra `su` step for me, but that''s minor), disallow plain passwords, and change port. If you do all these things and are _still_ getting hammered, then look into fancier technologies like port knocking, blacklisting, and automatic log scanning. The first thing to look at is the general blacklisting feature in shorewall; it''s wider than just SSH ...which may be a good thing if you''re trying to repel coordinated attacks. You can tell either by the very very large number of probes or by watching in real time that almost all these probes come from bots. They''re real stupid ...but VERY fast and VERY persistent. If you allow root SSH and your port is not stealthed, it may take them weeks or months of seemingly fruitless hammering on you but _eventually_ they will get in. good luck! -Chuck Kollars ____________________________________________________________________________________ Catch up on fall''s hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Mon, Oct 15, 2007 at 10:04:02AM -0700, Chuck Kollars wrote:> You can tell either by the very very large number of > probes or by watching in real time that almost all > these probes come from bots. They''re real stupid > ...but VERY fast and VERY persistent. If you allow > root SSH and your port is not stealthed, it may take > them weeks or months of seemingly fruitless hammering > on you but _eventually_ they will get in.Only if you have an utterly retarded password, like a dictionary word, or the username. Otherwise, your hard drive will crash and burn decades before they ever crack it. sshd is not susceptible to this kind of attack and never has been; it''s just far too slow. There is no threat from these things, unless you have stupid passwords. They are attacking only those who have stupid passwords. If you have stupid passwords, you''re already screwed. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Chuck Kollars wrote:>The first thing I do is make sure my network is _not_ >pingable from the Internet. If you "pong", they know >you exist, and they''ll start hunting for your SSHD.My 2d worth, disabling Ping doesn''t make the machine much harder to find, and it makes diagnosing problems much harder - in other words, IMHO speaking as a networking guy that regularly has to diagnose problems AND as a sysadmin, disabling Ping does at least as much harm as it does good. YMMV, that''s my opinion. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Hi everyone, Chuck Kollars <ckollars9@yahoo.com> wrote: > today I had about 1.000 Authentication Failures to> ssh and I had time to think about how to limit and > secure this issue.The first thing I do is make sure my network is _not_ pingable from the Internet. If you "pong", they know you exist, and they''ll start hunting for your SSHD. Disabling ping doesn''t make sense when you need to trouble-shoot problems. Disabling ICMP 8 also breaks other things, not just ping. The second thing I do is only make the SSHD port visible if the _other_ end seems legit (i.e. it''s in a local ISP''s range). My "rule" is similar to ACCEPT net:1.2.3.4/16,5.6.7.8/24 loc tcp 22 If that doesn''t catch, it falls through to my default policy for net->loc, which is DROP ...i.e. stealth. That''s a good idea, simply allow port 22 through from the IP''s you know you''re coming from. I do that myself. Just these two things have cut the number of SSH probes in my logs nearly to zero. I''d still be vulnerable to port scans _from_zombies_, but my experience is hackers don''t do that (yet:-). Of course I do other things too: use DNAT rather than ACCEPT so `sshd` actually runs on a separate host _not_ on the firewall itself; completely disallow "root" login (adds an extra `su` step for me, but that''s minor), disallow plain passwords, and change port. If you do all these things and are _still_ getting hammered, then look into fancier technologies like port knocking, blacklisting, and automatic log scanning. The first thing to look at is the general blacklisting feature in shorewall; it''s wider than just SSH ...which may be a good thing if you''re trying to repel coordinated attacks. I use software called "BlockHosts": http://www.aczoom.com/cms/blockhosts I use it to automatically block IP''s from inbound requests to many services, not just ssh, for people that try and login and fail after many attempts. It has the functionality to disable services (for the inbound IP''s) via tcpwrappers or directly through iptables. By default it blocks them for 12 hours, which is of course configurable. It supports whitelists, so there''s IP''s or subnets you can add which will never get blocked. It has two web interfaces you can install which show you the blocked IP''s via the web. It''s very powerful and very configurable, yet in it''s default install it "just works" without any mods at all. I''ve been using it for years now and it works a treat since it''s automatic, I don''t care if bots or people try and hack in, after a certain amount of attempts they''re blocked for a certain period, unblocked later. All automatic, never need to look at it again. You can tell either by the very very large number of probes or by watching in real time that almost all these probes come from bots. They''re real stupid ...but VERY fast and VERY persistent. If you allow root SSH and your port is not stealthed, it may take them weeks or months of seemingly fruitless hammering on you but _eventually_ they will get in. It goes without saying that a: mkpasswd -s 0 is one of the best ways to set passwords. Have trouble remembering them? setup a password database, and a wrapper around ssh to automatically query the password database and ssh into your hosts. Regards, Michael. good luck! -Chuck Kollars ____________________________________________________________________________________ Catch up on fall''s hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users --------------------------------- Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. Get it now. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Hello, I''d recommend that you disable password authentication and enable certificate SSH authentication Regards Samer> Date: Mon, 15 Oct 2007 18:59:10 +0100 > To: shorewall-users@lists.sourceforge.net > From: linux@thehobsons.co.uk > Subject: Re: [Shorewall-users] Limiting SSH Loginattemps > > Chuck Kollars wrote: > > >The first thing I do is make sure my network is _not_ > >pingable from the Internet. If you "pong", they know > >you exist, and they''ll start hunting for your SSHD. > > My 2d worth, disabling Ping doesn''t make the machine much harder to > find, and it makes diagnosing problems much harder - in other words, > IMHO speaking as a networking guy that regularly has to diagnose > problems AND as a sysadmin, disabling Ping does at least as much harm > as it does good. > > YMMV, that''s my opinion. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users_________________________________________________________________ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
I think that you can try
Options like these help (in /etc/sshd_config):
MaxAuthTries 4
MaxStartups 1:3:6
still you can use one of the below options
BlockHosts
BlockHosts,
is a script written in Python, is easier to set up, maintain, and
configure. The idea behind BlockHosts is to continuously scan a syslog
file for SSHD failed login attempts, and add the IP addresses listed
there (after a predetermined number of attempts have been exceeded) to
the system''s /etc/hosts.deny file -- a different approach from that of
Daemon Shield, which uses iptables to block connection attempts.
After installing the software, run the included setup script (as
described in the INSTALL file). The setup script copies and installs
all of the necessary BlockHosts files to their proper locations:
python setup.py install -force
Once you have the BlockHosts script installed, begin configuration
by editing the /etc/blockhosts.cfg file. BlockHosts comes with a default
configuration file with all options
commented out. Edit this file and uncomment each line suitable for your
installation. All of the options are well-documented in the comments,
and can be uncommented by removing the "#" at the beginning of each
line.
Once your configuration file is ready, the next step is to prepare
the /etc/hosts.deny (or /etc/hosts.allow, depending on your
installation) for BlockHosts by copying the following lines (in their
entirety) to your hosts.{deny|allow} file:
#---- BlockHosts Additions
#---- BlockHosts Additions
sshd:ALL:spawn (/usr/bin/blockhosts.py --verbose >>
/var/log/blockhosts.log 2>&1 )&:allow
proftpd:ALL: spawn (/usr/bin/blockhosts.py --verbose >>
/var/log/blockhosts.log 2>&1 )&:allow
These instructions tell the system to automatically run (spawn) the
BlockHosts script (/usr/bin/blockhosts.py) each time a user attempts to
connect to your system via either SSH or ProFTP. The script will then
determine if the connecting host should be allowed access or be blocked.
Once you have completed these steps, can begin watching for
dictionary attacks. Each blocked address will be added to your
hosts.{deny|allow} file and prevented from accessing your machine for
the specified length of time (specified by AGE_THRESHOLD in the
/etc/blockhosts.cfg file).
sshdfilter
sshdfilter,
which blocks dictionary attackers using iptables, and is very efficient
in how it detects them. The sshdfilter script starts the SSHD service
itself, and instructs SSHD to output all log details to stdout (which
is then captured by sshdfilter). In this way, the script can detect
attacks as they happen, in real time, and significantly reduces the
overhead involved in searching for offenders. Unfortunately,
the sshdfilter script is more complex to set up and install than the
Daemon Shield software, partly because the author has made
distribution-specific installation files that failed for my
(non-included) Mandriva system. Out-of-the-box configurations include
Red Hat 7.3 and 9.0, Fedora Core 3, and Debian 3.1. Details exist for
users who want to attempt an install on an unsupported system, though
they appear to be highly platform-specific.
Employing the basic practices and scripts above, you can harden your
Linux machine against many of the dictionary SSH attacks that plague
Linux systems today. Keeping your system''s software up to date goes a
long way toward protecting yourself against many common security
vulnerabilities that automated scripts attempt to take advantage of.
Don''t let your system be the jumping-off point for spam, additional
system attacks, or even blackmail -- protect yourself with these
practices today.
> Date: Mon, 15 Oct 2007 18:59:10 +0100
> To: shorewall-users@lists.sourceforge.net
> From: linux@thehobsons.co.uk
> Subject: Re: [Shorewall-users] Limiting SSH Loginattemps
>
> Chuck Kollars wrote:
>
> >The first thing I do is make sure my network is _not_
> >pingable from the Internet. If you "pong", they know
> >you exist, and they''ll start hunting for your SSHD.
>
> My 2d worth, disabling Ping doesn''t make the machine much harder
to
> find, and it makes diagnosing problems much harder - in other words,
> IMHO speaking as a networking guy that regularly has to diagnose
> problems AND as a sysadmin, disabling Ping does at least as much harm
> as it does good.
>
> YMMV, that''s my opinion.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Café. Stop by
today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Sorry for the multiple post
I wrote on ssh and brute force on my blog, and I think that we may further
discuss it so people learn from you all
blog link :
http://geek2live.blogspot.com/2007/10/secure-ssh-against-brute-force.html
Regards
Samer Azmy
From: samer_symantec@hotmail.com
To: shorewall-users@lists.sourceforge.net
Date: Tue, 16 Oct 2007 09:05:26 +0000
Subject: Re: [Shorewall-users] Limiting SSH Loginattemps
I think that you can try
Options like these help (in /etc/sshd_config):
MaxAuthTries 4
MaxStartups 1:3:6
still you can use one of the below options
BlockHosts
BlockHosts,
is a script written in Python, is easier to set up, maintain, and
configure. The idea behind BlockHosts is to continuously scan a syslog
file for SSHD failed login attempts, and add the IP addresses listed
there (after a predetermined number of attempts have been exceeded) to
the system''s /etc/hosts.deny file -- a different approach from that of
Daemon Shield, which uses iptables to block connection attempts.
After installing the software, run the included setup script (as
described in the INSTALL file). The setup script copies and installs
all of the necessary BlockHosts files to their proper locations:
python setup.py install -force
Once you have the BlockHosts script installed, begin configuration
by editing the /etc/blockhosts.cfg file. BlockHosts comes with a default
configuration file with all options
commented out. Edit this file and uncomment each line suitable for your
installation. All of the options are well-documented in the comments,
and can be uncommented by removing the "#" at the beginning of each
line.
Once your configuration file is ready, the next step is to prepare
the /etc/hosts.deny (or /etc/hosts.allow, depending on your
installation) for BlockHosts by copying the following lines (in their
entirety) to your hosts.{deny|allow} file:
#---- BlockHosts Additions
#---- BlockHosts Additions
sshd:ALL:spawn (/usr/bin/blockhosts.py --verbose >>
/var/log/blockhosts.log 2>&1 )&:allow
proftpd:ALL: spawn (/usr/bin/blockhosts.py --verbose >>
/var/log/blockhosts.log 2>&1 )&:allow
These instructions tell the system to automatically run (spawn) the
BlockHosts script (/usr/bin/blockhosts.py) each time a user attempts to
connect to your system via either SSH or ProFTP. The script will then
determine if the connecting host should be allowed access or be blocked.
Once you have completed these steps, can begin watching for
dictionary attacks. Each blocked address will be added to your
hosts.{deny|allow} file and prevented from accessing your machine for
the specified length of time (specified by AGE_THRESHOLD in the
/etc/blockhosts.cfg file).
sshdfilter
sshdfilter,
which blocks dictionary attackers using iptables, and is very efficient
in how it detects them. The sshdfilter script starts the SSHD service
itself, and instructs SSHD to output all log details to stdout (which
is then captured by sshdfilter). In this way, the script can detect
attacks as they happen, in real time, and significantly reduces the
overhead involved in searching for offenders.
Unfortunately,
the sshdfilter script is more complex to set up and install than the
Daemon Shield software, partly because the author has made
distribution-specific installation files that failed for my
(non-included) Mandriva system. Out-of-the-box configurations include
Red Hat 7.3 and 9.0, Fedora Core 3, and Debian 3.1. Details exist for
users who want to attempt an install on an unsupported system, though
they appear to be highly platform-specific.
Employing the basic practices and scripts above, you can harden your
Linux machine against many of the dictionary SSH attacks that plague
Linux systems today. Keeping your system''s software up to date goes a
long way toward protecting yourself against many common security
vulnerabilities that automated scripts attempt to take advantage of.
Don''t let your system be the jumping-off point for spam, additional
system attacks, or even blackmail -- protect yourself with these
practices today.
> Date: Mon, 15 Oct 2007 18:59:10 +0100
> To: shorewall-users@lists.sourceforge.net
> From: linux@thehobsons.co.uk
> Subject: Re: [Shorewall-users] Limiting SSH Loginattemps
>
> Chuck Kollars wrote:
>
> >The first thing I do is make sure my network is _not_
> >pingable from the Internet. If you "pong", they know
> >you exist, and they''ll start hunting for your SSHD.
>
> My 2d worth, disabling Ping doesn''t make the machine much harder
to
> find, and it makes diagnosing problems much harder - in other words,
> IMHO speaking as a networking guy that regularly has to diagnose
> problems AND as a sysadmin, disabling Ping does at least as much harm
> as it does good.
>
> YMMV, that''s my opinion.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
Help yourself to FREE treats served up daily at the Messenger Café. Stop by
today!
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Thanks Samer, I''ll have a go with some of the suggestions when I get to
the server.
Regards,
Mike B
From: shorewall-users-bounces@lists.sourceforge.net
[mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Samer Y.
Azmy
Sent: Tuesday, 16 October 2007 5:16 PM
To: Shorewall Users
Subject: Re: [Shorewall-users] Limiting SSH Loginattemps
Sorry for the multiple post
I wrote on ssh and brute force on my blog, and I think that we may further
discuss it so people learn from you all
blog link :
http://geek2live.blogspot.com/2007/10/secure-ssh-against-brute-force.html
Regards
Samer Azmy
________________________________
From: samer_symantec@hotmail.com
To: shorewall-users@lists.sourceforge.net
Date: Tue, 16 Oct 2007 09:05:26 +0000
Subject: Re: [Shorewall-users] Limiting SSH Loginattemps
I think that you can try
Options like these help (in /etc/sshd_config):
MaxAuthTries 4
MaxStartups 1:3:6
still you can use one of the below options
BlockHosts
BlockHosts <http://www.aczoom.com/cms/blockhosts/> , is a script written
in Python, is easier to set up, maintain, and configure. The idea behind
BlockHosts is to continuously scan a syslog file for SSHD failed login attempts,
and add the IP addresses listed there (after a predetermined number of attempts
have been exceeded) to the system''s /etc/hosts.deny file -- a different
approach from that of Daemon Shield, which uses iptables to block connection
attempts.
After installing the software, run the included setup script (as described in
the INSTALL file). The setup script copies and installs all of the necessary
BlockHosts files to their proper locations:
python setup.py install -force
Once you have the BlockHosts script installed, begin configuration by editing
the /etc/blockhosts.cfg file. BlockHosts comes with a default configuration file
with all options commented out. Edit this file and uncomment each line suitable
for your installation. All of the options are well-documented in the comments,
and can be uncommented by removing the "#" at the beginning of each
line.
Once your configuration file is ready, the next step is to prepare the
/etc/hosts.deny (or /etc/hosts.allow, depending on your installation) for
BlockHosts by copying the following lines (in their entirety) to your
hosts.{deny|allow} file:
#---- BlockHosts Additions
#---- BlockHosts Additions
sshd:ALL:spawn (/usr/bin/blockhosts.py --verbose >>
/var/log/blockhosts.log 2>&1 )&:allow
proftpd:ALL: spawn (/usr/bin/blockhosts.py --verbose >>
/var/log/blockhosts.log 2>&1 )&:allow
These instructions tell the system to automatically run (spawn) the BlockHosts
script (/usr/bin/blockhosts.py) each time a user attempts to connect to your
system via either SSH or ProFTP. The script will then determine if the
connecting host should be allowed access or be blocked.
Once you have completed these steps, can begin watching for dictionary attacks.
Each blocked address will be added to your hosts.{deny|allow} file and prevented
from accessing your machine for the specified length of time (specified by
AGE_THRESHOLD in the /etc/blockhosts.cfg file).
sshdfilter
sshdfilter <http://www.csc.liv.ac.uk/%7Egreg/sshdfilter/> , which blocks
dictionary attackers using iptables, and is very efficient in how it detects
them. The sshdfilter script starts the SSHD service itself, and instructs SSHD
to output all log details to stdout (which is then captured by sshdfilter). In
this way, the script can detect attacks as they happen, in real time, and
significantly reduces the overhead involved in searching for offenders.
Unfortunately, the sshdfilter script is more complex to set up and install than
the Daemon Shield software, partly because the author has made
distribution-specific installation files that failed for my (non-included)
Mandriva system. Out-of-the-box configurations include Red Hat 7.3 and 9.0,
Fedora Core 3, and Debian 3.1. Details exist for users who want to attempt an
install on an unsupported system, though they appear to be highly
platform-specific.
Employing the basic practices and scripts above, you can harden your Linux
machine against many of the dictionary SSH attacks that plague Linux systems
today. Keeping your system''s software up to date goes a long way toward
protecting yourself against many common security vulnerabilities that automated
scripts attempt to take advantage of. Don''t let your system be the
jumping-off point for spam, additional system attacks, or even blackmail --
protect yourself with these practices today.
> Date: Mon, 15 Oct 2007 18:59:10 +0100
> To: shorewall-users@lists.sourceforge.net
> From: linux@thehobsons.co.uk
> Subject: Re: [Shorewall-users] Limiting SSH Loginattemps
>
> Chuck Kollars wrote:
>
> >The first thing I do is make sure my network is _not_
> >pingable from the Internet. If you "pong", they know
> >you exist, and they''ll start hunting for your SSHD.
>
> My 2d worth, disabling Ping doesn''t make the machine much harder
to
> find, and it makes diagnosing problems much harder - in other words,
> IMHO speaking as a networking guy that regularly has to diagnose
> problems AND as a sysadmin, disabling Ping does at least as much harm
> as it does good.
>
> YMMV, that''s my opinion.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
________________________________
Help yourself to FREE treats served up daily at the Messenger Café. Stop by
today!
<http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline>
________________________________
Peek-a-boo FREE Tricks & Treats for You! Get ''em!
<http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Prasanna Krishnamoorthy wrote:> On 10/12/07, Andrew Suffield <asuffield@suffields.me.uk> wrote: >> Hint: don''t bother. Those were all authentication *failures*, so your >> system is already secure. You don''t have an issue. > > Simple trick, change the port.. Works against most of the port > scanning bots. Also, don''t have root account allowed to ssh in.Sorry to resurrect an old thread, but... I definitely second this approach (and most of the others, but this one gives huge gains for zero pain). I''ve *never* had an ssh worm attack my systems when they''ve been on alternative ports (i usually select one below 1024 that''s not listed in /etc/services). -- Paul <http://paul.gear.dyndns.org> -- Did you know? It is illegal to use your copy of Microsoft Office on multiple computers without multiple licenses. Why not try the free alternative OpenOffice.org? <http://www.openoffice.org> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/