Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-11 Thread Matt Emmerton

On 10/08/10 05.13, Matt Emmerton wrote:


I'm in the middle of dealing with a SSH brute force attack that is
relentless.  I'm working on getting sshguard+ipfw in place to deal with 
it,
but in the meantime, my box is getting pegged because sshd is accepting 
some

connections which are getting stuck in [accepted] state and eating CPU.

I know there's not much I can do about the brute force attacks, but will
upgrading openssh avoid these stuck connections?


If the attack you're experiencing is trying to exhaust system resources by 
opening a large number of connections, then you may want to toggle these 
options in sshd_config:


ClientAliveInterval
LoginGraceTime
MaxAuthTries
MaxSessions
MaxStartups

Check the man-page. Secondly, check your logs if this attack is from a 
limited range of IPs, if so, you might want to try block those ranges.


If your users will only connect from your country, then blocking other 
countries in your firewall is very effective.


Thanks to everyone for their help.

I did have MaxSessions set to a small number, but that essentially DoS'd my 
access to the server when enough sshd processes got hung.


sshguard+ipfw was blocking a large number of attacks, but the other attacks 
that were coming in and hanging sshd weren't getting caught (because they 
weren't repetitive.)


I have moved some of my servers to alternate ports, and on the others I 
tweaked some of the settings Erik suggested which has helped a lot.


Thanks for all the advice.

--
Matt 


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-10 Thread Rocky Borg
One thing I don't see mentioned a lot is port knocking. It's not perfect 
but it does have it's uses.


Since it sounds like you have a lot of users that need to connect you 
might be able to adapt it to your situation. I haven't tried this 
specific port knocking sequence but you could setup a knock where if a 
user attempts to connect to port 22 say 3 times (most clients should 
auto retry) it then opens up port 22 to that ip and allows them to 
connect to sshd. This would depend on the type of brute force being 
done. A distributed botnet might only try an ip/port once or twice then 
move on. This would be pretty seemless to the end user except for an 
initial delay when connecting as their client retries the connection 
until the specific knock threshold has been hit. It's a middle ground to 
changing the port sshd is operating on. You can do this with firewall 
rules or http://www.freshports.org/security/knock/. A lot of  SSH 
attacks are coming from large numbers of compromised hosts that make 
them very hard to stop with sshguard which is pretty annoying.


On 8/9/2010 8:13 PM, Matt Emmerton wrote:

Hi all,

I'm in the middle of dealing with a SSH brute force attack that is 
relentless.  I'm working on getting sshguard+ipfw in place to deal 
with it, but in the meantime, my box is getting pegged because sshd is 
accepting some connections which are getting stuck in [accepted] state 
and eating CPU.


I know there's not much I can do about the brute force attacks, but 
will upgrading openssh avoid these stuck connections?


root 39127 35.2  0.1  6724  3036  ??  Rs   11:10PM   0:37.91 sshd: 
[accepted] (sshd)
root 39368 33.6  0.1  6724  3036  ??  Rs   11:10PM   0:22.99 sshd: 
[accepted] (sshd)
root 39138 33.1  0.1  6724  3036  ??  Rs   11:10PM   0:41.94 sshd: 
[accepted] (sshd)
root 39137 32.5  0.1  6724  3036  ??  Rs   11:10PM   0:36.56 sshd: 
[accepted] (sshd)
root 39135 31.0  0.1  6724  3036  ??  Rs   11:10PM   0:35.09 sshd: 
[accepted] (sshd)
root 39366 30.9  0.1  6724  3036  ??  Rs   11:10PM   0:23.01 sshd: 
[accepted] (sshd)
root 39132 30.8  0.1  6724  3036  ??  Rs   11:10PM   0:35.21 sshd: 
[accepted] (sshd)
root 39131 30.7  0.1  6724  3036  ??  Rs   11:10PM   0:38.07 sshd: 
[accepted] (sshd)
root 39134 30.2  0.1  6724  3036  ??  Rs   11:10PM   0:40.96 sshd: 
[accepted] (sshd)
root 39367 29.3  0.1  6724  3036  ??  Rs   11:10PM   0:22.08 sshd: 
[accepted] (sshd)


 PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIME   WCPU 
