Hi

I'm a complete Newbie setting up a new webserver, with Debian. I need a firewall in order to protect the server mainly from malicious attacks.

For SSH i will be changing the port and potentially making it a no password login
For FTP i'll be only running SFTP
Web server will be apache off course.

Now i gather you can use IP Tables as a basic form of a firewall but since our last two servers were compromised, not setup by me. I would like to add a more advanced firewall.

On current server i've installed ConfigServer Security & Firewall which i'm not sure is the best but it's helped Stablise the server so it's not going down every 3 hours.

So i've ordered a new server which i want to secure 1st before i do anything else. To help users the server will also have webmin

Since the firewall will be running on the actual webserver and i don't have gui beyond webmin i need a command line installable firewall.

Just google give so many options i'm lost

Smoothwall
Firestarter Firewall

Any pointers most appreciated

Hello and welcome to the forums!

First of all, you probably want to use more than just a firewall. Also, what's your definition of 'more advanced firewall'? The firewalls you mention (Smoothwall and Firestarter) are just GUI front-ends...they're both using iptables behind the scene. Administrating a firewall via webmin is pretty much the same thing...webmin would be the front end (the frond-end interface) of the firewall.

It sounds like you might need to review the firewall rules. You can post what rules you have here so we can offer suggestions.

Also, note that firewalls aren't the one-stop solution for attacks, meaning firewalls typically don't act upon layer-7 attacks. If you've a webserver that is serving dynamic content (IE, LAMP), a firewall won't stop malicious SQL commands or snooping queries. For that, you can use either an IPS (intrusion prevention system) or a web application firewall (such as modsecurity). If you're talking DDoS or even DoS, there's not much you can do about that, beyond contacting your upstream provider and working with them on filtering out the DDoS/DoS.

Additionally, such things as changing SSH ports doesn't stop attacks or even hide the service from a determined attacker. In fact, having a "no password" login is probably not good, either. You probably should use key-based authentication. Some admins use key-based authentication as two-factor authentication (you have the key and passphrase to the key) but many skip the passphrase, which makes it a one-factor solution (dangerous, IMO). The reason they typically skip it is because they have to enter the passphrase (which might hinder any scripts they might tie to a login account). There are solutions for this (ssh-agent is one).

1 members found this post helpful.

Thanks well that helps a little

Do firewalls not help is IPTables sufficient, this is for port probing i'm talking about.

I have considered MODSecurity but excluded that for now as need to get my head around it as it general it was working ok on current server but on a few applications on particular url's it was playing funny.

I don't mind using command line for anything. So if i'm looking for an IPS then i need some recommendation as i have no idea. I've heard of Snort and thats it. I'm on a quick and steep learning curve at the moment to no where

All i want to know is list of software / things i should to to secure a webserver.

Think i need to go back to step 1

http://www.thegeekstuff.com/2011/03/apache-hardening/
http://www.howtoforge.com/apache_mod_security
https://www.net-security.org/dl/arti...linux_mag1.pdf

Kind regards

Given, as has already been commented, the GUI front ends are primarily easy ways of configuring iptables, you can do anything (nearly) that the GUI thingies do with iptables manually, if you have the appropriate level of knowledge.
that does not mean, for example

• that any and every iptables ruleset is 'sophisticated' enough for the job at hand - that depends on both the ruleset and the job at hand
• that iptables rules are the only things that the GUIs set up; There are also bash commands used to put the kernel in an appropriate state, and if you were to omit those things in your 'firewall script', then your protection wouldn't be as good as it might be
• nor does it mean that 'firewalling' is some kind of magic that makes all problems go away - if you think about, say, ssh logins, the firewall may well have a role to play in stopping anyone having too many tries at password cracking, but if your ssh setup is defective, it may well not be feasible to cure the problem with the just firewall, so you have to look at this holistically, across the whole system
• ...and you have to know what you are doing with, eg, networking, and it may just take a little less knowledge to work with a GUI, provided that the people who put together the GUI knew what they were doing, and thought about something sufficiently close to your use case to be helpful..but if this is all a way of avoiding understanding networking well enough, you will always be a bit more exposed than you need be

'you can do anything (nearly) that the gui thingies do with iptables manually' - just to go back to that comment, which I realise is ambiguous

