5

Sometimes I don't have a static IP and need to administrate my web server remotely. I'm looking for any additional layers of protection I could add to make opening port 22 safer.

Currently I have disabled root password login via SSH. It requires RSA key to login (the private key is stored on a usb smart card).

Are there any known risks with my configuration if port 22 was opened to the public? Besides port 22, iptables only has port 80 and port 443 open to the public.

I'm using a Windows computer to connect to Centos 6 Linux with Putty.

Are there any additional statements I can add to the firewall or SSH config to further limit access to port 22 to only my specific computer so that the port doesn't appear open to people scanning ports? I'm using iptables for the firewall currently.

4

Your existing configuration seems very secure. However, there are additional things you can use to restrict access.

Port knocking can be used to keep the port closes most of the time. This is implemented using iptables. There are daemons which can be used, or the rules can be implemented entirely in iptables as described in the Shorewall documentation.

If tcp wrappers is enabled. A couple of ruless like the following in /etc/hosts.allow will notify you whenever a remote connection is made to the deamon. The first rule lets local connections work silently, adjust the ip address range as appropriate. The second rule prevents access from addresses which reverse to a number of country TLD, and emails a message for each successful connection. It could be noisy, if you don't use Port Knocking.

sshd :          10.0.0.0/8 192.168.0.0/24 

sshd :          ALL \
            EXCEPT .ar .au .br .by .cl .co .cz .do .eg .gt \
                .id .il .in .jp .ma .mx .nl .pe .pk .pl .pt \
                .ro .rs .ru .sa .sg .tr .tw .ua .vn .za \
                .ae .at .bg .gh .hr .hu .ke .kz .lt .md \
                .my .no .sk .uy .ve : \
            spawn (/bin/echo "SSH connection to %N from %n[%a] allowed" | \
                /usr/bin/mailx -s "SSH Allowed" you@example.com)

fail2ban rules can be used to temporarily blacklist hosts which are trying to brute force your server. I've seen occasional attempts when I have had ssh exposed to the Internet.

  • On my SSH server, I see a dozen of attempts every day. fail2ban is really useful against that kind of probes. – lgeorget Jul 5 '13 at 3:28
  • Port knocking is something I didn't know about that could be good if I figure out how to do it. – Bruce Kirkpatrick Jul 5 '13 at 5:58
  • @BruceKirkpatrick The Shorewall documentation describes how it is done, and Shorewall can build the setup for you. This is simpler and less error prone than rolling your own. – BillThor Jul 5 '13 at 14:25
  • @BillThor - very nice tip about the country TLDs. Thanks – MountainX Jul 6 '13 at 19:27
  • I like denyhosts too. – MountainX Jul 6 '13 at 19:27
3

As others have said, SSH is already up to the task in terms of being secure enough. I think it's pointless to move the sshd daemon to a different point. I liken this to setting up a Wirelss access point and hiding the SSID. It's trivial to by pass these types of security through obscurity measures.

Limiting access not just to root, but to only key users is always a good idea, whether it's with SSH access or anything else for that matter.

One thing that I find helpful though is making use of something like fail2ban. You can use it to detect and take countermeasures to slow down and thwart would-be attackers.

  • I do have fail2ban setup and I know it works since I get emails when server restarts and when I login. It bans on 5 failures. Root is currently the only user with bash access. My other users are FTP only, and they have to tunnel through SSH as root user since FTP port is not open. Thanks – Bruce Kirkpatrick Jul 5 '13 at 5:04
1

Your SSH installation is already the state-of-the-art in term of security.

There is something you could do but note that it may be more a pain in the neck for you than a real protection. You could change the port from 22 to a less known one in order to receive less attacks and authentication probes.

  • Don't MAC addresses only appear in Ethernet frames (or 8.11x frames) and not in IP packets? And so MAC filtering is useless as no packet from the Internet has a MAC address field. – Dan D. Jul 5 '13 at 4:41
  • I couldn't get mac to work across the internet. it only works on the same subnet I think. -A INPUT -p icmp --icmp-type echo-request -m mac --mac-source MAC_HERE -j ACCEPT – Bruce Kirkpatrick Jul 5 '13 at 5:38
  • Hmm yes of course, on the internet, it's not really useful... As long as there is a router in the middle, in fact. I took into account my own case in which I have a level 2 VPN I share with a lot of people... so, that's pretty irrelevant here. I edit the answer. – lgeorget Jul 5 '13 at 11:52
  • MAC addresses are spoofable. – user26112 Jul 5 '13 at 12:43
