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
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.
Comments
Thank you for the denyhosts suggestion, i have to check this out.
https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/
thanks for denyhosts was looking for a easy alternative to fail2ban
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.
@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.
@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?
Ah well then, what they write in that article isn't valid for me then, i'm the only user on my servers.
Booth are great
@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...
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.
You cannot make a comparison with only one side. What do you consider resource-light and what implementation would that be in?
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 ?
@Spencer i will adjust change to privlieged 222 port, then guide will be complete
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:
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:
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---------
@painfreepc Great addon
the sshguard guys say it best; see here:
http://www.sshguard.net/docs/faqs/#what-different-from-others
root ALL=(ALL:ALL) ALL
user-name ALL=(ALL:ALL) ALL
You probably shouldn't do this. Install sudo and run
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
@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...
It wasn't previously that's why it is mentioned
fail2ban works great.
Yep, using fail2ban here and CSF.
Better would a port like: xxxx or xxxxx
I also would recommend to use fail2ban instead of deny hosts.
OK bad idea? lol
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.