Mailing List Archive: nsp: juniper

SSH_Brute_Force events

Index | Next | Previous | View Threaded

harri_makela at yahoo

Apr 5, 2012, 3:09 PM

Post #1 of 9 (830 views)
Permalink

SSH_Brute_Force events

Hi Guys

We are getting "SSH_Brute_Force" alerts quite often from our Intrusion prevention systems (IPS) - ISS GX.

Issue Description: We have detected SSH_Brute_Force events sourcing from external IP x.x.x.x targeting multiple internal IPs. This is probably an attempt to gain access to SSH enabled servers.

What could be best practices to handle these alerts ? i.e.

change SSH port system wide from 22 to 10022 ?
Report the ISP to contact with the customer which is really not a practical solution ?

Any advice will be highly appreciated. I myself new to this and trying to document the process.

Thanks in advance
HM
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

jof at thejof

Apr 5, 2012, 3:20 PM

Post #2 of 9 (805 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

On Thu, Apr 5, 2012 at 3:09 PM, Harri Makela <harri_makela [at] yahoo> wrote:
> Hi Guys
>
> We are getting "SSH_Brute_Force" alerts quite often from our Intrusion prevention systems (IPS) - ISS GX.
>
> Issue Description: We have detected SSH_Brute_Force events sourcing from external IP x.x.x.x targeting multiple internal IPs. This is probably an attempt to gain access to SSH enabled servers.
>
> What could be best practices to handle these alerts ? i.e.
>
> change SSH port system wide from 22 to 10022 ?
> Report the ISP to contact with the customer which is really not a practical solution ?
>
> Any advice will be highly appreciated. I myself new to this and trying to document the process.

This is a very common occurrence on the open internet. Usually, these
remote hosts test out some common account names and passwords, looking
for weakly-protected accounts.

The first thing I would do to mitigate this risk in my network would
be to setup firewall filters (in the case of JunOS) on my loopback and
management interfaces so that only internal management stations (that
also cannot be reached from the open internet!) can reach the SSH
daemons on my router.

Switching SSH ports to a non-standard port will stop the casual
scanner, but doesn't really do anything to mitigate the risk.

--j

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

wrx230 at gmail

Apr 5, 2012, 3:21 PM

Post #3 of 9 (792 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

Why is SSH exposed from the internet to begin with? Generally not a great
idea. Otherwise, changing from standard port just makes everything more
difficult when dealing with protocols that run over SSH.

These brute force events are usually just bots scanning for insecure
servers, they don't really pose much threat if your sysadmins have things
taken care of.

I am not familiar much with the IPS capabilities..can a rule be written to
block IP's on the fly?

Morgan

On Thu, Apr 5, 2012 at 3:09 PM, Harri Makela <harri_makela [at] yahoo> wrote:

> Hi Guys
>
> We are getting "SSH_Brute_Force" alerts quite often from our Intrusion
> prevention systems (IPS) - ISS GX.
>
> Issue Description: We have detected SSH_Brute_Force events sourcing from
> external IP x.x.x.x targeting multiple internal IPs. This is probably an
> attempt to gain access to SSH enabled servers.
>
> What could be best practices to handle these alerts ? i.e.
>
> change SSH port system wide from 22 to 10022 ?
> Report the ISP to contact with the customer which is really not a
> practical solution ?
>
> Any advice will be highly appreciated. I myself new to this and trying to
> document the process.
>
> Thanks in advance
> HM
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

harri_makela at yahoo

Apr 5, 2012, 3:34 PM

Post #4 of 9 (831 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

Hi Jonathan

Thanks for the advice.

