0

I'm running an VPS where I have deployed some projects. As I am the only person who accesses the server and I furthermore have a fixed IP i decided to configure iptables so that server access is only possible from my fixed IP.

Because I am very concerned about security issues, I am not really sure if I do have to additional things to secure my server when only my fixed IP has access.

Are there additional security improvements which I have to consider?

mhmpl
  • 103
  • 2

3 Answers3

3

There are plenty of things to consider however it depends on what sort of setup you have any what you want to secure.

Here are a few things to consider:

  • no password for ssh access (use private key)
  • no root access for ssh
  • using sudo for users so commands are logged
  • log unauthorised login attempts (and consider software to block/ban users who try to access your server too many times)
  • ssh on non-standard port
  • make sure things like ipv6 are locked down if not using them
  • keep software up to date (os, web server, scripting language, CMS)
  • remove any software you dont need
  • make sure file permissions are locked down (especially for things like user uploads)
  • limit the people who have access to the server
  • password protect admin area for CMS at the web server level
  • use SSL for admin area's and other sensitive data
Drew Khoury
  • 4,637
  • 8
  • 27
  • 28
  • All of these are great ideas, but if this server is truly only ever going to be accessed from the OPs static IP, and only by the OP himself, many of these are overkill IMHO, even if they are considered best practices. – EEAA May 12 '13 at 14:27
  • You might consider them overkill, they're only considerations. OP needs to decide how far they want/need to go. Considering I.P's can be faked it's very important to use private keys for ssh and not allow root access for ssh. Assuming only that I.P will ever be able to connect, and that OPs computer or network will never be compromised is not a safe bet. Most of these are not overkill IMHO, they're sensible security considerations. – Drew Khoury May 12 '13 at 14:31
  • Tell me how IPs can be faked. UDP? Yes. TCP, no. – EEAA May 12 '13 at 14:55
  • An IP can certainly be faked. TCP connection would be more difficult. But it's hard to know what sort of information an attacker can gain, or what sort of damage they could do. The considerations I have are common sense for securing a server. – Drew Khoury May 12 '13 at 15:04
1

For development purposes, restricting by IP is sufficient to prevent most malicious parties. However, you still ought to be concerned about cleartext information being sent back and forth. If possible, always use encrypted channels to interact with your server: SSH for administration and file transfer, HTTPS, etc.

For more information on this, please see the answers to: Tips for Securing a LAMP Server.

Community
  • 1
EEAA
  • 109,363
  • 18
  • 175
  • 245
  • There are many aspects to security. Locking down SSH access via IP is a great start, but my no means a sufficient security practice on it's own. I urge you to consider all aspects of your server and code when thinking about security. – Drew Khoury May 12 '13 at 14:36
  • Seriously? Of **course** I implement extensive security measures (many you mentioned and many more) on my production servers. But on a personal server, firewalled off from the world? Not necessary. – EEAA May 12 '13 at 15:01
  • OP came looking for "additional security improvements to consider", not the bare minimum effort required. I'm not sure of the specifics of the OP's server so I would err on the side of caution. At the end of the day we both have sensible answers that others are free to comment and vote on. – Drew Khoury May 12 '13 at 15:09
1

I use the same measure, and sleep better!

TIP 1: You should have a provider with real working restore ability. I have one and used it once. I keep hearing rumours of providers that have restore ability in name only.

You can get hacked regardless of your measures, it may come through a hacked laptop of your server company, through a server software company, some linux vulnerability etc. You may never know how. The solution for a hacked or rooted vps account is only one, full restore from a backup of an estimated clean date.

TIP 2: In regards to software passwords, be attentive about tiring days, and 'I will change it in a few minutes' passwords, and old unused unimportant left aside cms websites that one neither checks nor updates.

My little experience is, the attack, if any, will come from website software. Or at least, that is certainly what you will be accused of by your web hosting company.

Protecting root with ip rule prevents the attacker from gaining root access using SSH. But nowadays when a vps is hacked, the payload is the websites themselves, the emails in databases, the php files that the hacker infects. Who cares about root access, sort of. But you are right, it is one thing to get hacked, another thing to be rooted.

Beware of this: When one has a lot of projects and while years pass by, on a tiring day, while working on a test project, one just cannot be bothered with finding a long password or cannot be bothered to have another admin login than 'admin'. One thinks one will change it later. And that one mistake is usually enough.

You must have no exception policies about all your cms passwords, never use admin as admin user name, and update your software as much as feasable.

TIP 3: Iptables firewall rules, they may not be protecting VPS GUI area logins from different ips.

For example, one can use etc/hosts.allow file to ip filter ssh logins AND admin panel logins. You should ask support to do it and then also check that file yourself.

TIP 4: Stronger account separation between websites.

Cpanel or any other, the default separation between accounts is weak as of 2013. One account hacked into > script person reaches all accounts in a few minutes > reaches all databases > server is as good as rooted. Please see http://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242.html for 24 pages of fear. Solution: ask your web host to install symlink attack protection AND also if possible chmod 600 for config.php and any other database information files ( http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/ ). 

//some symlink protection between user accounts, if you know what you are doing
//list files: web root >
find -type f -regex ".*config.php" -exec ls -lh {} \;
//change permissions
find -type f -regex ".*config.php" -exec chmod 600 {} \;
Johan
  • 122
  • 3