Prometeus - Your 'net consultants !

Let's face it, many of us want an internet presence but have almost no clue about how to keep their internet "real-estate" secure.
We all heard of hackers and they seem something inevitable, only luck can keep them away etc. Trusting your luck is not a good policy in any area, being informed and proactive is a generally good strategy.
It has been said that if you don't know linux or how to secure your server you should stay with Windows and shared hosting...
Staying with Windows is WORSE than with Linux securitywise. Windows is hacked even at home behind firewalls and hordes of zombies (captured windows machines controlled by hackers without the owner's knowledge) are proving this every day sending DDoS, probing for security holes, being spam machines and proxies that criminals use to hide their identity, etc.
As with shared hosting, one careless user can expose the database and the whole server in cases.
Nothing is certain, of course, but the chances to be hit by a truck if you are looking when you cross the street are much smaller than if you are not looking and listening music at full volume or talking on the phone.
This article is gonna be long, this is the first part with basic explanations, and at the end there will be the steps anyone can take to secure their Linux VPS even if they are not experienced sysadmins.

Services and ports

Once you have a machine on the net with a public IP all it's ports are visible from the internet. Think of ports like the apartments in a block, from 1-65535 are available for any IP address which is like your street address. That is a huge number, agreed, but very few are actually used, meaning the vast majority of the apartments have a locked door from day one and it is highly unlikely anyone will move there.
There are, on the other hand, some that have to be used, otherwise it is meaningless to have an internet presence, what is the use for a large building if the main door is locked and nobody lives there ? Only to pay taxes and rent ?
So, at least one port must be open, the one you connect from the internet, the ssh port. When you open putty and connect, you are connecting to a port, usually port 22. This is like the administration for the building, you must have access to the administration if you want to do anything with it. You can also use it for other purposes, such as proxy/vpn, but the main use is to control the machine.
Depending on what we want to do with our machine/building, there must be other ports/doors accessible from the internet.
For example, this board is hosted on a VPS that uses a webserver to deliver the contents to your browser. This is running on port/apartment 80.
When you type board.prometeus.net, your browser (internet explorer, mozilla, chrome, safari, etc) assumes you are going to the port/apartment number 80, because that is the location of a webserver and this is what browsers are used for, to connect to webservers, mainly. If port 80 on this machine will be blocked, the browser will knock on the door and if nobody answers will tell you the tenant at that address cannot be found. Whether it is so all the time or just gone in a vacation, your browser doesn't know.
So, in order for this board to work, there must be a webserver at port 80 and the port 80 must not be blocked (door locked).
We already have 2 ports and 2 services listening to external connections. Like the tenant is there and hears the doorbell and goes opening no matter who is out there (browser for port 80) or asks for the password before opening (ssh on port 22).
Once they opened the door, the dialog starts. Like the visitor says to the webserver (notice the word server) give me the page about security and as long as it knows the link (from other boards or wherever it got it from) the webserver will not ask any questions, just hand out the data. If, on the other hand, the visitor wants to write something here (post something) the webserver will give the authentication page instead, because this is how it's reactions are scripted in the code of the page. Visitors cannot post if not authenticated.
Ssh, on the other hand, will only ask for password (or key) if someone knocks on the door, as long as the password is not correct, will not do anything else, even more, depending on the configuration file it has, after a number of bad passwords will kick the visitor in the street so they will have to come back and start over. Even more, if the configuration says so, the ssh in flat 22 will call the concierge and demand that visitor such and such will not be allowed on the main door under any circumstances (IP banned).
Now, lets take the 2 cases of an automated hacker attack. Drones looking like humans, knock on doors and try various passwords (ssh) or try to obtain from the webserver on port 80 the keys of all flats in the building, instead of just the regular pages it should give them.
In the case of SSH, there is not much else to do, just try passwords over and over again. If we told ssh to call the police and lock the door after a number of failed attempts, there has to be another drone to try them and it is not practical as the hacker must have many drones and a script to keep track of which drone visited already and send another all the time. Also, if our ssh is, instead, in another flat, our drone won't start knocking on all doors till someone asks for the password, will simply give up most of the time.
That is the normal cases when we took some security countermeasures. If, instead, we put password for root user such as root or toor or bob or 12345678, then chances are the drones will tell the correct password from their list of mostly used passwords by people which do not care about security or have no clue about how a password should look like. In this case, the drone will report home they managed to pass as the rightful owner and SSH gave them the keys from all the building, including the ones from the control panel of utilities and they practically control the whole building. The drone owner (hacker) will then proceed to make a drone factory in our building and send them around to find more poorly protected buildings and also use this one for other malicious purposes, such as selling it's bandwidth for DDoS, hosting child porn or phishing sites to steal passwords and money, or sending spam, anything to make a buck while police will look for the owner and the host will shut you down because you are too irresponsible to own some real estate on the internet. If, however, our password is something like MyPa$$_Vvord/Excel/2012, there is no chance in hell any drone will have that on their list, so won't be able to enter in the first place. If, also, we use a tool called fail2ban (the red line to the concierge to tell it to keep out such and such visitor after a failed number of passwords) then the drone has even less chances because his tries are limited to a handful before is kicked. If, also, the ssh port is not the usual 22, but something else, like 22022, 12322, 64133, or any other combination, the drone will usually give up when nobody will answer the number 22 door. We can also allow only someone coming from a certain address to enter the building, like only your IP at home or from another VPS will have even the chance to knock on the door, all the others will be stopped in the hall.
See ? It is not so hard to defend against brute force attempts (trying passwords at random).
Let's see how to defend against other attacks, such as those on certain services, like the webserver on port 80.
Suppose a browser or someone pretending to be a browser comes to our number 80 door and asks something unintelligible, like give me SELECT FROM TABLE row,column INSERT X VALUE or something along those lines. A very old and partially deaf tenant will probably try his best to do his job and do what the visitor asked and this might be changing the password from the forum's database to allow the hacker to read/modify it, so visitors to this forum will be redirected to his malicious sites to infect them with some virus and take over their computer. Or simply ask for the file containing the password directly.
A young and trained webserver will know better than comply with such requests and will simply give the standard answer 404-not found, or 302-forbidden sending them on their way and also keep a diary (log) about that malicious visitor so the owner will know and contact their host/isp or send police on their tracks. Unfortunately, that is another poor victim of bad password/old software used by the hacker and not the hacker address itself.
How does this translate in our case ? It means we need to keep our services (in this case the webserver) which are exposed to the internet up to date so the hackers will not be able to use known methods of social engineering or simply the force to knock down the service and do what they please with the site and, at times, with the whole server.

Firewalls

A firewall is nothing more than a special lock that verifies the visitor to comply with some criteria before allowing access. For example, it can limit the number of connections to some ports (so a spammer won't be able to send more than x mails a minute/hour, etc, for instance), can verify if the visitor comes from a few selected addresses and only then allow them in, can verify if the visitor comes from another number of addresses and deny their access and let everyone else in (for example block a known list of spammers/abusers/hacked computers), can block certain IPs after the services they tried to access told it so. It is the equivalent of the concierge or doorman at the main gate. it can also have complex rules like: If the visitor is not from x address, is looking for port(door) xxxxx and has not been connecting for more than x times before, let it in. Failing any of the checks blocks the access.

When is a firewall needed ?

Whenever we need special and complex access rules. Each service can be configured to block certain IPs, interfaces, only listen to certain type of packets, but if we want really complex things which our services configuration files do not support, we need a firewall.
We DO NOT need a firewall in most cases. For example, we only have ssh and HTTP (webserver) active (doors 22 and 80). These can be configured to deny/allow easy from their internal configuration files, but if we have tens of services and ALL must deny access to certain ranges of IPs (for example block a whole country) then it is easier to do this in the firewall, at the main door.
If we have just a few services, we keep them updated regularly from the official repositories of our Linux maker, we don't have to put up a firewall, it inserts another SPOF (single point of failure), if you misconfigure it you can block everyone out, including yourself, inserts more lag (tho minimal) and uses some resources (tho, also minimal).

The next part of this tutorial will present you the practical means to achieve security, with command examples and software usage.

Admin

thanks admin, looking forward to next installment

Hello again :)

For those landing here due to the announcement we sent asking you to keep your OS updated, it does not mean we have info you were hacked in particular, but you should keep your OS updated to prevent such a thing!

We saw what the threats are, let's see what we can do to stay out of harm's way.
First, I must tell you that, if some good hacker is after you, chances are he/she will get through. Will stalk any 0 day exploit in your software and act before you do, or even design special exploits, people at NASA or FBI were hacked, so, nobody is really safe, but we can defend against script kiddies or automated probes/exploiting which account for 99.99% of attacks each day.
Let's start with the basics:
1. Choose a right password and don't save it on your pc, especially if it runs windows. There were special viruses that were reading your ftp/ssh passwords and used those to infect your files in the server so your blog would redirect to malware sites. If you can't remember them, either send in your mail, stick them to your monitor or use something easy to remember but long enough so no hacker would guess. ButItIsEasyToRemember is long enough to be uncrackable by regular bots, and even special ones, also very easy to remember, IF you can't use the other methods (mail/stick-it note). You should, of course, use something else than my example, like a first verse of your favourite poem, Isaia12:13 is also a good one, use whatever you can remember easily and has either special chars and more than 8 chars or is long enough (6-8 words should be ok). Also, don't give out your password to "friends" or people which "offer" to install things or help you with things unless you know them. Having a good password is meaningless if anyone can obtain it from you after a simple request. At the very least, change it to something simple like abcdefghijk before you hand it out and reverse it to the old one after whatever intervention needed is done. This includes all passwords, including those from the system or scripts.
2. Keep your software up to date ! This is very important, not only for windows, linux is vulnerable too, if old enough, even Unix flavours such as BSD can be exploited if not kept updated. For linux, the 2 most frequently used distros (and their offspring), Debian and CentOS, it is simple, run from time to time: and for Debian-like ones (Ubuntu is included here) and for CentOS-like (fedora is included here). Answer yes to prompts if any.
It goes without saying that your own scripts or third party ones should be also kept up to date. For example PHP scripts such as forums or blogs, must always have the latest version installed. And, of course, add-ons and plugins to those third party scripts too !
3. Keep your exposed surface small. This means you should only install what you need. Also, it means that, if you need compiler tools to compile something, you should remove them after the job is done. The more software you install and the more ports that software listens too, the more chances for a hacker to find exploitable security holes. If you don't need DNS server, remove bind, for example, if you will not use a webserver, remove it, mail servers also, etc. Use netstat command to see listening ports and which software is using them, maybe you don't need all of those daemons. They take resources and are a liability if not needed for the purpose of the VPS. "I might need it later" is not a valid excuse, you can "apt-get" or "yum" them at any time.
This applies to your scripts too, for example, don't add any plugin for your blog/forum if it is not really needed. It adds a new attack target.
4. Listen to lo if possible ! lo is the local, fake network interface which any TCP/IP capable device has. It has the advantage it is not exposed to the internet and local programs can use it to exchange data with other programs which are not listening to the internet. For example, your local database doesn't need to listen to the internet, you can use local interface and make local programs to connect to it by pointing them to "localhost" instead of the IP of the VPS. Other programs can use local Unix sockets, try to use those as it is much safer than opening ports to the internet. If you need a mailer daemon for local purposes, this is the normal setup.
5. Do not give root privileges to programs ! Run them as low privilege users or chroot them at least. This means you should not start any program while you are using the root user or give read/write system-wide. Doing so, everyone can read your passwords, for example. If something does not work because of privilege problems, don't just chmod 777 the directory, investigate the problem and apply the right owner and privileges.
6. A firewall is one more point of failure and should only be used when needed. Unlike windows, when a firewall is needed more or less in any situation because nobody knows what security holes are left unpatched and updates are not very fast, security in linux is much more tight, there are other safeguards in place, even if a program has been compromised, it is rare that the hacker can take over the system if the right permissions are in place.
That being said, there are situations when a firewall is needed, for example when you need complex rules that apply system wide, or to limit access to some IP ranges, countries or providers, things like those. Do not install a firewall "because it is a good thing". Always keep your installation minimal, and this includes the firewall. Install one only when you cannot limit access well enough using the configuration files of your installed services.
7. Use non-standard ports for your services if possible. This twarts most automated attempts to check for exploits and try brute-force the passwords. Personally I do not believe this is such a good measure, besides I have a problem remembering those ports and it is not rare that I have to probe all ports to find the one I moved the service on. If this is not a problem for you, use it, one more line of defense against bots, but it is easy for a human to find the real port.

Admin

hello admin. lately, i am using passwordless ssh login using keys because it is convenient. is there a security flaw with using key pairs that we should be aware of?

No, atm there is no known exploit, but keep your ssh up to date.
Actually, using keys is way more secure than password.
To give an example based on the tutorial, the most secure way to login with SSH is to do this way:
Password+key logins on non-standard port on another account than root (don't allow root login) which will sudo and allow only a few IPs you have, such as other VPSes. Of course, passwords will have to be 24+ chars long, include space, special chars such as )(*&^, numbers, capital letters and non-capital. I think you can't go more secure than that Adding fail2ban will go too far

Admin