3

I have a server with ubuntu. I do work on it over SSH. I had a problem with brute force attempts over port 22. I changed the port and I assumed it fixed the brute force problem. Am I right or are the attempts on another port just not logged anymore in /var/log/auth.log?

1
  • Migrated in 3..2..
    – Mike B
    Aug 18, 2009 at 17:06

10 Answers 10

12

To avoid bruteforce attacks here is what i do:

  • Change ssh port
  • Install denyhosts
  • Limit number of connections per second on ssh port
  • Use only keybased no root ssh, instead use sashroot if needed, or console login
  • port knocking to open ssh port in some case

[EDIT]

  • create a canssh group, add the people whom i wanna give ssh to this, add "AllowGroups canssh" to sshd_config. And set DENY_THRESHOLD_(IN)VALID*/ROOT in denyhosts to 1 e.g. one wrong ssh as root or (in)valid user, and your ip is blocked, add my ips to hosts.allow, create ~/.ssh/config and define which ssh-key to use for which server and create aliases say:

[/EDIT]

[EDIT]

  • Use logwatch to email you important logs...

[/EDIT]

And as mentioned earlier, in case of bot attacks, they try 22 by default, so i guess you aren't being targeted any more.

Links:

3
  • 1
    Cool. Do you have a link for the place you got your tin hat? Aug 19, 2009 at 3:48
  • nah, just somethings i picked from here and there in the years since i started nix. Don't have a specific resource, remain on irc (error404notfound on freenode), have subscribed to some of blogs and sites which deal with security, linux and such. Plus for everything i do a google first like: "Secure ssh linux OR distroname"
    – Shoaibi
    Aug 19, 2009 at 7:03
  • thinking to write my own personal "Linux server pocket reference guide" in one of these days that will contain the common tricks, tweaks and hacks that i do with linux servers.
    – Shoaibi
    Aug 19, 2009 at 7:06
5

The attempts are probably just generated by bots trying to get easy access. Unless someone is specifically targeting your system, they won't even look on a different port.

Security by obscurity.

5

As long as you didn't change anything but the port number, the logging won't be affected.

3

No automated attack is going to try other ports, as there are plenty of SSH servers on 22 to try.

As long as all you are relying on the port migration to do is reduce the log spam, then that's fine, but you shouldn't rely on it for any real security.

I've done the same thing to provide the same benefit of preventing the log entries.

2

For added hilarity (and if you have some time to kill), implement Port Knocking:

http://en.wikipedia.org/wiki/Port_knocking

1
  • That's great! I'd never heard of that before. Somewhat security by obscurity though...
    – Luke
    Aug 20, 2009 at 2:44
1

As pointed out by others changing the port will stop the annoying log spam and extra traffic, but is not a security measure as obscurity does not equal security.

A good idea might be to audit the passwords on your system with a password cracker, and/or set new passwords using a methodology like the one described here by Redhat's documentation: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/Security_Guide/s1-wstation-pass.html

2
  • 1
    A better Idea is to use keys, instead of passwords. Aug 19, 2009 at 3:21
  • +1 for obscurity is not security Aug 19, 2009 at 3:44
1

Your logging shouldn't be different because of a port change.

You may also want to look at setting up denyhosts or fail2ban.

1
  • aye, fail2ban is more than enough to have the script kiddies go away, and probably the best solution for this problem. Aug 19, 2009 at 3:45
1

Take a look at here - 20 OpenSSH best security tips: http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html

1

You can rate-limit brute force attak with iptables:

sudo iptables -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "ATTACK SSH BRUTE FORCE "
sudo iptables -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT

0

If you must have the login connection, you may also limit the allowed users to connect by editing /etc/pam.d/ssh and add the line :

auth required pam_listfile.so item=user sense=allow file=/etc/sshusers_allowed onerr=fail

Create a file /etc/sshusers_allowed and put all allowed users line by line.

Maybe a ssh restart, not sure.

2
  • Please use the "code" or "blockquote" tags to format your answer. Aug 18, 2009 at 18:08
  • You can also add groups to the /etc/ssh/sshd_config file under AllowedGroups Aug 19, 2009 at 13:16

You must log in to answer this question.