Iptables -- any good script for Virtualmin?

12 posts / 0 new
Last post
#1 Tue, 07/10/2007 - 15:56
MarkCumberland

Iptables -- any good script for Virtualmin?

I am running FC6 and Virtualmin Pro, and still have a few hackers daily trying to hit me, especially on 22 and 25. I am getting a lot of hijackers as well on 25, and had to turn that port off... but then realized that I could not receive mail!

Anyone have a good iptables script that will further lock down for the Virtualmin configuration?

Wed, 07/11/2007 - 03:01
Joe
Joe's picture

Hehehe...Yeah, port 25 is the most abused port on the Internet, and you can't close it if you want to send and receive mail.

Port 22 (ssh) is actually reasonably safe, as long as you use strong passwords for every account (a strong password is one with numbers and letters, and possibly symbols, and is 8+ characters in length). Leif posted a pretty cool little snippet of iptables rules a while back, which is discussed at length in this thread:

http://www.virtualmin.com/index.php?option=com_fireboard&Itemid=77&a...

This might do what you're after (it throttles connections to SSH if they're not established...so, a valid login will not be affected because it becomes an established connection after the first try, while brute force attacks are affected because they have to reconnect every time they fail to hit the right password after three tries).

--

Check out the forum guidelines!

Fri, 07/13/2007 - 08:31 (Reply to #2)
Joe
Joe's picture

Hey Mike,

The networking nerd in me just won't let this one slide: Blocking all ICMP is bad mojo. Block pings, if you want, but brother please don't drop'em all! ;-)

Here's why:

MTU path discovery will break. This will hurt performance if you're on a network with reasonably modern routing infrastructure, particularly if you serve large files at high speeds.

Destination Unreachable, Fragmentation Needed and Don't Fragment packets will be lost, and users that needed them will get broken images, incomplete pages, corrupted data transmissions via other protocols, or nothing at all from your server. This will happen to some percentage of your users (possibly a quite high percentage...it depends on a lot of factors), and it will be hard to troubleshoot unless you know where you're looking for.

So, drop ICMP Echo requests if you like. No problem there. But leave the network reliability types untouched.

--

Check out the forum guidelines!

Fri, 07/13/2007 - 22:49 (Reply to #3)
ah...lifes...good

<b>Joe wrote:</b>
<div class='quote'>So, drop ICMP Echo requests if you like. No problem there. But leave the network reliability types untouched.</div>

Joe, will dropping ICMP Echo requests affect Webmin's System and Server Status function?

What about the web hosting company's network monitoring service?

Thanks.

Fri, 07/13/2007 - 23:12 (Reply to #4)
Joe
Joe's picture

Yes, AH, dropping echos will make anything that uses ping to test for availability to fail. This probably includes hosting provider network monitoring, and certainly includes some types of Server and Status monitors. There are other monitoring types supported by Webmin, of course, so you could just skip the ping test, and instead test the actual protocols you use--HTTP, POP, FTP, etc. are all supported monitor types. I recommend using those types of checks anyway, since they tell you a lot more than a ping test. Ping pretty much just tells you, &quot;yes, the network between here and there is live&quot;, and optionally, &quot;and the latency is high|low&quot;.

--

Check out the forum guidelines!

Fri, 07/13/2007 - 23:28 (Reply to #5)
Joe
Joe's picture

I'll also add that you could be specific and only allow echo traffic from your hosting provider and any monitoring hosts. That'd solve the &quot;I want to monitor uptime and network latency with ping&quot; problem. iptables is extremely flexible...it's not like low end broadband &quot;routers&quot;, at all. You can be very specific. It's also stateful (also not comparable to the &quot;SPI&quot; features on consumer level devices--it's comparable to the best Cisco PIX firewalls), so you can do things like the SSH brute force filter I linked to above. That's really very complex behavior for a firewall, and iptables can actually do quite a bit more than that.

Sounds like maybe we should all begin working on an IPTables chapter for the Webmin wiki, and maybe a firewall recipes page, as well. While firewalls play a limited role in securing a web hosting server (you can't block most of the running services in any meaningful way because then there's no point in having the server...and if a service isn't needed, you can just shut it down and you don't need to firewall it), the questions still come up quite a bit. But, I imagine there are lots of you also using Webmin on intranet servers and routers and such for your local network...in which case firewalls are vital and useful.

That reminds me, I'll mention the web hosting server security triumvirate again, since I don't want folks thinking that because I find firewalls interesting and enjoy talking about them, that they're particularly useful for Virtualmin servers. Firewalls are not where you should be spending a large part of your limited time when thinking about securing your webserver. First, make sure all of the following are taken care of:

1. All running services are kept up to date with the latest revision from your vendor or from Virtualmin's repos (depending on where the package comes from).

2. Passwords are strong. All of them. A strong password is one that contains numbers and letters and even better symbols. A strong password is also 8 or more characters in length. A strong password is changed about once every year or so. More if you have reason to suspect your machine is a target (if you run IRC servers, download sites, or keep sensitive user data).

3. You've shutdown all unneeded services. If you don't need it, turn it off. If you don't know what it is, find out. Google knows. We probably know here, as well. Feel free to ask.

That's it! Do those things, and you'll probably never get cracked. If you see some particular abuse going on (like the ssh brute force attacks that inspired this thread and Leif's solution) then dig in and make some rules, but otherwise, there's just not a lot a firewall can do for you on a world-facing system, except in very specific circumstances.

The only exploited systems I've ever seen were due 90% to weak passwords, and 10% to old exploitable services. Never have a seen an exploit that could have been prevented by a firewall (the ssh rule for brute force attacks might have reduced the weak password incidents by some measurable amount, though...).

--

Check out the forum guidelines!

Fri, 07/13/2007 - 07:18
mike

a nice little rule i have here in mine has a bit of a &quot;repelling&quot; effect on hackers and high jackers, first of all, i think it is safe to assume that we all know and understand that most hackers rely on &quot;ping&quot; to tell them if the target host is up or down. your average computer user doesn't bother with using ping because he/she most likely wont need to and have no interest in breaking into your machine. if a hacker pings your machine and gets a reply back then they know it is up and will make the attempt to get in, but on the other hand if a hacker pings your machine and doesn't get a reply back then they probably wont bother and move onto the next target. we all know that computers don't lie unless their owners make them do so what the firewall rule i have here is pretty much just that, it makes your server lie to those who ping you, the firewall rule is that for all &quot;incoming connections&quot; the server will take action and &quot;Drop&quot; everything coming in on the &quot;ICMP&quot; network protocol. I have yet to test this 100% but what it does in theory is well just as the rules show, it drops every packet on coming into the server via the ICMP protocol, this includes &quot;ping&quot; so the server will receive the ping but not send a response, it kinda takes the effect of firing fireworks into the air and them not going off, this will weed out the lame hackers quite well, and leave you with only the hackers that are determined so remember, drop all incoming packets on the ICMP network protocol, this is as close to identical as i could get to the very same as the &quot;Block WAN Ping&quot; setting on most home routers available on the market.

&quot;Drop all incoming packets on the ICMP network protocol&quot;

Fri, 07/13/2007 - 22:20
mike

right, u just saved me a few hours in testing the firewall rule, the other night i was searching around for a list of things that use ICMP and i found nothin, just that it is used primarily for comunicating so i figured, if the incoming packets were droped and the outgoing packets were left alone to do as they please, things should be fine... so yeah, total mistake on my hand :P

Sat, 07/14/2007 - 00:33
mike

on the topic of old exploitable services and up to date software, for the most part i all ways use the most recent software that i can get but there are 2 pieces i am not sure about yet both relate to compatibility, security, and stability, i run UBUNTU 6.06.1LTS Server but kinda thinking of upping to UBUNTU 6.10 Server, but anyways as i was saying, there are 2 bits of software i am not quit sure about, the last time i used them i found things that relied on them wouldnt install properly so i would kinda like a bit of a comparison of php4 -&gt; php5, and mysql 4.1 -&gt; mysql 5

like i said, when i last used php5 and mysql 5 i found that software that depended on php and mysql such as forum boards and some control panels i have tried, didnt work properly due to support, so has these php 5 and mysql 5 become as widely supported as php 4 and mysql 4.1?

Sat, 07/14/2007 - 00:44
mike

currently as of this post the most recent UBUNTU Server is 7.04 and comes with support till 2008 where the release I currently have (6.06.1LTS) has support till 2011, their support includes updates, so i think it is resonably safe to assume that staying with version 6.06.1LTS is safe untill the year 2011, in the instance of this one should probably upgrade his / her installed OS as new LTS releases come out.

Sat, 07/14/2007 - 00:55 (Reply to #10)
Joe
Joe's picture

<div class='quote'>currently as of this post the most recent UBUNTU Server is 7.04 and comes with support till 2008 where the release I currently have (6.06.1LTS) has support till 2011</div>

Yep. That's exactly why we don't really want to support non-LTS versions of Ubuntu. 12-18 months is just not a reasonable upgrade cycle for servers. Heck, I don't like to mess with nicely running systems no matter how old they are...so a five year life cycle is what I like to see for server operating systems.

But, yeah, as long as you're running the latest version of PHP4 or MySQL 4 from the Ubuntu repositories, you should be fine.

--

Check out the forum guidelines!

Sat, 07/14/2007 - 05:17
mike

ok good, cause i thought there for a moment that i could be running a bit of a security risk by running an &quot;old&quot; version, but i only use the most recent otherwise and yeah it would be the most recent version of php4 and mysql4.1 from the ubuntu repositories

Topic locked