I`l go through the JunOS configuration and make sure that relevant configuration/filters are being applied.

once I`ll make the process after some more research, I`ll share it with you. The process that I have to write is more to do define the alerts severity and handling.

Thanks
HM

________________________________
From: Jonathan Lassoff <jof [at] thejof>
To: Harri Makela <harri_makela [at] yahoo>
Cc: "juniper-nsp [at] puck" <juniper-nsp [at] puck>
Sent: Thursday, 5 April 2012, 23:20
Subject: Re: [j-nsp] SSH_Brute_Force events

On Thu, Apr 5, 2012 at 3:09 PM, Harri Makela <harri_makela [at] yahoo> wrote:
> Hi Guys
>
> We are getting "SSH_Brute_Force" alerts quite often from our Intrusion prevention systems (IPS) - ISS GX.
>
> Issue Description: We have detected SSH_Brute_Force events sourcing from external IP x.x.x.x targeting multiple internal IPs. This is probably an attempt to gain access to SSH enabled servers.
>
> What could be best practices to handle these alerts ? i.e.
>
> change SSH port system wide from 22 to 10022 ?
> Report the ISP to contact with the customer which is really not a practical solution ?
>
> Any advice will be highly appreciated. I myself new to this and trying to document the process.

This is a very common occurrence on the open internet. Usually, these
remote hosts test out some common account names and passwords, looking
for weakly-protected accounts.

The first thing I would do to mitigate this risk in my network would
be to setup firewall filters (in the case of JunOS) on my loopback and
management interfaces so that only internal management stations (that
also cannot be reached from the open internet!) can reach the SSH
daemons on my router.

Switching SSH ports to a non-standard port will stop the casual
scanner, but doesn't really do anything to mitigate the risk.

--j
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

robertson.corey at gmail

Apr 5, 2012, 3:37 PM

Post #5 of 9 (791 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

Changing to a non-standard port is a start.

You should also look at why SSH is available globally? Locking it down seems like an obvious solution to me.

Lastly, I know there are some IPS systems which have mitigation options built-in. It's not much more than a script that logs into your gear and adds a /32 null route for the offending host at your edge. I've never been a fan of this from an automatic perspective but /32 null routes for habitual offenders have always been successful for me anyway.

HTH

--Corey

On Apr 5, 2012, at 5:09 PM, Harri Makela <harri_makela [at] yahoo> wrote:

> Hi Guys
>
> We are getting "SSH_Brute_Force" alerts quite often from our Intrusion prevention systems (IPS) - ISS GX.
>
> Issue Description: We have detected SSH_Brute_Force events sourcing from external IP x.x.x.x targeting multiple internal IPs. This is probably an attempt to gain access to SSH enabled servers.
>
> What could be best practices to handle these alerts ? i.e.
>
> change SSH port system wide from 22 to 10022 ?
> Report the ISP to contact with the customer which is really not a practical solution ?
>
> Any advice will be highly appreciated. I myself new to this and trying to document the process.
>
> Thanks in advance
> HM
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

thogard at abnormal

Apr 5, 2012, 4:08 PM

Post #6 of 9 (785 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

>
> On Thu, Apr 5, 2012 at 3:09 PM, Harri Makela <harri_makela [at] yahoo> wrote:
> > Hi Guys
> >
> > We are getting "SSH_Brute_Force" alerts quite often from our Intrusion prevention systems (IPS) - ISS GX.
> >
...
> >
> > change SSH port system wide from 22 to 10022 ?
I'm guessing your inside hosts are getting hit and not your router/firewall.

This works well if ssh is needed world wide. I have been doing it for years and so far it has never
caused a propblem that couldn't be fixed by reading a manual and adding a command line option.

> > Report the ISP to contact with the customer which is really not a practical solution ?
> >
> > Any advice will be highly appreciated. I myself new to this and trying to document the process.
>
> This is a very common occurrence on the open internet. Usually, these
> remote hosts test out some common account names and passwords, looking
> for weakly-protected accounts.

These are distributed bruteforce attacks. A host will pick a common user id
like "bob" and a common password like "letmein" and then scan the world trying
those two and recoding which ones work.

There are others thse use ssh keys on existing hacked systems to work
their way into any other systems. Too bad openssh doesn't allow
keys and passwords at the same time but encrypted keys tends to stop
this attack.

Another thing is if ssh keys are used by automated systems, you
don't have to give them a shell that lets them run everything, but you
can have a shell that only runs the one command that is needed.

> Switching SSH ports to a non-standard port will stop the casual
> scanner, but doesn't really do anything to mitigate the risk.
It does mitigate risk buy a calculatable factors.
i.e. going from port 22 to 10022 means the attacker needs to scan first
and that makes that job 10^4 times harder. Knowing they are after you
and not just targets on the net gives you info that makes the defense about
twice as good. So now your system is 2,000 times better by moving the port.
You still need to sure your IDS knows your running ssh on the new port or
else you can increase the risk because you don't get warned.

The rules about security through obscurity is that it should never be
counted on but it is useful as another layer on your security onion.

-tim
http://web.abnormal.com

wrx230 at gmail

Apr 5, 2012, 4:54 PM

Post #7 of 9 (786 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

Changing the port really isn't useful. Against automated systems just
scanning, sure. If someone wants in, they'll find it.

Morgan

On Thu, Apr 5, 2012 at 4:08 PM, Tim Hogard <thogard [at] abnormal> wrote:

> >
> > On Thu, Apr 5, 2012 at 3:09 PM, Harri Makela <harri_makela [at] yahoo>
> wrote:
> > > Hi Guys
> > >
> > > We are getting "SSH_Brute_Force" alerts quite often from our Intrusion
> prevention systems (IPS) - ISS GX.
> > >
> ...
> > >
> > > change SSH port system wide from 22 to 10022 ?
> I'm guessing your inside hosts are getting hit and not your
> router/firewall.
>
> This works well if ssh is needed world wide. I have been doing it for
> years and so far it has never
> caused a propblem that couldn't be fixed by reading a manual and adding a
> command line option.
>
> > > Report the ISP to contact with the customer which is really not a
> practical solution ?
> > >
> > > Any advice will be highly appreciated. I myself new to this and trying
> to document the process.
> >
> > This is a very common occurrence on the open internet. Usually, these
> > remote hosts test out some common account names and passwords, looking
> > for weakly-protected accounts.
>
> These are distributed bruteforce attacks. A host will pick a common user
> id
> like "bob" and a common password like "letmein" and then scan the world
> trying
> those two and recoding which ones work.
>
> There are others thse use ssh keys on existing hacked systems to work
> their way into any other systems. Too bad openssh doesn't allow
> keys and passwords at the same time but encrypted keys tends to stop
> this attack.
>
> Another thing is if ssh keys are used by automated systems, you
> don't have to give them a shell that lets them run everything, but you
> can have a shell that only runs the one command that is needed.
>
> > Switching SSH ports to a non-standard port will stop the casual
> > scanner, but doesn't really do anything to mitigate the risk.
> It does mitigate risk buy a calculatable factors.
> i.e. going from port 22 to 10022 means the attacker needs to scan first
> and that makes that job 10^4 times harder. Knowing they are after you
> and not just targets on the net gives you info that makes the defense about
> twice as good. So now your system is 2,000 times better by moving the
> port.
> You still need to sure your IDS knows your running ssh on the new port or
> else you can increase the risk because you don't get warned.
>
> The rules about security through obscurity is that it should never be
> counted on but it is useful as another layer on your security onion.
>
> -tim
> http://web.abnormal.com
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

plunin at senetsy

Apr 8, 2012, 5:54 AM

Post #8 of 9 (774 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

We are getting "SSH_Brute_Force" alerts quite often from our Intrusion
> prevention systems (IPS) - ISS GX.
>
> [...]

> What could be best practices to handle these alerts ? i.e.
>

Configure rate-limits to ssh. E. g. n attempts per something from a single
IP. JUNOS has such an option under ssh stanza.

change SSH port system wide from 22 to 10022 ?
>

Agree to previous comments. Only reason for this is to make your own life
harder (sometimes needed to distinguish hosts using PAT). But port scanners
know their business well.

Some folks manage to have "single entry point" SSH server exposed to
outside, using which they SSH to devices 'from inside'. Other people run
user-VPNs for only this, which is IMHO too fancy.

> Report the ISP to contact with the customer which is really not a
> practical solution ?
>

Haven't ever seen this gave any result, though a try isn't worth much. But
this can help the people (if they care, which is not always the case), from
whom the attack sourced, but not you. Such things are usually sourced from
hacked machines, so even if you manage to get rid of a particular source,
the attacker probably has plenty of others.

Good news is that the brute force SSH attack is such a frequent thing
(usually automated), that it does not necessarily mean someone is trying to
bruteforce particularly you (commercial attacks are usually much wiser or
just DDoS). Bruteforcers are simply hacking everything not nailed down.
Doesn't mean you don't have to protect from it though.
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

plunin at senetsy

Apr 8, 2012, 8:46 AM

Post #9 of 9 (781 views)
Permalink

Re: SSH_Brute_Force events [In reply to]

4/6/2012 Ð³. 3:08 Tim Hogard wrote:

i.e. going from port 22 to 10022 means the attacker needs to scan first
> and that makes that job 10^4 times harder.
>

It's just like if an MX router doing lookups in 400-entries table had 1000
times more performance than this same router looking against the full
table. Problem with this logic is that scanning X ports is not necessarily
N times harder than scanning N*X ports.

This logic have reasons though, some bruteforcers are too lazy to perform
port scans (there are enough other hosts to try), so the change of port
will let you to not be exposed against them. This divides the 'probability
space of attackers' into two parts: lazy and diligent. But in order to
calculate how much secure you will be after changing the port number, you
must understand which part of attackers overall are lazy and, of course, be
sure that the ones trying to hack you are uniformly distributed over all
attackers :)
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads