Distributed SSH attack

krad kraduk at googlemail.com
Sat Apr 24 22:07:25 UTC 2010


On 24 April 2010 14:46, jhell <jhell at dataix.net> wrote:

> On 04/16/2010 05:18, krad wrote:
> > On 16 April 2010 09:39, David Xu <davidxu at freebsd.org> wrote:
> >
> >> Jeremy Lea wrote:
> >>
> >>> Hi,
> >>>
> >>> This is off topic to this list, but I dont want to subscribe to -chat
> >>> just to post there...  Someone is currently running a distributed SSH
> >>> attack against one of my boxes - one attempted login for root every
> >>> minute or so for the last 48 hours.  They wont get anywhere, since the
> >>> box in question has no root password, and doesn't allow root logins via
> >>> SSH anyway...
> >>>
> >>> But I was wondering if there were any security researchers out there
> >>> that might be interested in the +-800 IPs I've collected from the
> >>> botnet?  The resolvable hostnames mostly appear to be in Eastern Europe
> >>> and South America - I haven't spotted any that might be 'findable' to
> >>> get the botnet software.
> >>>
> >>> I could switch out the machine for a honeypot in a VM or a jail, by
> >>> moving the host to a new IP, and if you can think of a way of allowing
> >>> the next login to succeed with any password, then you could try to see
> >>> what they delivered...  But I don't have a lot of time to help.
> >>>
> >>> Regards,
> >>>  -Jeremy
> >>>
> >>>
> >> Try to change SSH port to something other than default port 22,
> >> I always did this for my machines, e.g, change them to 13579 :-)
> >>
> >> Regards,
> >> David Xu
> >> _______________________________________________
> >> freebsd-hackers at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >> To unsubscribe, send any mail to "
> freebsd-hackers-unsubscribe at freebsd.org"
> >>
> >
> > dont allow password auth, tcp wrap it, and acl it with pf. Probably more
> > stuff you can do. Think onions
>
> Not allowing password auth also means turning off PAM authentication for
> logins with openssh and has the resulting effect utmp not being updated
> among other things. Be sure you want to go this route.
>
> tcpwrap it ? that is unneeded. The moment you start configuring
> hosts.allow your system is going to be sending requests for ident. Its a
> bad idea with all the other options that are available.
>

Not by default it doesnt.

Even then ident wont happen to random hosts only ones you trust as you will
be protected via pf/ipfw/iptables, its just their as a safety net.

I did mention onions I thought.


More information about the freebsd-hackers mailing list