New entry for deny hosts, action needed?

This article relates to the logs entries I found: http://xpt.sourceforge.net/techdocs/nix … 01s04.html">http://xpt.sourceforge.net/techdocs/nix/conn/ssh/ssh06-SshServerSecurity/ar01s04.html

Based on that I think I'm set. I might change the ssh port to a higher one, but unless I see lots of attempts in my auth.log for now I think I'll hold off.

If anyone thinks I should be taking any actions let me know :)

If you're really worried, have IPTABLES drop all traffic from that IP.

@vonskippy:

If you're really worried, have IPTABLES drop all traffic from that IP.

Thanks for the tip vonskippy. If I see anymore attempts in the log I'll do just that.

Since I'm using Ubuntu 11.04 I'm using ufw to manage my ip tables. For anyone reading this and wanting to know how to block an ip address using ufw do this as root:

ufw deny from 

Or if you already have port 80 open, this will override any later rules. In that case edit /etc/ufw/before.rules and add a section "Block IP" after "Drop INVALID packets" :

-A ufw-before-input -s 111.222.3.44 -j DROP

Source: https://help.ubuntu.com/community/UFW

Run sshd on a high port.

That's a brute force attack, the IP the attack came from probably was hacked itself, and if the brute force worked, YOUR ip might be in someone else's logs doing the same thing.

Use a port > 1024 for sshd and you will rarely ever see a brute force attempt again.

sshd configuration may be in a different place in your distro, but edit

/etc/ssh/sshd_config

Make sure Port 22 is commented out, and under it put

Port 1331

(or whatever port you choose)

Also, by default setups for linode allow you to ssh in as root.

Make sure you have a non root user you can log in with, then make sure

PermitRootLogin no

is set in the same file.

Restart the sshd daemon and you will rarely if ever see a brute force attempt against that service again.

You will need to set up your ssh client to connect to different port.

See your client documentation (or ask someone who uses same client).

@Ericson578:

This article relates to the logs entries I found: http://xpt.sourceforge.net/techdocs/nix … 01s04.html">http://xpt.sourceforge.net/techdocs/nix/conn/ssh/ssh06-SshServerSecurity/ar01s04.html

Based on that I think I'm set. I might change the ssh port to a higher one, but unless I see lots of attempts in my auth.log for now I think I'll hold off.

If anyone thinks I should be taking any actions let me know :)

Do it. You will see daily attacks against it soon if you do not already.

Didn't take long with my first linode to see daily attacks against the sshd port.

@FunkyRes:

Do it. You will see daily attacks against it soon if you do not already.

Didn't take long with my first linode to see daily attacks against the sshd port.

So? If you have passwords disabled, who cares if someone is trying to hit your sshd? you can install fail2ban if the logs are getting annoying.

Changing sshd to a high port is obscurity, not security. A port scan will easily find it.

@glg:

So? If you have passwords disabled, who cares if someone is trying to hit your sshd? you can install fail2ban if the logs are getting annoying.

Changing sshd to a high port is obscurity, not security. A port scan will easily find it.

Thanks glg, that was the direction I was leaning towards.

My current setup sshd doesn't accept passwords, only keys, and doesn't allow root access. I was looking around in the sshd config file and found a place to specify which users can login, but I'm worried that I might accidentally prevent the linode web-based ssh access which I want to keep around as a last resort.

@FunkyRes:

That's a brute force attack, the IP the attack came from probably was hacked itself, and if the brute force worked, YOUR ip might be in someone else's logs doing the same thing.

I don't think I was hacked, but if my machine was making outgoing ssh attempts how could I tell?

I doubt you were hacked, but just pointing out that banning an IP may not be the best course of action. Attacks will still happen and legitimate users of that IP (now or in the future) won't be able to reach you, even when the problem no longer exists.

I don't think I was hacked either. But I'm genuinely interested in knowing how to monitor my box to see if it's making strange outgoing requests.

Any ideas? I'm assuming there's a log file somewhere where I can view outgoing connection attempts.

When you are hacked, things like log files can't be trusted to be accurate.

I'm not sure what log (if any) an outgoing portscan or ssh attempts would touch.

netstat might help.

You'll probably receive a ticket from Linode in a frighteningly short amount of time. Mass ssh scans aren't exactly subtle.

For what it's worth, here's my decision tree for denyhosts alerts:

1) Is it from a Linode IP? If no, archive the e-mail.

2) Is it from within the last few hours? If no, archive the e-mail.

3) Forward it to abuse@linode.com with the usual boilerplate (including my IP address and the time zone).

4) Receive confirmation that it is being dealt with.

I used to notify other abuse desks, but I get too darned many to care much more than that. :-) For the 24 hours ending at 8am this morning, my home router dropped 1954 packets from 211 sources; a number of these are probably "bad", but I simply cannot gather together enough free time to do much more than ship the logs off to DShield. Receiving attacks is an indication of a healthy and fully-functional Internet connection.

And yes, ssh lives on port 22. I need less cruft riding around in my dotfiles repository, not more.

Less cruft is not an excuse for poor administration.

Moving ssh to another port allows you to close port 22.

When the port scan sees it is closed, the brute force is not even tried.

When the brute force is not even tried, your server doesn't use resources responding to the request and no file I/O is used logging the attempts.

Some services you really can't easily run on other ports, but ssh daemon is one you can, and you really should look at the config file anyway because the defaults are rarely a perfect match for what you really want to do.

@Ericson578:

… I'm worried that I might accidentally prevent the linode web-based ssh access which I want to keep around as a last resort.
Lish logs into your node over the virtual equivalent of a serial console, not your node's sshd. That's why it works even if you break networking.

By the way, lish is also available via ssh to the host – to emphasize, you ssh to the host, which accesses your node via the serial console. It's much better than the terrible Ajax console. :)

@FunkyRes:

Less cruft is not an excuse for poor administration.

Leaving ssh on port 22 is not poor administration. Any other port its on will be discovered in a port scan.

I like to move SSH to a higher port, and then use fail2ban to blast anything that touches port 22 for good 24 hours. Of course, any failed auth attempt to the real SSH port gets blasted too (using pubkey of course).

@Azathoth:

I like to move SSH to a higher port, and then use fail2ban to blast anything that touches port 22 for good 24 hours. Of course, any failed auth attempt to the real SSH port gets blasted too (using pubkey of course).

Care to share your config options to accomplish that. Would save me a little google-fu :D

Firewall (iptables):

...
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j LOG --log-prefix "iptables: DROP: "
iptables -A INPUT -p tcp --dport 22 -j DROP
...

fail2ban filter:

[Definition]
failregex = iptables: DROP: .* SRC=(?P<host>\S*) DST.*
ignoreregex =</host> 

fail2ban jail config:

[ssh-22]
enabled  = true
filter   = ssh-22
action   = iptables[name=SSH-22, port=22, protocol=tcp]
           sendmail-whois[name=SSH-22, dest=root]
logpath  = /var/log/iptables.log
maxretry = 1
bantime = 86400

What I'll probably do though is to put the iptables log at the end of teh valid input chain and not assigned to any port, so that I can ban anything that touches any port other than active enabled services. IMHO this should break any portscan attempt assuming they start at lower ports and work upwards.

If you're busy banning port scans, I hope you don't run an IRC client…

I don't run irc, but that reminds me I wanted to implement a web based chat at some point, thanks :)