amuck-landowner

Simple security

jcaleb

jcaleb

New Member
Hello,

This is a simple way on how I secure my VPS.

On fresh install, login as root. First create a user you will use to login later, because we will disable root login after a while.


adduser jon
From your client machine, you will want to copy your key to this user on your server. So that you can have passwordless login.
Code: 
ssh-copy-id jon@your-ip-address
If you don't have ssh keys on your client machine, do this first before above, to generate your key pair.
Code: 
ssh-keygen
Again the ssh-keygen and ssh-copy-id are to be executed on your client machine, not from server. I only have linux as my client desktop, I don't know how to do this otherwise on a Windows desktop, sorry.
Now try to login to your server without providing password. If you can login successfully, then good.


ssh jon@your-ip-address
Edit ssh server config. And change the port to some random high value (E.g. 55190). Disable root login, and password authentication
Code: 
sed -i "/Port/cPort 55190" /etc/ssh/sshd_config
sed -i "/PermitRootLogin/cPermitRootLogin no" /etc/ssh/sshd_config
sed -i "/PasswordAuthentication/cPasswordAuthentication no" /etc/ssh/sshd_config
I assume we want ssh server and not dropbear. I dont know how to do this in dropbear.
Next is firewall

Create a file to contain firewall rules


pico /etc/iptables.up.rules
and place the ff. contents
Code: 
*filter

#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allows all outbound traffic
-A OUTPUT -j ACCEPT

#  Allows SSH connections to our new ssh port
-A INPUT -p tcp --dport 55190 -j ACCEPT

# Open Other TCP Ports (like 80 if you will install a webserver).  add more lines like this if you like
-A INPUT -p tcp --dport 80 -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT
You can apply the firewall by running
Code: 
iptables -F
/sbin/iptables-restore < /etc/iptables.up.rules
But we want it to run on restart, so create a script file
Code: 
pico /etc/network/if-pre-up.d/iptables
And put the contents
Code: 
#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules
And make it executable
Code: 
chmod +x /etc/network/if-pre-up.d/iptables
Then reboot your server and try to login. (Because I dont know how to apply above without restarting. And restarting makes me feel more secured. )
Code: 
ssh jon@your-ip-address -p 55190
If you can't login after this, then there is a problem =)

Click here to view the article
 
Last edited by a moderator:
wlanboy

wlanboy

Content Contributer
I would add following lines to /etc/ssh/sshd_config

Code: 
LoginGraceTime 60
MaxStartups 3:30:10
MaxAuthTries 3
 
3

365Networks

New Member
To do this for dropbear is quite simple, on Debian/Ubuntu based systems:

Head to /etc/default/dropbear:

You may have a quite a few lines or you may have little, this just depends on how it was installed.


# disabled because OpenSSH is installed
# change to NO_START=0 to enable Dropbear
NO_START=0

# the TCP port that Dropbear listens on
DROPBEAR_PORT=51096

# any additional arguments for Dropbear
DROPBEAR_EXTRA_ARGS=-g
As seen above, you will want to have DROPBEAR_PORT=51096 on a line to change the default dropbear port.

To disable root password login, root logins, etc. you will need to have DROPBEAR_EXTRA_ARGS=xxxxx on another line.

-g = Disable password logins for root.

-s = Disable password logins

-w = Disable root logins

An example would be DROPBEAR_EXTRA_ARGS=-s to disable password logins on all accounts including root.

Finally you will want to service dropbear restart or /etc/init.d/dropbear restart to finalize the changes.

Not trying to hijack thread I just thought this would be great for other users to know! :)
 
Last edited by a moderator:
bbb

bbb

New Member
I'm not Unix guru, just a beginner (an absolute beginner), but I belive that using a high port by changing it in the configuration file is bad practice. Why?

  • Everyone's used to looking for '22' when checking for listening daemons.
  • A local DoS means that someone can replace the SSHd.
It's much better to leave it on port 22 but accessible from a higher port -- like the one you mentioned -- using iptables.

I'd also recommend disabling X11Forwarding and using the AllowUsers directive to only allow your shell accounts to log in via SSH.
 
Last edited by a moderator:
Ishaq

Ishaq

New Member
Verified Provider
bbb said:
  • Everyone's used to looking for '22' when checking for listening daemons.   
Click to expand...
Actually that's the whole point, people who want to brute use scripts that normally check for the default 22, so changing this is wise.
 
bbb

bbb

New Member
Ishaq said:
Actually that's the whole point, people who want to brute use scripts that normally check for the default 22, so changing this is wise.
Click to expand...
I was talking about when the administrator was working with lsof and such. 'Changing' the port by redirecting with iptables would still secure against this.
 
jcaleb

jcaleb

New Member
365Networks said:
To do this for dropbear is quite simple, on Debian/Ubuntu based systems
Click to expand...
dropbear is great, why cant the devs of normal sshd lower the memory consumption?  dropbear people have done it?  is it because they have different featureset?
 
acd

acd

New Member
bbb said:
I'm not Unix guru, just a beginner (an absolute beginner), but I belive that using a high port by changing it in the configuration file is bad practice. Why?

  • Everyone's used to looking for '22' when checking for listening daemons.
  • A local DoS means that someone can replace the SSHd.
It's much better to leave it on port 22 but accessible from a higher port -- like the one you mentioned -- using iptables.

I'd also recommend disabling X11Forwarding and using the AllowUsers directive to only allow your shell accounts to log in via SSH.
Click to expand...
And then someone fat-fingers a conntrack -F, or the firewall is turned off for some maintenance and then your ssh-to-highport gets reverted and your ssh session dies before you can fix it. If you're worried about a local DOS, write a script that checks for aliens and kills them on a cron. They shouldn't ever be able to kill ssh, and if they can, you've got far bigger issues. ssh is the one services that you need to "just work" when performing remote maint unless you've got a KVM tail on it; making it complicated by adding other subsystem dependencies is something I strongly recommend against.

#!/bin/bash

 

NOTIFYEMAIL=tw@localhost

 

ZOMBINS=/var/spool/zombins

 

#alternate ssh port:

PORT=5522

EXPECTEDBINARY=/usr/sbin/sshd

EXPECTEDUID=0

 

umask 0077

 

KILLLOG=`mktmp`

KILLUIDS=`mktmp`

KILLPIDS=`mktmp`

 

for pid in `netstat -lnp | grep ":${PORT} " | gawk '{print gensub(/\/.*/,"","",$7)}' | sort -u`

do

  uid=`ps -n -p "$pid" -o uid | tail -1 | awk '{print $1}'`

  runningbin="`ls -l /proc/\"$pid\" | grep exe | cut -d' ' -f 11-`"

  performkill=0

 

  if [ ! -z "$uid" ] && [ "$uid" != "$EXPECTEDUID" ] then

    performkill=1

  fi

  if [ ! -z "$runningbin" ] && [ "$runningbin" != "EXPECTEDBINARY" ] then

    performkill=1

  fi

 

  if [ "$performkill" -neq 0 ] then

    bzip2 -c /proc/"$pid"/exe > $ZOMBINS/"$pid".bz2

    echo "PID $pid listening on port $PORT as user $uid with binary ($runningbin) saved to $ZOMBINS/$pid.bz2" >> $KILLLOG

    if [ "$uid" -neq 0 ] then

      echo "$uid" >> $KILLUIDS

    else

      echo "$pid" >> $KILLPIDS

    fi

  fi

done

 

if [ -s $KILLUIDS ] then

  while read uid

  do

    if [ ! -z "$uid" ] && [ "$uid" != "root" ] && [ "$uid" -neq "0" ] then

      usermod -L "$uid"

      killall -u "$uid" -9

    fi

  done < $KILLUIDS

fi

if [ -s $KILLPIDS ] then

  while read pid

  do

    if [ ! -z "$pid" ] && [ "$pid" != "1" ] then

      kill -9 "$pid"

    fi

  done < $KILLPIDS

fi

if [ -s $KILLLOG ] then

  today=`date`

  hn=`hostname -f`

  mailx -s "Kill log for $today on $hn" "$NOTIFYEMAIL" < $KILLLOG

fi

rm -f $KILLUIDS $KILLPIDS $KILLLOG

jcaleb said:
dropbear is great, why cant the devs of normal sshd lower the memory consumption?  dropbear people have done it?  is it because they have different featureset?
Click to expand...
Yes. And because they use a different encryption library, but mostly because openbsd, where openssh originates from is not efficiency focused, it's security focused. If gaining memory efficiency means reducing code readability and obviousness of function, they will not include your patch. And how many people really scrimp for 3MB (approx the difference between openssh (~5.5 MB) & dropbear (~2 MB)) per incoming ssh session? Pay another 4$/mo and double your ram size.
 
vanarp

vanarp

Active Member
Thanks @jcaleb for the truly simple tutorial.

jcaleb said:
Because I dont know how to apply above without restarting. And restarting makes me feel more secured.
Click to expand...
 
To restart SSH one can use sudo service ssh restart command. It does not terminate your existing ssh session so that you can test new one with changed port number safely.

I think the command /sbin/iptables-restore < /etc/iptables.up.rules itself ensures new iptables rules are active. Of course bouncing the server is required to ensure the rules are picked after a fresh boot.
 
vanarp

vanarp

Active Member
jcaleb said:
On fresh install, login as root. First create a user you will use to login later, because we will disable root login after a while.
Click to expand...
 

I think it will be a good idea to add the new account to sudoers right after creating it. I use the command sudo adduser username sudo to perform the same. Hope this helps some!
 
  • Like
Reactions: acd
You must log in or register to reply here.
Top
amuck-landowner