• The GUIs, and most iptables config scripts, do stuff which is not purely iptables; therefore, you cannot say that iptables directly can do everything, but it is often bundled up in the same configuration script
• Some of what you can do with iptables depends on the use of modules or other add-ons, that's not purely iptables either, although it is directly related

And sophisticated is not really the right word, as extra sophistication isn't necessarily helpful; the firewall has to do enough, but adding extra frilly bits, because you can, is not a good approach, if you need throughput. And, if you don't have sufficient throughput, you can make DoS/DDoS attacks easier


Errr, OMG (sorry). Every three hours. That'll mean that you have plenty of evidence about exactly how it is being crashed and what tactics are being used against it. Care to share? If it is, eg, ssh then you'll need some info on that, but if it is known to be something else, then we are wasting your time, at least in the short term, giving lots of ssh stuff.


Well, you can see a thread here in which someone does go through the steps in (perhaps painful) detail. This probably the closest I have seen to best practice, in this regard.

1 members found this post helpful.

Thanks you all been very helpful

Sorry but it was all lost as all that was happening was log files filling up with my little knowledge and what i sort of saw is that something kicks off something which then tries to flood an ip address with UDP requests down various ports since placing the firewall i've got it down to this occurring very occasionally maybe 3 or 4 days. Looks like the firewall is blocking most attempts.

Prior to this occurring some of the wordpress sites were compromised with a php.shell virus i did clean all files but even with Modsecurity and the Firewall another did get compromised so i have done various extra bits on wordpress. So this incident proves to me that i need something beyond a firewall and modsecurity i.e IPS/ IDS like snort so i can monitor more closely what is happening.

Best reading all links provided before next question

Thanks

Don't write off modsecurity just because it didn't block the compromise. It could've been set up wrong, or the sig/rule that could've caught it was disabled. I'd bet that it wasn't set up properly. The cool thing about signature-based tools is that you can create your own to catch things that would otherwise slide through your security layers. Modsecurity is pretty much an IDS/IPS that is specific to monitoring Apache, so that would be the tool that should've worked. If something slides past your IDS/IPS, you need to look at why the anomaly wasn't detected...more than likely its a PEBKAC issue.

I'm sure there is alot of issues on old server hence why want to get it right on new server. Yes with modsecurity i just used core rules as on their site and i don't think wordpress was locked down enough. Thanks for all the pointers i got a much better idea now.

I've read a sample of the Mod Security book written by one of the developers of Mod Security. Maybe time to purchase that i think your right if i get Mod_Security right and monitor logs regular, patch up etc i have a better chance of stopping the server being compromised.

As mentioned in post #2 re 'layer-7' its important to realise that each security 'tool/utility' works at a different layer, so eg iptables is very important to get right, but it can't stop a defective app from being compromised eg SQL Injection attack.
You need to address each layer separately eg firewall (iptables), kernel+OS kept up to date, patch everything at the OS and App layer, run IDS/IPS tools.
Check for SQL injections and such like https://www.owasp.org/index.php/Main_Page.
Don't run unwanted services; check with nmap against your sytem to see what it looks like from the outside. Your system should offer a way to check what services are enabled eg chkconfig ?

As you've noticed, CMS's are popular tools to attack.

Check the Stickies at the top of this forum for good advice.

As no one has picked up this part of the original question:

No, I can't even think what too much security would be. You could, however, configure whatever security measures you have in a way that they cause real difficulties for the normal operation, but it is not a simple 'slider', where as one goes up, the other goes down: it is just not the case that 'Good' security implies an impossible workflow and 'Bad' security implies an easy-to-use workflow, so it is not a simple 'tradeoff' that improved security implies more difficult workflow and vice versa.

Have you considered fail2ban/denyhosts (etc, there are several utilities that do similar-ish things) to block off malevolent ip addresses (in as much as this has any meaning)? I'd guess currently you are using something like iptables rate limiting features to achieve a degree of protection, which may not be versatile enough.

Now this is where newbies get confused

I was so much up for looking into deploying mod_security then i come across this 4 reasons not to use mod_security

http://devcentral.f5.com/weblogs/mac...7/23/3477.aspx

And i'm thinking how will it affect the performance of the one server i have don't have luxury of getting another yet.

Also then i find another Web Application Firewall called dotDefender to name but one form this list

https://www.owasp.org/index.php/Web_...ation_Firewall

Now how do i know which is better or worse easier to configure or not. The only criteria i can use is experience of others. Is there a GUI for mod security to make log file reading easier.