1

en.wikipedia.org: Systrace

OpenBsd man page

OpenBsd have such trick, you can launch OpenSsh with limited permissions and additional logging.

Try to wrap /usr/sbin/sshd with /usr/sbin/systrace.

Each access to any system object would be logged by systrace, any access to any file, directory, network ports, memory, system calls, etc.

Generate policy this way:

systrace -A -d /etc/systrace/sshd.policy/ \
         -E /var/log/systrace_sshd.log /usr/sbin/sshd

Edit policy with your favorite text editor:

vi /etc/systrace/sshd.policy/

Thereafter, launch sshd daemon with restrictions:

systrace -a -d /etc/systrace/sshd.policy/ \
         -E /var/log/systrace_sshd.log /usr/sbin/sshd

There are many how-tos about systrace wrapper over shell, but you should wrap sshd, if you are interesting in secure of daemon.

0

The only risk on the server side is a pre-authentication exploit. There haven't been many (publicly known) in the history of SSH.

0

I use a tar trap in iptables. Too many failed login attempts and you have to go to the physical machine.

10 times in 15 minutes and you're blacklisted.
9 times in 10 minutes and you're blacklisted.
6 times in 5 minutes and you're blacklisted.

Adjust Accordingly!

#
# - Black List
#
-A BLACKLIST -m recent --name blacklist --set
-A BLACKLIST -j LOG --log-level 4 --log-prefix "TAR-TRAP: "
-A BLACKLIST -j DROP
#
# - SSH Tar Trap
#
-A FIREWALL -p tcp --dport ssh -m state --state NEW -j TAR-TRAP
#
-A TAR-TRAP -m recent --update --name blacklist --seconds 900 --hitcount 1 -j LOG --log-level 4 --log-prefix "BANNED: "
-A TAR-TRAP -m recent --update --name blacklist --seconds 900 --hitcount 1 -j DROP
-A TAR-TRAP -m recent --set --name strike1
-A TAR-TRAP -m recent --set --name strike2
-A TAR-TRAP -m recent --set --name strike3
-A TAR-TRAP -m recent --update --name strike1 --seconds 300 --hitcount 6 -j LOG --log-level 4 --log-prefix "IPT TAR1: "
-A TAR-TRAP -m recent --update --name strike1 --seconds 300 --hitcount 6 -j BLACKLIST
-A TAR-TRAP -m recent --update --name strike2 --seconds 600 --hitcount 9 -j LOG --log-level 4 --log-prefix "IPT TAR2: "
-A TAR-TRAP -m recent --update --name strike2 --seconds 600 --hitcount 9 -j BLACKLIST
-A TAR-TRAP -m recent --update --name strike3 --seconds 900 --hitcount 10 -j LOG --log-level 4 --log-prefix "IPT TAR3: "
-A TAR-TRAP -m recent --update --name strike3 --seconds 900 --hitcount 10 -j BLACKLIST
-A TAR-TRAP -j ACCEPT
#
  • 1
    Or you could use ssh guard. – user26112 Jul 5 '13 at 12:49
0

You can make a rule like this to block ssh connection from certain source IP addresses. The IP range could be public or private.

$ iptables -A INPUT -p tcp -s IP_Range --dport 22 -j ACCEPT

As an example, you can use this one for your private network

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -j ACCEPT

You can also use tcpwrappers to control ssh access on your centos. TCPwrappers use a combination to /etc/hosts.allow and /etc/hosts.deny files. The following example below shows to set access control which allow to access to sshd from 10.0.0.0/24.

$ vim /etc/hosts.deny
sshd: ALL
$ vim /etc/hosts.allow
sshd: 10.0.0.

You can also make ssh daemon to listen to a different port other than 22.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.