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 <j...@thejof.com> To: Harri Makela <harri_mak...@yahoo.com> Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net> 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_mak...@yahoo.com> 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp