Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


[GUIDE] Basic steps to secure your Ubuntu / Debian server
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

[GUIDE] Basic steps to secure your Ubuntu / Debian server

drserverdrserver Member, Host Rep
edited January 2014 in Tutorials

This is tutorial for newbies and it will help you that you harden a little bit your ubuntu/debian server.

1) Update and upgrade apt and your packages

apt-get update && apt-get upgrade

By doing this regularly you will always have up to date packages and current fixes.


2) Change SSH port as most of automated brute force attacks and sniffers are aimed to port 22. You will do half of the job by simply changing port that port to some high port. Lets say 222 is our target port for this tutorial. SSHd config file is located here: /etc/ssh/sshd_config

What we need to do is to launch nano and change port variable from 22 to 222

nano /etc/ssh/sshd_config

Look for following:

Port 22

We have to change it to port 222 then save changes

Port 222

Restart sshd to apply the change

service ssh restart


3) Install DenyHosts

Basic idea of deny hosts is to prevent multiple continuous unauthorized login attempts on your ssh server

apt-get install denyhosts

There is no config file tuning needed if you wish to have basic protection. If you wish to play with it little bit more config file is located at /etc/denyhosts.conf


This will help you a little bit. Keep your system always up to date, change your root password regularly and you will be safe.

«1

Comments

  • Thank you for the denyhosts suggestion, i have to check this out.

  • akzakz Member

    thanks for denyhosts was looking for a easy alternative to fail2ban

  • Mark_RMark_R Member
    edited January 2014

    I read through that entire non-straight-forward wall of text and in the end he didn't name 1 valid reason why putting ssh on another port than 22 is a bad idea.

  • drserverdrserver Member, Host Rep

    @Spencer I am aware that 22223 is not privileged port. Also i am aware that 99% of low end vps servers are simple single (root) user environments. This is basic hardening so in my personal opinion i think that it is more beneficial to change ssh port then to leave it.

  • drserverdrserver Member, Host Rep

    @Mark_R

    It is possible than other (non root) make port listener and spoof his malicious app to collect root user and pass. However i think that ssh will always be run before user scripts

  • Do you think denyhosts is better than fail2ban?

  • @drserver said:
    Mark_R

    It is possible than other (non root) make port listener and spoof his malicious app to collect root user and pass. However i think that ssh will always be run before user scripts

    Ah well then, what they write in that article isn't valid for me then, i'm the only user on my servers.

  • drserverdrserver Member, Host Rep

    @catalystium said:
    Do you think denyhosts is better than fail2ban?

    Booth are great

  • Shoaib_AShoaib_A Member
    edited January 2014

    @drserver Thanks for posting the basic hardening tutorial for Debian/Ubuntu, hope to see you doing one for CentOS/RHEL as well :) I am not a newbie but still I appreciate that you are trying to help people who are new to Linux

  • A very well written article that will probably save me several hours in my life of explaining this concept to people and why it doesn't work.

    Ontopic: that said I don't support moving the SSH port, I do appreciate the denyhosts suggestion. You should replace port swapping with teaching people to use proper key authentication instead...

  • @catalystium said:
    Do you think denyhosts is better than fail2ban?

    Fail2ban is far more powerful and can be used for other listening services other then just ssh.

    Both suck in the sense they use python and therefore use more resources.

    Check out sshguard.

  • darkshire said: Both suck in the sense they use python and therefore use more resources.

    You cannot make a comparison with only one side. What do you consider resource-light and what implementation would that be in?

  • howardsl2howardsl2 Member
    edited January 2014

    I wrote up a detailed IPTables security guide at my tech blog at this link. Anyone interested can take a look. Although it is for Asterisk server, you can just disregard that one section related to Asterisk.

  • Any comparison between the denyhost to fail2ban, I like fail2ban, as it also defend other services.

  • Seems fail2ban can do more than just SSH and denyhosts is just for SSH. How much better on resources is sshguard than fail2ban @darkshire ?

  • drserverdrserver Member, Host Rep

    @Spencer i will adjust change to privlieged 222 port, then guide will be complete

  • painfreepcpainfreepc Member
    edited January 2014

    additional steps i do:

    Get two Ultra High Security Passwords from: https://www.grc.com/passwords.htm

    use 1 for root and the other for new-user

    Change Your root Password (if needed)

    passwd

    Add New User with root rights

    adduser user-name

    Give New User Root Privileges

    "export VISUAL=nano; visudo"

    Under root, add the following line, granting all the permissions to your new user:

    # User privilege specification
    root    ALL=(ALL:ALL) ALL
    user-name    ALL=(ALL:ALL) ALL
    

    Type ‘cntrl x’ to exit the file.
    Press Y to save; press enter, and the file will saved

    Add new user to SSH

    nano /etc/ssh/sshd_config

    Edit the following lines and save:

    Port <your port number>
    UseDNS no
    # YES you add root and other users on same line
    AllowUsers root user-name
    

    Type ‘cntrl x’ to exit the file.
    Press Y to save; press enter, and the file will saved

    Restart sshd to apply the change

    service ssh restart

    Test new settings (don’t logout of root yet),

    open new terminal window and login as your new user.

    Don’t forget to include the new port number

    now check to see if you can get root access

    type the word
    "sudo su"
    or
    "sudo -i"
    press enter

    enter password

    Your prompt should now say:
    root@yourhostname:~#


    may be a good ideal to logout of new-user and open new terminal

    to see if you can still login as root

    if all is ok, you now have root access as new user,


    Now reboot and login as new-user

    type the word
    "sudo su"
    or
    "sudo -i"
    press enter

    Note: "sudo -i" unlike "sudo su" only needs to be typed once

    Now lets remove root password

    sudo passwd -dl root

    ---------NOTE---------

    i don't use key, if someone can hack a 63 random alpha-numeric characters PW - God bless them

    "9miohq4AozopkVUfTFzzMWSShqoOgD7ZZck9Wo1JxpKZ58l4yfUFxk10sG24Uw9"

    i do not remove root from ssh login

    i just disable the root account password

    "sudo passwd -dl root"

    when i need the root account

    i enable the root account passward

    sudo passwd root

    when i am done using the root account i disable root password

    "sudo passwd -dl root"

    ---------NOTE---------

  • drserverdrserver Member, Host Rep

    @painfreepc Great addon

  • @catalystium said:
    Seems fail2ban can do more than just SSH and denyhosts is just for SSH. How much better on resources is sshguard than fail2ban darkshire ?

    the sshguard guys say it best; see here:

    http://www.sshguard.net/docs/faqs/#what-different-from-others

    Thanked by 1catalystium
  • painfreepc said: Under root, add the following line, granting all the permissions to your new user:

    User privilege specification

    root ALL=(ALL:ALL) ALL
    user-name ALL=(ALL:ALL) ALL

    You probably shouldn't do this. Install sudo and run

    sudo usermod -aG sudo user-name
  • What black said.

    No love for CSF?

    Moving the port SSH uses is only security thru obscurity and only cuts down on the noise in the logs.

    Security is a process not a product, and if a person is serious about having a server accessible to the public internet, they will need to learn to read logs and take note of how their system behaves normally so they can know if something is wrong with it (misconfiguration/owned/etc).

  • also @drserver clearly in the guide put 222 which is still a privileged port :)

  • edited January 2014

    @Mark_R

    Agreed, I read all as well could not find a valid reason not to change default 22 port

    ( I never use port 22 maybe as a honey pot).

    rsync -e"ssh -p[yournewporthere]" ...

    scp -P[yourenewporthere] ... (note capital P)

    ssh -p[yournewporthere] ...

    and you are set.

  • Writing one up for CentOS now, since it was requested...

  • @wojons said:
    also drserver clearly in the guide put 222 which is still a privileged port :)

    It wasn't previously that's why it is mentioned :)

  • fail2ban works great.

  • Yep, using fail2ban here and CSF.

  • NeoonNeoon Community Contributor, Veteran
    edited January 2014

    Better would a port like: xxxx or xxxxx

    I also would recommend to use fail2ban instead of deny hosts.

    OK bad idea? lol

  • sleddogsleddog Member
    edited January 2014

    said: by simply changing port that port to some high port. Lets say 222

    Technically port 222 isn't a high port. All ports below 1024 are classed as well known ports, and associated with a service.

    If someone port-scans you, they may well scan the well known port range.

    So if you're going to move it, move it to a high port -- above 1024.

    Most of the arguments against moving it are centred around confusion, i.e., in a multi-user scenario some users will try to connect to the standard port and fail -- creating a support issue. For a personal server it doesn't matter.

    I always firewall the ssh port. Even if you have a dynamic IP, your ISP works within a limited range, so you can allow that range (or ranges, like me). You can setup a basic, static iptables firewall with a few config files without a full-fledged solution like CSF.

    fail2ban is (IMO) the solution of last resort. For a lowendbox it's a memory hog.

Sign In or Register to comment.