COMMAND
39597 root 1 1030  6724K  3036K RUN 3   0:28 
35.06% sshd
39599 root 1 1030  6724K  3036K RUN 0   0:26 
34.96% sshd
39596 root 1 1030  6724K  3036K RUN 0   0:27 
34.77% sshd
39579 root 1 1030  6724K  3036K CPU33   0:28 
33.69% sshd
39592 root 1 1020  6724K  3036K RUN 2   0:27 
32.18% sshd
39591 root 1 1020  6724K  3036K CPU22   0:27 
31.88% sshd


--
Matt Emmerton
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to 
freebsd-questions-unsubscr...@freebsd.org





___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-10 Thread Chuck Swiger
Hi, Matt--

On Aug 9, 2010, at 8:13 PM, Matt Emmerton wrote:
 I'm in the middle of dealing with a SSH brute force attack that is 
 relentless.  I'm working on getting sshguard+ipfw in place to deal with it, 
 but in the meantime, my box is getting pegged because sshd is accepting some 
 connections which are getting stuck in [accepted] state and eating CPU.
 
 I know there's not much I can do about the brute force attacks, but will 
 upgrading openssh avoid these stuck connections?

If I wasn't allowed to require that in order to SSH to arbitrary internal 
machines one would need to do a VPN session, the second choice would be to 
install the openssh port with tcpwrappers support + denyhosts.

Regards,
-- 
-Chuck

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-10 Thread Dave
On 8/9/2010 8:13 PM, Matt Emmerton wrote:

 Hi all,

 I'm in the middle of dealing with a SSH brute force attack that is
 relentless.  I'm working on getting sshguard+ipfw in place to deal
 with it, but in the meantime, my box is getting pegged because sshd
 is accepting some connections which are getting stuck in [accepted]
 state and eating CPU.

 I know there's not much I can do about the brute force attacks, but
 will upgrading openssh avoid these stuck connections?

 root 39127 35.2  0.1  6724  3036  ??  Rs   11:10PM   0:37.91
 sshd: [accepted] (sshd) root 39368 33.6  0.1  6724  3036  ??  Rs
   11:10PM   0:22.99 sshd: [accepted] (sshd) root 39138 33.1  0.1
  6724  3036  ??  Rs   11:10PM   0:41.94 sshd: [accepted] (sshd) root
 39137 32.5  0.1  6724  3036  ??  Rs   11:10PM   0:36.56 sshd:
 [accepted] (sshd) root 39135 31.0  0.1  6724  3036  ??  Rs  
 11:10PM   0:35.09 sshd: [accepted] (sshd) root 39366 30.9  0.1 
 6724  3036  ??  Rs   11:10PM   0:23.01 sshd: [accepted] (sshd) root 
39132 30.8  0.1  6724  3036  ??  Rs   11:10PM   0:35.21 sshd:
 [accepted] (sshd) root 39131 30.7  0.1  6724  3036  ??  Rs  
 11:10PM   0:38.07 sshd: [accepted] (sshd) root 39134 30.2  0.1 
 6724  3036  ??  Rs   11:10PM   0:40.96 sshd: [accepted] (sshd) root 
39367 29.3  0.1  6724  3036  ??  Rs   11:10PM   0:22.08 sshd:
 [accepted] (sshd)

  PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIME  
  WCPU 
 COMMAND
 39597 root 1 1030  6724K  3036K RUN 3   0:28
 35.06% sshd 39599 root 1 1030  6724K  3036K RUN
 0   0:26 34.96% sshd 39596 root 1 1030  6724K  3036K
 RUN 0   0:27 34.77% sshd 39579 root 1 1030 
 6724K  3036K CPU33   0:28 33.69% sshd 39592 root 1
 1020  6724K  3036K RUN 2   0:27 32.18% sshd 39591 root  
   1 1020  6724K  3036K CPU22   0:27 31.88% sshd

 -- 
 Matt Emmerton

Hi.

There is a cracking/DoS technique, that tries to exhaust a servers 
resources, by continualy issuing connect requests,  in the hope that 
when the stack croaks in some way, it'll somehow drop it's guard, or 
go off air permanently.   Have you upset anyone recently?