I'm actually using ConfigServer Security & Firewall which helped stablise the system and is daily increasing in banned ip list. Heard of fail2ban but not used as i'm not sure if good idea running multiple pieces of software which do similar things.

As example would there be any harm running like a normal firewall, a web application firewall i.e Mod Security and maybe even an IDS/IPS system like AIDE or Snort or is it best to limit software and configure one of them better as technically they do all do different tasks

A convention I have herd of in the past that could help you is: "block everything first then open what needs opening". Selinux and the other similar product (the name eludes me right now). These programs have a learning curve to them. You maybe doing some studying on them. Also with security, I see it every day at my job. We seems to me we use more than what is really needed. You will need to balance security with performance. The more security you have the slower the system will work. My organization is notorious for this, in some cases there are literally 30+ layers of security from the client to the server. Also like to reference Mick Bauer at Linux journal. He has a few articles on hardening Linux. Although his approach maybe basic you maybe able to use that as a starting point. Hope this helps you.

1 members found this post helpful.

From
http://devcentral.f5.com/weblogs/mac...7/23/3477.aspx (I'll answer inline):

How many web servers do you have? It is implied that you're using one. Modsecurity isn't the only tool that has to be installed on the machine it is supposed to monitor (all HIDS have to have agents installed, which monitor for any file changes on the host). I don't think this is something you need to worry about. It would be different if you needed to monitor multiple (like 5 or more) web servers. I also don't believe in the argument that adding modsecurity would add undue load to the web server. Your machine should be beefy to begin with. If it can't handle modsecurity, it more than likely won't be able to handle large loads of traffic. And note that tuning modsecurity (turning off rules that aren't a concern for you, while enabling those that are a concern) will make it more efficient, which will have a positive effect (load-wise) on your web server. I'm pretty sure but not 100% positive that modsecurity sniffs traffic on the machine's interface and will block the traffic if the traffic matches a pattern that is within the rules that are enabled. Doing that to every packet that comes across the wire CAN be intensive, especially with large traffic spikes...it is important that you ensure that your hardware can support sniffing AND serving, in this case, but I don't think its a show-stopper.

It sounds like you need to be a security expert anyways, from reading your requirements. Any admin should be enough of a security expert to properly lock down the machines and networks they're responsible for. This is a no-brainer. Yes, you have to be expert enough to know what you're doing...that's not a bad thing.

The last note above applies to this as well, for the same reasons. Also, as a web admin, you should know the HTTP protocol regardless, so this is also a no-brainer.

This is also a no-brainer. Of course the configuration has to be done manually. Every security tool I've ever seen has to have it's configurations done manually, even commercial products. I've lost count of the times I've had to do PIX changes at work across multiple firewalls. It has to be done by hand. Clients typically don't trust automation in this regard. Reason being, they tend to want human intervention...human beings usually have better judgement than an automated tool, for one. You yourself stated earlier that you were running the core rules for modsecurity and that you were concerned that modsecurity hadn't stopped an attack. Part of the tuning process for most security tools is for human-based sanity checks to occur. For example, why would you need to have an IDS monitor for Windows-based attacks if you don't have Windows machines on your network? In that case, you've the option of turning off every IDS rule that alerts on anything related to MS Windows. Such tuning optimizes the tool so that it isn't overloaded and looking for traffic that isn't a concern to you. You're not going to be able to get around this unless you desire an inefficient security tool.

---

Basically, I think that page offers crappy reasons to not use modsecurity. You'd have to do it for most alternatives. Also, I don't think there's anything more capable, unless you go snort-inline (which would give you the option of using oinkmaster, a rule updating third party tool).

I've no idea about dotDefender, but I'll research and maybe even attempt to test it.

And, yes, modsecurity has the option of a GUI, although I never used it...I viewed the alerts as flat files.

Thanks Unixfool you've been very helpful i should be linuxfool

I agree i'm already learning more and more about security on linux. I think the only thing that gets newbies confused is the array of information in google and open source software which do the same thing and not know if any is better then other.

Time to setup a virtual box and do some testing me thinks.

Just asked on server forum but none has mentioned kernel hardening. Was just googling and found this

http://www.howtoforge.com/hardening-...ecurity-debian

I'm not sure if it's even a requirement or an option for a newbie as i suppose this only issue if your looking to protect the kernel from attack ?