Security tips

[uteck]

Previously I have mentioned DenyHosts as a good program for preventing brute force attacks on your ssh password. Here is a program that extends that and allows other applications to be protected in a similar manner.
http://www.fail2ban.org/wiki/index.php/Main_Page
Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.

[danieldk]

I heavily recommend people to avoid the use of denyhosts or fail2ban. Both tools have security errors more often than the daemons they suppose to protect (e.g. OpenSSH), and allow remote manipulation of your host access tables, or even worse, packet filter via IP spoofing and other techniques.

If you really want to protect OpenSSH, Apache, etc. a few simple rules will make your configuration a lot more secure:

- Use kernel/glibc/gcc with techniques for vurnerability mitigation (e.g. the RHEL/CentOS/Fedora use many such techniques.
- Use a mandatory access control framework like SELinux.
- Use different filesystems for things that users have write access to, e.g. /home, /var, and /tmp for two important reasons:
- Users will not be enable to hardlink system binaries to keep vulnerable binaries around after a security update.
- You can mount these partitions with sensible combinations of the noexec, nosuid, and nodev flags.
- Use OpenSSH with RSA keys, and not password authentication. A cracker needs two things with RSA authentication: the private key, and the password for the private key. Which is a lot harder than just a password.
- If possible, restrict OpenSSH access to trusted IPs. E.g. many webservers need SSH access from just a few addresses.
- Update often, make sure that the latest security fixes are installed.
- Tighten up whatever network-facing daemons you use. E.g. Apache runs on most distributions with all included modules enabled, where often only a handful are required.
- Restrict the users that can su or sudo to root, this can easily be done with PAM.
- I didn't want to say it, but: don't use PHP software. Many PHP applications are written badly, and it's quite hard to get PHP secure.

This provides far more security than denyhosts or fail2ban, both may block automated scripts (who do no harm if you have no trivial passwords), but won't really stop any seasoned hacker, and will (IMO) only make a system more insecure.

Remember that most of the holes in well-updated systems are created by the system administrator, or a lack of tight policies.

[fos]

This is a good topic. Anyone that has a presence on the web must take security issues seriously.

.... don't use PHP software. Many PHP applications are written badly, and it's quite hard to get PHP secure.

Many (most?) interactive / dynamic web applications are written in php scripting language. The commercial products like this BBS software must continually upgrade to stay on top of security.

What is a better alternative?

fos

[danieldk]

I personally like Python for web applications, but they are not as widely available as PHP applications. I write most of the Python web stuff I deploy myself. I deploy lighttpd with each Python web application running as a fastcgi server (with Django as the Python web framework). I am currently working on a SELinux policy for lighttpd (it is mostly finished, but needs some more testing/cleaning).

BTW, another security tip: divide your physical server into multiple virtual machines with Xen, and use one VM per function. E.g. if your webserver is for some reason compromized, it does not affect your mailserver. Of course, this requires having multiple IPs.

[fos]

Using Xen to divide the server into virtual machines is a great idea, not to mention sharing resources accross multiple servers. Thanks to RH that is a much more viable option. Thank goodness the cost of hardware is coming down. Parceling out system resources is becoming much more cost effective.

I had hoped to co-locate a server to experiment with but colocation costs have gone up considerable during the last several months. Renting is much better financially. LayeredTech is offering virtualization on a big scale. That is not what I had in mind but it may be the way of the future.

[danieldk]

Hmmm, I think we pay Euro 50 for a 1U rack with 300GB bandwidth. Though, with less bandwidth, it's possible to colocate for ~20-30 Euro. The server investment is the most expensive side.

[fos]

Why are python based scripts more secure than php?

Is it the expertise of the programmer or is python inherently more secure?

[uteck]

I have been using DenyHosts for a few years and not had any problems, nor heard of any. It has added hundreds of IPs to my deny list and that alone makes me feel safe, especially since I changed the default from only denying ssh access to denying all access to my box.

Kind of odd that you say not to use it, but then recommend Python web apps, since DenyHosts is written in Python. :) I could tighten up my security, but I can't guarntee that I will have my ssh key with me, or the IP I will access it from. And there have been a few times were I allowed other people to access my box, and the 'lose' security I have made that easier for some of them.

Perhaps someday I will rebuild it using CentOS so I can use SELinux, but in the meantime, these apps are better then nothing.

[danieldk]

Why are python based scripts more secure than php?

Is it the expertise of the programmer or is python inherently more secure?

Both. Python programming usually requires a programmer to have at least some clue ;). Second, Python is far stricter. It has strict typing, and if something goes wrong, throws an exception, where PHP applications often continue to run. If a program does something that is really messed up, it should just throw exceptions, not to try to continue ;).

[danieldk]

I have been using DenyHosts for a few years and not had any problems, nor heard of any.

Ask any experienced security expert. The thing is that this stuff is not fooled by automated scripts that most kiddies use. But it will provide a nice attack vector to more seasoned hackers. Though, they will only taget you if you are interesting (i.e. a popular site or company).

Security is as bad as it's weakest link. Look up how often OpenSSH or Apache are remotely exploitable. Almost never. There are security bugs in Apache every now and then, but mostly in modules that most people shouldn't have enabled anyway. Even when a vulnerability is found, it can often be mitigated with stack protection, etc. and SELinux. Additionally, errors in OpenSSH and Apache are usually fixed the same day. In other words, if you use these programs, have a secure distribution, update when updates come out, and don't mess up your configuration, chances to be hacked are virtually zero.

