Category: Security

Basic iptables Firewall

The iptables software is a user space application for configuring packet filtering in the Linux kernel. iptables is used to set rules for packets that travel through a host’s network stack and at certain points, called hooks, the iptables rules are evaluated and actions, such as dropping a packet, can be executed. In this post I will draft a script to setup the iptables’ rules for a firewall and then set that script to be executed at boot time.Read More

Preventing SSH Known Hosts Enabled Island Hopping

Upon connecting to an OpenSSH server, the server sends its public key to the
client so that the user on the client side can verify that the server they
are trying to connect to is indeed the server they expect it to be (and not an
attacker spoofing the desired SSH server). Once initially verified, the server’s
key is then stored in the $HOME/.ssh/known_hosts file. Proper use
of this system mitigates SSH Spoofing attacks, but by default it also
presents a data leak that could be utilized by someone who has cracked your system.

When securing a system, we would like to believe our efforts will thwart any
any such attempts at penetration; but any good security plan should consider how
to minimize damage in the event that an intruder does gain access. By default
the keys in known_hosts are referenced in plain text:

$ cat $HOME/known_hosts
$, ssh-rsa AAAAB3NzaC1yz2EAAAADAQABAAABAQC/TLO38IPrLW18kgKx4BQmPGmOXaIKRyTGTFtOT4tCph9ORyb7Mh0SlIe1bowqOFcNI6LUNcrloiTFd9wvAljTHriZJASEOy6uCBf1cKcwX/TpjtiA2uJ7mzosmeoB0PFAxCmKvb2xGXGIsjFOHYWSOitKqxj9r9JUAAURgzb5teml9/bcsMz05qZtkS4EmvYAFXXSaqLNiT+Q3UCjj2GD3mSGqyuy4ad+pEENXNf10D/hMxQBiedH4jNhUJSqTCtJtfVf7532OP7qvQ4PISbh3itEmrFBelkDxlC+3mxFFOzk/SyYWf16Roc9xsnR5HK7mGYG4N4YcxYaioCV1Nd9

The problem here is that if an attacker found a vulnerability in your security
and gained access to a single machine, all they would need to do is run the above
command and they would have a list of hosts on the network that possibly have
the same vulerability. This is a type of an Island Hopping attack, in
which an attacker gains access to a ‘weak link’ in the network and then ‘hops’
around from system to system. We can prevent this type of attack by hashing the
hostnames in our known_hosts file.

Hashing will take our human readable hostname (and ip address) and transform
it into something like


Which is virtually useless to an attacker, but OpenSSH will have no problem
utilizing. To configure our server to hash hostnames automatically, set the
following directive in /etc/ssh/ssh_config:

HashKnownHosts yes

To hash existing entries in your known_hosts use:

ssh-keygen -H

This command will copy your $HOME/.ssh/known_hosts file to
$HOME/known_hosts.old with all the plain text hostnames and replace
the known_host file with hashed hostnames. It would be wise to verify
this replacement file will allow you to connect to remote hosts before removing
the known_hosts.old file.

Protecting Against SSH Server Spoofing

To defend against SSH server spoofing – where an attacker sets up an SSH server and masquerades as another in order to capture users’ login credentials – every SSH server has a unique public key that can be utilized to verify that servers identity. This key is located in the /etc/ssh/ directory, and is used by clients to encrypt communications with the server. In turn, the server must use its private key to decrypt these communications.

The key is a rather long string of random characters and not very useful for humans, but a fingerprint of the key can be produced which is more compatible with the operating system of the mind. The first time an SSH client connects to an SSH server, this fingerprint is displayed.

The authenticity of host ' (' can't be established.
ECDSA key fingerprint is 03:ed:6d:1f:ff:56:9d:5f:f3:65:20:b5:ad:55:55:87.
Are you sure you want to continue connecting (yes/no)?

This prompt is asking the user to verify the offered fingerprint (the fingerprint of the server) against a known good fingerprint under their control. But how is this done? At the time the SSH server is installed and the public/private key pairs are generated, the SSH server administrator can fingerprint the server and distribute this fingerprint to users who will access the server. One can do such fingerprinting with the ssh-keygen program:

ssh-keygen -lf /etc/ssh/ 
256 03:ed:6d:1f:ff:56:9d:5f:f3:65:20:b5:ad:55:55:87  host (ECDSA)

The -l option instructs the program to show the fingerprint, and f for a key file. Simply direct the output the above command to a file and distribute that file to users who will be connecting to the server.

ssh-keygen -lf /etc/ssh/ > server_fingerprint.txt

To get a look at the server’s public key fingerprint before attempting a connection, one can utilize the ssh-keyscan program

ssh-keyscan -t ecdsa > tmp
ssh-keygen -lf tmp 
256 03:ed:6d:1f:ff:56:9d:5f:f3:65:20:b5:ad:55:55:87 (ECDSA)

Here the -t is for type of key to be scanned (which can be rsa1 for protocol version 1, dsa, ecdsa, ed25519, or rsa for protocol version 2). The output is redirected to a temporary file named tmp, then the file is checked with the ssh-keygen program.

Once client has verified the fingerprint, it will store a copy of the server’s public key in $HOME/.ssh/known_hosts and will check the stored key on subsequent connections to that host. If the server has changed its keys, or another machine is attempting to spoof the real server, the client will notice and will not allow connections to that host.