Can you not move your services to non standard IP ports, moving away 
from the standard ports, where all the script kiddies  bots hang 
out, or are your clients cast in concrete?

I've got FTP, Web and SSH systems running on two sites, on very non 
standard ports, with next to no one trying to get in as a result, 
but maintaining full visibility to the clients that need them, and 
know where they are!  All my standard ports (80, 21, 22 etc) show as 
non existant to the outside world, except on one site, where the 
mail server is continualy getting hammered, but the site's ISP say 
they cant forward mail to any other port.

The users have no problems, so long as I correctly specify the port 
with the address to them, as in 'address:port' if I send them a link 
etc, or an example how to fill in a connection dialog.

DJB.



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-10 Thread Ian Smith
In freebsd-questions Digest, Vol 323, Issue 3, Message: 35
On Mon, 9 Aug 2010 23:36:57 -0400 Matt Emmerton m...@gsicomp.on.ca wrote: 

I know there's not much I can do about the brute force attacks, but will
upgrading openssh avoid these stuck connections?
  
   1. switch over to using solely RSA keys
  
  In the works; I have too many users to convert :(
  
   2. switch to a non-standard port
  
  This is not attractive, even though it would be effective.  I tried this 
  once already and my support volume skyrocketed so I had to switch back.

Matt, I've seen later responses; portknocking, tcpwrappers + denyhosts 
etc.  The latter works, well but keeping lists of $badguys updated is 
becoming more intensive all the time against botnets.

If you're in a position to permit only connections from a table of IP 
addresses, maybe subnets, there's lots you can do to block connections 
from elsewhere before they get to sshd (or tcpwrappers), eg with ipfw:

ipfw add $rule allow tcp from table(22) to me 22 in recv $ext_if setup
ipfw add deny $logifdesired tcp from any to me 22 in recv $ext_if setup

Add keep-state, or earlier allow established connections, to taste.

For users with varying IPs you can have them do a (say) POP mail ckeck 
or anything requiring auth, tail its log either live or from a maybe 5 
minute cronjob to add $goodguys table entries, simple scripting and it's 
not too onerous training roaming users to (eg) check mail before login.

Adding `date +%s` as the value for added table entries, it's easy 
enough deleting dynamic entries after some period of time, by cron.

If you can't limit connections to just $goodguys for logistic reasons 
you can at least use ipfw 'limit' rules to allow only say one or two ssh 
connections from one IP, which should help the open connections issue.

You could also impose connection limits running sshd from inetd(8):
[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]

HTH, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-10 Thread Paul Macdonald

 On 10/08/2010 15:25, Dave wrote:

On 8/9/2010 8:13 PM, Matt Emmerton wrote:


Hi all,

I'm in the middle of dealing with a SSH brute force attack that is
relentless.  I'm working on getting sshguard+ipfw in place to deal
with it, but in the meantime, my box is getting pegged because sshd
is accepting some connections which are getting stuck in [accepted]
state and eating CPU.

I know there's not much I can do about the brute force attacks, but
will upgrading openssh avoid these stuck connections?

root 39127 35.2  0.1  6724  3036  ??  Rs   11:10PM   0:37.91
sshd: [accepted] (sshd) root 39368 33.6  0.1  6724  3036  ??  Rs
   11:10PM   0:22.99 sshd: [accepted] (sshd) root 39138 33.1  0.1
  6724  3036  ??  Rs   11:10PM   0:41.94 sshd: [accepted] (sshd) root
 39137 32.5  0.1  6724  3036  ??  Rs   11:10PM   0:36.56 sshd:
[accepted] (sshd) root 39135 31.0  0.1  6724  3036  ??  Rs
11:10PM   0:35.09 sshd: [accepted] (sshd) root 39366 30.9  0.1
6724  3036  ??  Rs   11:10PM   0:23.01 sshd: [accepted] (sshd) root
39132 30.8  0.1  6724  3036  ??  Rs   11:10PM   0:35.21 sshd:
[accepted] (sshd) root 39131 30.7  0.1  6724  3036  ??  Rs
11:10PM   0:38.07 sshd: [accepted] (sshd) root 39134 30.2  0.1
6724  3036  ??  Rs   11:10PM   0:40.96 sshd: [accepted] (sshd) root
39367 29.3  0.1  6724  3036  ??  Rs   11:10PM   0:22.08 sshd:
[accepted] (sshd)

  PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIME
  WCPU
COMMAND
39597 root 1 1030  6724K  3036K RUN 3   0:28
35.06% sshd 39599 root 1 1030  6724K  3036K RUN
0   0:26 34.96% sshd 39596 root 1 1030  6724K  3036K
RUN 0   0:27 34.77% sshd 39579 root 1 1030
6724K  3036K CPU33   0:28 33.69% sshd 39592 root 1
1020  6724K  3036K RUN 2   0:27 32.18% sshd 39591 root
   1 1020  6724K  3036K CPU22   0:27 31.88% sshd

--
Matt Emmerton

Hi.

There is a cracking/DoS technique, that tries to exhaust a servers
resources, by continualy issuing connect requests,  in the hope that
when the stack croaks in some way, it'll somehow drop it's guard, or
go off air permanently.   Have you upset anyone recently?

Can you not move your services to non standard IP ports, moving away
from the standard ports, where all the script kiddies  bots hang
out, or are your clients cast in concrete?

I've got FTP, Web and SSH systems running on two sites, on very non
standard ports, with next to no one trying to get in as a result,
but maintaining full visibility to the clients that need them, and
know where they are!  All my standard ports (80, 21, 22 etc) show as
non existant to the outside world, except on one site, where the
mail server is continualy getting hammered, but the site's ISP say
they cant forward mail to any other port.

I'm in agreement with dave here, about ssh anyway moving ssh to a non 
std port makes a massive difference, do it now!


Paul.

--
-
Paul Macdonald
IFDNRG Ltd
Web and video hosting
-
t: 0131 5548070
m: 07534206249
e: p...@ifdnrg.com
w: http://www.ifdnrg.com
-
IFDNRG
40 Maritime Street
Edinburgh
EH6 6SA
-

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-10 Thread Matt Emmerton

On 8/9/2010 8:13 PM, Matt Emmerton wrote:


Hi all,

I'm in the middle of dealing with a SSH brute force attack that is
relentless.  I'm working on getting sshguard+ipfw in place to deal
with it, but in the meantime, my box is getting pegged because sshd
is accepting some connections which are getting stuck in [accepted]
state and eating CPU.

I know there's not much I can do about the brute force attacks, but
will upgrading openssh avoid these stuck connections?


There is a cracking/DoS technique, that tries to exhaust a servers
resources, by continualy issuing connect requests,  in the hope that
when the stack croaks in some way, it'll somehow drop it's guard, or
go off air permanently.   Have you upset anyone recently?


Not that I know of - unless my wife counts :)


