Linux server security?

Forums › Linux › Linux server security?

tonyhughes

Hawkes Bay
8477 posts

Uber Geek

Mod Emeritus

Trusted

Lifetime subscriber

#112213 30-Nov-2012 15:23

Getting my previously dip-my-toe-in-the-water level Linux server and cli skills up to scratch.

Starting with some learn-by-doing in a VM, with Ubuntu Server (LTS), and getting all basic services installed, configured, working and secured (LAMP, mail, SSH, file, print, etc).

Beyond IPTables+UFW, deny everything, allow specifically whats needed, from where it's needed, disabling unused services, changing SSH port, using strong passwords, users/groups configured well, root disabled, using DenyHosts and fail2ban, a/v, antispam, and generating/analyzing/reading reports from logs, what else should I be investigating?

I have a bunch of websites lined up to read, many of which rehash the same information, but some of which have more information or avenues for security (or failure as the case may be).

Would be good to get some info straight from some of the knowledgable people around here.

tonyhughes

Hawkes Bay
8477 posts

Uber Geek

Mod Emeritus

Trusted

Lifetime subscriber

#725290 30-Nov-2012 19:44

Changes to the server relating to security only (e.g. haven't listed applications/services that are non-security related, or customisations to increase performance/reduce load).

So far:
Done:
Using LTS version of Ubuntu.
Automatic updates from Ubuntu activated.
Iptables denied all incoming, and allowed http, webmin, ftp, SSH (custom port)
Secured shared memory in /etc/fstab
SSH - disabled root login and changed port in sshd_config
Protected SU by limiting access only to new admin group and added my limited user account.
Prevented source routing of incoming packets, ignore ICMP broadcast reqs/redirects, block SYN attacks & log malformed IPs in /etc/sysctl.conf
Added 'nospoof on' to /etc/host.conf
php.ini edits: disable_functions = exec,system,shell_exec,passthru / register_globals = Off / expose_php = Off / magic_quotes_gpc = On
Installed DenyHosts (currently on stock config other than activating reporting)
Installed Fail2Ban and enabled SSH monitoring and reporting on bans made
Installed CHKRootkit and RKHunter
Installed nmap and scanned entire range for open ports - found only expected ports
Installed logwatch
Installed Tiger security audit and intrusion detection

Todo:
Restrict some services in iptables by IP address range (SSH etc)
Install antivirus software
Install apache2 mod_security and mod_evasive modules
Add ignoreip ranges to Fail2Ban, and configure DenyHosts and Fail2Ban correctly (investigate securing other services with them)
Install PSAD to detect and report port scans etc
Config CHKRootkit and RKHunter to avoid known false positives
Config or script installed tools to run and report automatically if not already setup to do so
Config logwatch
Config Tiger
Check apparmor config
There is nothing relating to mail yet, as I haven't installed any mail software yet.

Am I on the right track? What else should I be looking at doing? Anything superflous there?

Some of this is straight from advice in random internet guides.

I'm sticking with iptables for now, as I'm comfortable with allow/deny rules and the concepts of firewalling. Would I get any benefit from Shorewall et al?

Really I am wanting as basic a system as possible, to minimise the craziness if something goes wrong, or if I need to enlist outside help, but don't want to skimp on anything if it's needed.

tonyhughes

Hawkes Bay
8477 posts

Uber Geek

Mod Emeritus

Trusted

Lifetime subscriber

#725303 30-Nov-2012 20:22

Tiger report is very informative. A ton of warnings about things that are ultimately ok, so I'll have to learn how to filter the report that is generated. Tiger runs CHKRootkit and reports on its findings - great.

kyhwana2

2460 posts

Uber Geek

#725308 30-Nov-2012 20:52

Note changing the SSH port doesn't increase security. Infact, it decreases it if you put it above port 1024. (Since a local user could cause you sshd to crash and restart a trojaned sshd on the same port)

Klipspringer

2385 posts

Uber Geek
Inactive user

#725310 30-Nov-2012 20:58

kyhwana2: Note changing the SSH port doesn't increase security. Infact, it decreases it if you put it above port 1024. (Since a local user could cause you sshd to crash and restart a trojaned sshd on the same port)

I use to run mine on the default port 22. The script kiddies were hitting it many times a day. I have since moved it to port 443 and its not taken a hit since.

As added security I have switched off password login and setup sshd to accept keys only.

tonyhughes

Hawkes Bay
8477 posts

Uber Geek

Mod Emeritus

Trusted

Lifetime subscriber

#725314 30-Nov-2012 21:04

I read a lot on shifting the SSH port number, and general consensus seems to be simply stopping the annoyance of script kiddies constantly checking low ports (or port 22 in particular), and acknowledging that the actual security benefit is virtually nil - and that's fine.

Will look into SSH keys - but is this an issue if SSH is only accessible in the local network?

Why is the risk of a local user crashing SSHd and running a naughty one in it's place any worse on a higher port?

kyhwana2

2460 posts

Uber Geek

#725315 30-Nov-2012 21:09

tonyhughes: I read a lot on shifting the SSH port number, and general consensus seems to be simply stopping the annoyance of script kiddies constantly checking low ports (or port 22 in particular), and acknowledging that the actual security benefit is virtually nil - and that's fine.

Will look into SSH keys - but is this an issue if SSH is only accessible in the local network?

Why is the risk of a local user crashing SSHd and running a naughty one in it's place any worse on a higher port?

You can force sshd to only allow users with public keys, which makes bruteforcing attempts pointless.

If sshd is running on port 22 (or <1024) then you require root access to bind it to that port. Ports over 1024 can be bound to by any user.

tonyhughes

Hawkes Bay
8477 posts

Uber Geek

Mod Emeritus

Trusted

Lifetime subscriber

#725320 30-Nov-2012 21:17

So it sounds like a shift in port to anything free <1024 is probably a good avoidance of the script kiddies, without introducing risk of binding to it if someone manages to kill off the daemon.

Surprised I havent seen this written anywhere else if thats the case.

I didn't realise about the root access required below 1024.

Klipspringer

2385 posts

Uber Geek
Inactive user

#725323 30-Nov-2012 21:22

tonyhughes:

Will look into SSH keys - but is this an issue if SSH is only accessible in the local network?

Thats a question that probably only you can answer. Do you own or have full control to configure the local network including firewalls? If not then personally I would want to setup the system security as strong as possible.

insane

2415 posts

Uber Geek

Trusted

Subscriber

#725347 30-Nov-2012 23:35

Security is about layers of defence, as it only takes one mistake or vulnerability to leave you wide open. You've covered most of the things to look at on the server, but look at placing a FW in front of that server to stop unwanted traffic from ever reaching it to start with.

Kyanar

3148 posts

Uber Geek

Trusted

Subscriber

#738103 28-Dec-2012 18:23

One piece of software I can't recommend enough is CSF (ConfigServer Security & Firewall - available from http://configserver.com/cp/csf.html).

It's free, and will do such stuff as autobanning (with iptables) anyone who attempts to port scan you, brute force sshd, and that sort of thing. It will also alert you to any ssh logins and su usage (not sudo though).

I'd also recommend making sure that ACL support is enabled on your machine, and set up ACLs so your limited user doesn't have to su to root just to update websites. This took me a long time and a lot of trial and error, so I'll suggest that Google can probably explain it better than me.