Firewalling instructions for new Virtualmin (GPL) install

4 posts / 0 new
Last post
#1 Mon, 08/16/2010 - 09:01
aitech

Firewalling instructions for new Virtualmin (GPL) install

Hi,

Can anyone give me some insight as how to best firewall a new install of Virtualmin (GPL) specifically which ports should/shouldn't be blocked. I'm running a Debian 5 x64 system with the current version of Virtualmin as installed via the install shell script. I've Googled and searched the forums without finding much. Any help is appreciated.

Thanks

Mon, 08/16/2010 - 09:20
andreychek

Howdy,

Well, that all depends on what services you want to provide :-)

However, Virtualmin takes a guess at install time, and sets up a series of firewall rules allowing a number of common applications. You should be able to see what those are by running "iptables -L -n" from the command line, or by going into Webmin -> Networking -> Linux Firewall.

-Eric

Mon, 08/16/2010 - 09:51 (Reply to #2)
aitech

Eric,

Thanks for the response. I checked both places and seem to have an empty rule set. I was mainly wondering if this had been addressed in the documentation and I had missed it or even covered elsewhere in the forums. I'm looking for a best practices approach as recommended by someone more knowledgeable than myself.

Thanks

Mon, 08/23/2010 - 12:47
Joe
Joe's picture

You're assuming a firewall is particularly useful or necessary in a hosting environment...when, it generally isn't all that useful. You can't block the services you want to provide (because what good is a webserver if everyone can't reach it from anywhere?), and the services you don't want to provide shouldn't even be running. A port with nothing on it is a port that is just as secure as one with a firewall blocking it.

That said, you might consider reading up on some of the stateful features of iptables for preventing some types of abuse. For example, it's possible to reduce brute force attempts against some services (ssh, in particular) using stateful rules that block rapid-fire attempts to connect...though I don't bother implementing them until I'm finding that it's a problem. Most of the services running in a Virtualmin system are already pretty well-hardened against most attacks due to being mature code with a lot of battle-testing, though nothing in a single system deployment can prevent DDoS attacks from causing trouble.

So, when you ask about firewalls, I'm going to actually assume you really want to know about how to secure your system, which is a more useful topic for discussion.

The holy trinity of server security is this:

  1. Always run up to date software. yum or apt-get makes this easy. Always run the latest code from your distro or the Virtualmin repos. Your web applications also have to be up to date. Virtualmin Professional makes this easy for the most popular web apps via it's Install Scripts update features.
  2. Use strong passwords. A strong password is 8 or more characters and contains letters, numbers, and optionally special characters.
  3. Don't run unneeded services. If you don't need postgresql, don't run it. If you don't need FTP access, and can use ssh instead, shut down proftpd (tell Virtualmin about this in available features, or it will complain).

I used to do security consulting, post-exploit cleanup and recovery, etc., and literally 99% of the exploited boxes I saw would have been prevented if the administrator had followed these rules. Actually, it's probably 100%, but in one case I couldn't identify the point of entry (it couldn't be cleaned up because of that fact, and we had to rebuild their server from the ground up with a newer OS version; if you don't know how they got in and what they did afterward, the system can never really be trusted again, because the ways a system can be compromised are nearly infinite and it's extremely difficult to be sure you've found them all before rebooting).

Seriously, I have never seen an exploited system that would have been saved by a firewall, though the modern stateful capabilities of iptables might have slowed down the discovery of weak passwords in a few cases. The weak password cases, however, were the least damaging...the attacker discovered a non-privileged user's password and started sending spam or attacking other machines from that machine. Usually easily fixed and easily cleaned up, assuming you weren't running any old software that allows privilege escalation.

--

Check out the forum guidelines!

Topic locked