Can you not move your services to non standard IP ports, moving away
from the standard ports, where all the script kiddies  bots hang
out, or are your clients cast in concrete?


Right now, they are cast in concrete.  I want to move many of them to public 
keys, so maybe I will change the port at the same time too.



I've got FTP, Web and SSH systems running on two sites, on very non
standard ports, with next to no one trying to get in as a result,
but maintaining full visibility to the clients that need them, and
know where they are!  All my standard ports (80, 21, 22 etc) show as
non existant to the outside world, except on one site, where the
mail server is continualy getting hammered, but the site's ISP say
they cant forward mail to any other port.


I have two servers on the same IP block, and one is getting brute-forced and 
the other is not.  I guess it's just a matter of time before the botnets 
seek it out.



The users have no problems, so long as I correctly specify the port
with the address to them, as in 'address:port' if I send them a link
etc, or an example how to fill in a connection dialog.


I'm seriously going to consider this.

--
Matt 


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-10 Thread Erik Norgaard

On 10/08/10 05.13, Matt Emmerton wrote:


I'm in the middle of dealing with a SSH brute force attack that is
relentless.  I'm working on getting sshguard+ipfw in place to deal with it,
but in the meantime, my box is getting pegged because sshd is accepting some
connections which are getting stuck in [accepted] state and eating CPU.

I know there's not much I can do about the brute force attacks, but will
upgrading openssh avoid these stuck connections?


If the attack you're experiencing is trying to exhaust system resources 
by opening a large number of connections, then you may want to toggle 
these options in sshd_config:


ClientAliveInterval
LoginGraceTime
MaxAuthTries
MaxSessions
MaxStartups

Check the man-page. Secondly, check your logs if this attack is from a 
limited range of IPs, if so, you might want to try block those ranges.


If your users will only connect from your country, then blocking other 
countries in your firewall is very effective.


BR, Erik
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


ssh under attack - sessions in accepted state hogging CPU

2010-08-09 Thread Matt Emmerton

Hi all,

I'm in the middle of dealing with a SSH brute force attack that is 
relentless.  I'm working on getting sshguard+ipfw in place to deal with it, 
but in the meantime, my box is getting pegged because sshd is accepting some 
connections which are getting stuck in [accepted] state and eating CPU.


I know there's not much I can do about the brute force attacks, but will 
upgrading openssh avoid these stuck connections?


root 39127 35.2  0.1  6724  3036  ??  Rs   11:10PM   0:37.91 sshd: 
[accepted] (sshd)
root 39368 33.6  0.1  6724  3036  ??  Rs   11:10PM   0:22.99 sshd: 
[accepted] (sshd)
root 39138 33.1  0.1  6724  3036  ??  Rs   11:10PM   0:41.94 sshd: 
[accepted] (sshd)
root 39137 32.5  0.1  6724  3036  ??  Rs   11:10PM   0:36.56 sshd: 
[accepted] (sshd)
root 39135 31.0  0.1  6724  3036  ??  Rs   11:10PM   0:35.09 sshd: 
[accepted] (sshd)
root 39366 30.9  0.1  6724  3036  ??  Rs   11:10PM   0:23.01 sshd: 
[accepted] (sshd)
root 39132 30.8  0.1  6724  3036  ??  Rs   11:10PM   0:35.21 sshd: 
[accepted] (sshd)
root 39131 30.7  0.1  6724  3036  ??  Rs   11:10PM   0:38.07 sshd: 
[accepted] (sshd)
root 39134 30.2  0.1  6724  3036  ??  Rs   11:10PM   0:40.96 sshd: 
[accepted] (sshd)
root 39367 29.3  0.1  6724  3036  ??  Rs   11:10PM   0:22.08 sshd: 
[accepted] (sshd)


 PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIME   WCPU 
COMMAND

39597 root 1 1030  6724K  3036K RUN 3   0:28 35.06% sshd
39599 root 1 1030  6724K  3036K RUN 0   0:26 34.96% sshd
39596 root 1 1030  6724K  3036K RUN 0   0:27 34.77% sshd
39579 root 1 1030  6724K  3036K CPU33   0:28 33.69% sshd
39592 root 1 1020  6724K  3036K RUN 2   0:27 32.18% sshd
39591 root 1 1020  6724K  3036K CPU22   0:27 31.88% sshd

--
Matt Emmerton 


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-09 Thread Matt Emmerton
 I know there's not much I can do about the brute force attacks, but will 
 upgrading openssh avoid these stuck connections?


1. switch over to using solely RSA keys


In the works; I have too many users to convert :(


2. switch to a non-standard port


This is not attractive, even though it would be effective.  I tried this 
once already and my support volume skyrocketed.



3. what version of openssh are you currently using?


Whatever ships with 8.0-REL, which appears to be:


Best

James= 


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-09 Thread Matt Emmerton

 I know there's not much I can do about the brute force attacks, but will
 upgrading openssh avoid these stuck connections?

1. switch over to using solely RSA keys


In the works; I have too many users to convert :(


2. switch to a non-standard port


This is not attractive, even though it would be effective.  I tried this 
once already and my support volume skyrocketed so I had to switch back.



3. what version of openssh are you currently using?


Whatever ships with 8.0-REL, which appears to be:

OpenSSL version
OpenSSL 0.9.8k 25 Mar 2009

Regards,
--
Matt 


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: ssh under attack - sessions in accepted state hogging CPU

2010-08-09 Thread James Harrison
Hi Matt,
 
 I know there's not much I can do about the brute force attacks, but will 
 upgrading openssh avoid these stuck connections?


1. switch over to using solely RSA keys
2. switch to a non-standard port
3. what version of openssh are you currently using?

Best

James___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org