Then you add denyhosts. A program, which has seen more critical security errors than OpenSSH or Apache in recent times, is not carefully audited. Which is not confined by SELinux. And is based on wrong assumptions of security (allowing remote attackers to manipulate your access control).

In other words, you are adding a very interesting weak link to an otherwise strong security chain.

It has added hundreds of IPs to my deny list and that alone makes me feel safe, especially since I changed the default from only denying ssh access to denying all access to my box.

There is a difference between feeling safe and being secure. E.g. a lot of people recommend to run SSH on another port. And it makes them feel safe. It won't leave a serious hacker suprised for less then a few seconds. It's a false sense of security.

Aditionally, if you really want to have such a scheme. iptables/netfilter can do it. It doesn't scan your log files, run as a root application, etc. So, it's far more safe. Just block everything that tries to log on more than N times.

Kind of odd that you say not to use it, but then recommend Python web apps, since DenyHosts is written in Python. :)

We were talking about web applications, that run in a confined environment (e.g. a separate SELinux security context, that can't touch anything else than it's own resources), not a program that can be fooled and has access to virtually every system resource (or at least your packet filter tables and host access table). What was the last time you ran a web application as root? I hope never.

I could tighten up my security, but I can't guarntee that I will have my ssh key with me, or the IP I will access it from.

I have an USB key that I always take with me. On it there is a separate partition that is encrypted with LUKS, with the stuff I need. Because the encryption with critical stuff is encrypted, it will do no harm if I lose this key.

And there have been a few times were I allowed other people to access my box, and the 'lose' security I have made that easier for some of them.

Let them give you their public RSA key. Then they can log in in a secure fashion too ;).

Perhaps someday I will rebuild it using CentOS so I can use SELinux, but in the meantime, these apps are better then nothing.

[uteck]

I still think you are over exaggerating the ability of people to exploit a script that may not have network access. By default the sync function is turned off, but the ability to download a few thousand know bad IP's is good to have and can be turned off after the first run. Even if it is left on, the most likely avenue of attack is if someone hacks the Sourceforge server. If all these bot nets and attack drones can't even create any sort of link with my server then it is very secure indeed. http://stats.denyhosts.net/stats.html

You use yum on your SELinux boxes, so you are also extremely vulnerable to a hypothetical hack. Yum is run with root privileges, so don't run it. (insert the joys of SELinux here) but I don't have it istalled, so I don't have to deal with it locking me out of other services and being a big pain in the arse to configure.

For my needs, Firestarter and DenyHosts work nicely and don't demand too much attention. Great security means great pains to do the simple things.

[danieldk]

Sorry, I am not going to rehash the same arguments. As I said, you add a weaker chain to solve something that is not a problem in the first place, unless your system uses passwords like 'test' or 'password'.

Wrt. yum. This is a different issue, because it does solve a problem. Of course, you could rpm -Uvh your RPMs manually, but yum is much smarther in getting the correct dependencies to keep your system running. Anyway, every package is signed. The repodata is also hashed. I am all in favor of signing repomd, yum's authors are too.

That said, yum runs in an rpm_t context on SELinux, so you can restrict its access privileges.

[fos]

Well, I'm definitely convinced.

Daniel, can you recommend a good text covering python and mysql scripting?

Thanks, fos

[danieldk]

Django is a very nice Python framework for writing web applications. It also has a database abstraction API, making it possible to let your application run on MySQL, PostgreSQL, and SQLite (handy for development and testing). There are two good free online resources that also include many examples:

http://www.djangobook.com/
http://www.djangoproject.com/documentation/tutorial01/

For Python I can recommend "Learning Python". If you want a free book, this one is good too:

http://greenteapress.com/thinkpython/

BTW. If you need Django for CentOS 5, I have it prepackaged for my own needs. I can give you the address of my repo.

[fos]

Thanks for the links, especially the one for Green Tea Press!

Django does look interesting. I would like to install it on my CentOS 5 installation. If the learning curve isn't too steep maybe I can get something up while I'm off this summer.

BTW, the least expensive colocation I have found in Houston is $90 per month including 500GB transfer. A 2U server is significantly more. I can rent a server with 1500GB transfer for $20 less than that. :confused:

fos...

[danieldk]

Hmmm. Bummer. Isn't The Planet in Houston?

[fos]

The Planet server farm is in Dallas. They were a very good company until they merged with a Houston based company called PeoplePC. I had a bad experience with PeoplePC a couple of years ago, but that is a long story.

HostGator bases most of their server business with The Planet. I always received excellent service and support from HostGator. I rented space from them until I rented the dedicated server that I'm running now. I had been with HG since their early days and would go back if they offered self-managed servers. HostGator's home office is in south Florida. They have recently opened a very large support center here in Houston. I was shocked at its size as I drove back from a trip to Austin recently. HostGator's owner once answered a support on a Sunday morning when I was having the issue with PeoplePC. It was caused by PeoplePC but my only solution was to change to another ISP. Brent is a class act and HG is as well.

There has been a lot of chatter on WebHostingTalk that The Planet has gone downhill since the merger. It is a shame if that is true.

Colo4Dallas is a very good colocation provider, but Dallas is a 3 hour plus drive from Hoston.


fos

[Lavene]

Fos,

Just want to mention another excellent free Python book; Dive Into Python. (http://diveintopython.org/) It's fairly "down and dirty" but every chapter contain links to other resources on the topic covered. It has become my 'only' Python book (not entirely true of course but it really is very good) :)

Sorry to but in totally OT...

Tina

[fos]

Thanks Tina,

Your input is welcome anywhere! :)

fos