Why do I need a firewall?


#1

Ok, this might be a really really naive question to ask, but do I really need a firewall (be it iptables or whatever) on my VM? I’m running mine as a web server and I have MySQL which only listens on 127.0.0.1 as well as FTP and ssh. I don’t want to block access from anywhere in particular so I’m not looking to block IPs.

So do I really need one? Or am I being stupid in not using one?


#2

[quote=Piers Karsenbarg]Ok, this might be a really really naive question to ask, but do I really need a firewall (be it iptables or whatever) on my VM? I’m running mine as a web server and I have MySQL which only listens on 127.0.0.1 as well as FTP and ssh. I don’t want to block access from anywhere in particular so I’m not looking to block IPs.

So do I really need one? Or am I being stupid in not using one?[/quote]
Do you believe that you will not make a mistake, ever? If you do, then perhaps you don’t need a firewall.

The point of a firewall is to implement a deny everything that’s not explicitly allowed policy; it is an additional defense against mistakes in configuration and such like. It can also be used to make password guess attacks against FTP or SSH harder.

BTW, I hope you’re only enabling anonymous FTP. Regular-account FTP is a huge security risk in today’s network environment.


#3

Anonymous ftp? Not a chance? Why would I do that?


#4

So - no-one should be able to FTP?

FTP is like any other web service - a good package, good passwords and confining user accounts to their own directories will address most issues.


#5

That’s what I do. I thought I was going about it the right way. (FTP, not Firewall stuff)


#6

You echo my own thoughts. But the last time I raised this discussion the counter-arguments were roughly as follows:

  1. You might make a mistake.
  2. A user might make a mistake.
  3. Outgoing firewalls will help you if you’re running insecure (php) applications.
  4. They cause no harm, and might accidentally do good.
  5. Your kernel might contain bugs. (Been a while in general, but some recent IPv6 modules have been problematic.)

Steve


#7

So - no-one should be able to FTP?

FTP is like any other web service - a good package, good passwords and confining user accounts to their own directories will address most issues.[/quote]
Yeah, if the FTP accounts are not linked to system accounts, it could work. I was really referring to the typical setup where FTP allows anyone to login via their valid system credentials.


#8

Anonymous FTP (as a file service) is the only common FTP usage scenario I was aware of that is not a huge security risk. Of course, it is probably possible to set FTP up securely, but I’d expect that to take a lot of planning. Or are there nowadays canned setups for it?

I apologise if my knee-jerk reaction was out of order :slight_smile:


#9

Not at all - I was just surprised by the comment! :smiley:


#10

Tell that to the man who just locked himself out by misconfiguring it :wink:

Thankfully it’s Bytemark to the rescue here as you’ve always got serial access to your virtual machine or dedicated host to fix such problems quickly! Hah <3

I’ve got a firewall running on one server, in total, and that’s just a couple of preventative rules aimed at 1-2 specific ports. Not so much a fan, I’m afraid. Anything I deploy I’ll make sure to configure properly, and my users can’t deploy stuff through their own shells due to the magic of grSecurity - unless they’re explicitly allowed they cannot create listening sockets.


#11

I’m the only person who actually has user access to my server. And I keep tabs on what ports are accessible. I will probably put something on there eventually, but I just wondered what people thoughts were.


#12

One common security precaution that system admins use is to set ssh to listen on a non-standard port.

You may wish to configure your sshd by editing /etc/ssh/sshd_config and changing the line:

Port 22

to specify a different port (e.g. 12345).

It is common for hackers to attempt ssh daemon exploits that tend to be very specific to the version of openssh that is running. By having sshd listen to a different port, instead, then you are reducing the risk of a general port 22 scan and hack.

At least this is what I have done.


#13

Yup, after noticing at least 10-20 ssh login failures every night, I moved my port, and haven’t had any more problems.

Is it possible to move the ftp port too? I’m getting similar login attempts to that.


#14

[quote=Peter Payne]It is common for hackers to attempt ssh daemon exploits that tend to be very specific to the version of openssh that is running. By having sshd listen to a different port, instead, then you are reducing the risk of a general port 22 scan and hack.

At least this is what I have done.[/quote]
What I do is that I have a iptables firewall that slows them down (dropping connection attempts from the same ip address if there are too many too fast); it seems to discourage such password guessing games quite well.

My solution is available at http://antti-juhani.kaijanaho.fi/stuff/ratelimit.txt (it is a shell function that you can use in your firewall script).


#15

http://rimuhosting.com/howto/firewall.jsp


#16

I am in the have-a-firewall camp but then I like watching packets on interfaces :slight_smile:

It is not the be-all and end-all of system security but it provides one of many stumbling blocks which may help me in any attempt to prevent my machine being compromised.

You can for example lock a remote box down to traffic on a fixed IP address only. Then you can deal with the box if it seems to be misbehaving or execute your usual security measures on a new remote box.

Obviously you need to open the ports of the services you offer but you can use rate limiting on them as a DoS prevention on those ports.

You can open services on non-standard ports too but a portscan will reveal them - whether or not they are above 1024. So working off a non-standard port might confuse script kiddies but you might want to rate limit the non-standard port anyway.

I unceremoniously drop on ports 135-139, 445, 1026-1028, 1014-1017 and 10144 and 17488 all of which appear to come from noisy Windows boxes. I believe there is a recommendation that one rejects unrouteable with an ICMP Type 3 code 2 or 3 - which is what -j REJECT does. The -j DROP merely drops the packet and I see no reason why I should add to the noise out there.

You can also log what’s happening at an interface rather than simply allow anything in. This may or may not help in tracing a compromise or simply being aware you are being portscanned or experiencing heavy traffic on an unused port.

All that I have read on iptables advises the default policy is to drop and only allow the traffic you want to have happen - effectively run a whitelist - and this applies to all tables. Obviously it is difficult to think of a whitelist on a server but I think you can still deal with some potential problems using iptables.

I am not sure how you would deal with some of them otherwise.

Regards

L.


#17

Concerning ftp if you can get your users to upload using sftp instead of ftp this will reduce your attack surface. You’ll still need to secure your ssh server, but this can now handle your uploads using sftp as well as shell logins. It also protects you against man-in the middle attacks on ftp passwords which otherwise traverse the net in the clear. For backups I use rsync also running over ssh which benefits from ssh security as well as reducing bandwidth and increasing speed. The ssh server is very versatile and so saves a lot of work.


#18

I can’t say that I use a firewall, although I do have some tools such as denyhosts (although fail2ban is excellent too) to monitor incorrect SSH logins, and then ban that IP’s access through /etc/hosts.deny

I probably should install some sort of firewall, although I only really run Apache/PHP/MySQL on the box. I don’t run FTP, DNS or even a mail server.

Jonathan


#20

You could also consider blocking everything other than public facing services and allow all other access via OpenVPN.