Hackers knocking at my door.

[datadan]

Every night I get thousands of attempts to access my server illegally. The names start with a and go through z and root is tried hundreds of times. The IP traffic is from foreign sources or ISPs. (yes telnet is off) I only allow two users SSH access in the sshd_config AllowUsers and disallow root ssh altogether. Can I restrict ssh access to specific IP ranges? What is the syntax? Can I configure server to not allow ssh access for x# minutes after y# of failed attempts? Also is there anything else I should harden things up? Thanks,



<snip>
sshd:
Invalid Users:
Unknown Account: 3779 Time(s)
Authentication Failures:
unknown (61.108.35.250 ): 2181 Time(s)
unknown (ool-43570400.dyn.optonline.net ): 23 Time(s)
unknown (83.97.100.178 ): 1215 Time(s)
unknown (220.64.74.55 ): 107 Time(s)
unknown (222.96.154.133 ): 135 Time(s)
unknown (82-78-123-33.rdsnet.ro ): 3 Time(s)
unknown (82.78.123.33 ): 115 Time(s)
</snip>

 

[iolair]

What type of router are you using? If it's Cisco, what is the ACL set to, if anything?

Iolair MacWalter

 

[lgarner]

You'd do that at the firewall. If you don't have one, then shame on you, but the router can do it as iolair mentioned.

As a last resort you could put the ACL on the server itself. Research "iptables" or "linux firewall"

 

[sleipnir214]

I had a problem with that for several months.

For each of the most egregious cases, I would report the problem to the abuse contact for the registered network on which the hacking machine resides. My emails to these folk generally consist of a summary of the incident and a excerpt from my logs which shows the problem in detail. I would also make sure to tell the abuse admin my time offset from UTC so he/she could track the activity back to their users.

You can get network information through whois queries at ARIN (

http://ws.arin.net/whois)

or its counterparts around the world (see

http://www.arin.net/community/rirs.html

to find those counterparts).

I would then configure my Cisco PIX border firewall and the firewall in the Linux kernel both (belt and suspenders) to deny access from those entire networks.

I don't know if it's coincidence or if the hackers share information, but after I reported and blocked 5 or 6 of the most egregious hackers, the incidents of login attempts fell off dramatically. I do know that a lot of the hacking sweeps I saw originate in university networks around the world.


Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[stefanwagner]

I would email to the abuse-adresses of:

unknown (61.108.35.250 ): 2181 Time(s)
unknown (83.97.100.178 ): 1215 Time(s)

too.

/etc/ssh/sshd_config
has an entry: ListenAdress
perhaps that helps.

The files
/etc/hosts.allow
/etc/hosts.deny
work together with services, specified in inetd AFAIK, and should help there.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[sleipnir214]

I just looked up 61.108.35.250. According to APNIC, that IP address falls into a network registered to an elementary school in Kyongnam, Korea. I've had this kind of stuff come from university networks, but not an elementary school network.


I don't bother with hosts.allow or hosts.deny. I just configure iptables to drop all packets from an offending network.




Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Trevoke]

First thing you can do is not be pingable. That'll essentially hide your server from basic script kiddies.

-Haben sie fosforos?
-No tiengo caballero, but I have un briquet.

 

[n3buo]

I agree with Trevoke. I was being attacked on my ssh server and since we made the change to not be pingable most of the attacks have stopped. I have gone the route in the past and reported the IP's to both my ISP and to the IP's owners. Most do not care.

 

[jstreich]

Consider 3 teirs:
- Hardware firewall with only the ports you use open
- IPTables set to disallow contact on any port from any computer that cannot be trusted (adjust down from here, esp. fif webserver is involved).
- Don't run a telnet service, keep that port blocked, run SSH on a non-standard port. And even in the ssh config be ery spesific who it lets on from where.

Remember: Never let root login remotely -- if you need root access from a remote location ssh as a user and then su to root (requires extra password), sshd should be running as the ssh user or nobody.

We used to have a huge list like yours, then we added the few extra hoops and we almost never see anyone knocking on the door.

[plug=shameless]

http://game-master.us/phpx-3.4.0/

[/plug]