What are the best practices in configuring Juniper SSG140 firewall?

The above firewall being setup back to 2 months. Recently, few servers were found being attacked. In term of the firewall end, any best practices for any pro-active settings. Using IPS? any thing else?
BalackAsked:
Who is Participating?
 
Sean_D76Commented:
The outgoing ANY Trust -> ANY Untrust rule is not unusual.  It is tricky to secure all outgoing communications unless you really know very well which ports your servers will use when replying back to the incoming requests.  Probably you need to leave that alone or you will forever be trying to figure out why things don't work.

You MUST secure your web code and IIS.  That is priority #1.  That and/or weak passwords(?) are most definitely how the attackers got in.  If you cannot account for your web code or change IIS settings then you had better license Deep Inspection and enable it on the policies for WWW.  It should catch many common attack patterns and make up for the security holes in your IIS and code.  pay attention to the firewall logs for the first few days using it.  DI can also block some "good" traffic too sometimes.  In those cases, just disable that individual rule which is causing problems instead of turning off DI or removing the entire group.

In the meantime, Juniper will let you download 30-day trial keys for Deep Inspection so you can use it while you wait for your order.
0
 
Sean_D76Commented:
Juniper offers IDS services (they call it "Deep Inspection") but you must buy and license it.
You really have not given us enough information by which to offer any advice with.
We don't know anything about your MIPs, VIPs, or policies at this point or what services on your network (if any) must be accessible from the outside to meet your company's business requirements.
0
 
ongpcCommented:
I have no experience with Juniper Firewall. However in general, best practice to configure firewall is to

1. Block all traffic and allow only required ports.
2. Make use of DMZ zone for those servers that need to face internet directly.
3. If budget is not a concern, have multiple layer of firewall (at least 2 layer) and make sure every layer are different brand.
0
WEBINAR: 10 Easy Ways to Lose a Password

Join us on June 27th at 8 am PDT to learn about the methods that hackers use to lift real, working credentials from even the most security-savvy employees. We'll cover the importance of multi-factor authentication and how these solutions can better protect your business!

 
BalackAuthor Commented:
I configured to use MIPs, there are up to 10 MIPs. Most of the ports to open include, 80, 3389, 22,. Others includes, 21. There is only ONE segment, to house all the servers. There are few pools of servers, for web/application engine/database.
0
 
BalackAuthor Commented:
Currently, I configured to open port 3389 for MS RDP, on almost all of the servers. What would be the best practice of allowing RDP, with security tightening way? Do I have to setup one PC, open port for RDP, and it becomes the launching pad for the rest of the servers? Does this also means more administrative efforts for administrator?
0
 
ongpcCommented:
Do you mean you ace accessing to all servers by RDP via internet? Opening port 3389 on the firewall is very common, however it is not the best practice. The best should setup a server as TS Gateway, so that you can access servers by RDP via port 443 instead of 3389. However you will require to get yourself a SSL certificate.
0
 
BalackAuthor Commented:
Thanks for the advise of using TS Gateway, but not budget for it at the moment. How about other best practices?
0
 
ongpcCommented:
You should not allow port 3389 to all servers. Instead those servers that need to face internet directly should be placed in DMZ zone, and you may want to open port 3389 to DMZ servers if required. However you should not enable port 3389 to internal network and of course not even from DMZ zone. If you are required to remote access to servers in your network from internet, best practice would having a VPN connect either IPSEC or SSL VPN should be fine.
0
 
BalackAuthor Commented:
Hi Ongpc,

You got a point - a good ones. VPN MUST be why to go. Other than remote access, how about the pro-active way that Juniper has in order to deter any security breach attempt by hacker? such as half-port attempt, port-scanning, etc?

Maybe I forgot to mention, I got only one segment - to house all my internet-hosted services servers. No user desktops, equipments. As this is a datacentre.
0
 
Sean_D76Commented:
Yes.  You really need VPN for administrative access.  Juniper has a client which is very cheap to license but not really a very good client.  You can also open PPTP and set that up on one of your servers in RRAS.  Best would be a simple dedicated VPN box.  I like the little Sonicwall SSL VPN 200 for a very cheap and easy VPN solution ( < $500).  That being said your security breaches are more than likely not via RDP.  While there are a few vulnerabilities that exist in RDP they are very few and if you've patched recently you should be OK.  90% of your risk is from opening port 80 to these machines.  And if you're running IIS, you've really got to be sure you've properly hardened your IIS servers and web code.  Most likely this was the source of your breach.  There is a huge list of IIS vulnerabilites.  The first and most important step you can take is to make sure all servers have all their Windows Updates and none are running older unsupported OS's (Windows 2000, etc.).  There is a tool called the IIS Lockdown wizard which you can run.  You should do it off hours but if you can run through that wizard without breaking your applications it should help a lot.  If you can't do much tinkering with your IIS or web applications then you really MUST get some IDP going.  Ask your vendor for a quote for Juniper's Deep Inpection licensing.  You can enable it and choose which protections to implement under the policy via which you open port 80.  This should also have a huge impact on your security.  Also, FTP is something of a hole here because if you're running Microsoft's FTP which comes with IIS then it's very easy to run a brute force attack against it and since it uses system accounts they could divulge your local windows user passwords.  Consider using a different FTP server app if at all possible.  Something like Filezilla server is free and should suffice and will not use system accounts, has an IP blocking function for brute force attacks, and chrooting for limiting the attacker from roaming all over your hard drive.

If you've already had breaches I would say you really need to implement all of the above:  VPN, IIS/OS hardening, Deep Inspection, reduction of your surface footprint (closing unnecessary ports), using alternative FTP software, etc...
0
 
BalackAuthor Commented:
Web, FTP, and MS RDP are few major things in my scenario. For web, I'm using linux-based, any way to strenghten by using Juniper? For FTP, i'm using filezilla server. How to strengthen? And MS RDP, other than user accounts, can Juniper to some thing?
0
 
BalackAuthor Commented:
I also found one more security vulnerability - a policy allow trusted to untrusted any>any with any services access. Could this be the major problem? As on one of the server, my teammate found some activities being triggered from there, such as using Bit-torrent and other tools to copy the files out
0
 
BalackAuthor Commented:
Does deep inspection is a MUST to have in order to tighten the security? Shall I buy license for it?
0
 
s_magicCommented:
I've never really used the Deep Inspection in production.  As far as RDP goes, I usually lock down the sources.  The group of IP address I use to connect via RDP are added to a group I call "remote_management."  I then put in a seperate policy for RDP access from the remote_management group.  This isn't always an option of you have things like terminal servers where end users will be connecting from various locations but it works good for protecting servers that only need RDP open for admins.

As far as outgoing ANY Trust --> Any Untrust, it may not be a good idea for webservers.  I like to block it, but if they need to communicate with things like payments gateways and other servers via port 80 it may not be possible to block this.  Blocking outbound port 80 access is good for things like exploits that will download scripts and files from other servers on the internet.
0
 
Sean_D76Commented:
@s_magic:  There are more important reasons not to block outgoing traffic.  Granted if you can manage it, its definitely more secure, but the problem is not strictly other software on the PC.  The browser will always make it's request to port 80 on the web server but for various reasons the web server may respond from a different source port and the client definitely uses random ports.  FTP is even worse as PASV mode will negotiate it's own ports.  It gets messy to manage all your source ports.  Eventually you end up with a long complex list of source port based rules.  Moreover, you haven't done anything to mitigate the breach, only the damage.  Since he MUST have port 80 open, he could still get rooted via an IIS flaw or hole in his code, combined with privilege escalation.  The outgoing traffic blocking simply makes it harder for the infected server to "phone home" but not really that hard as the attacker knows the firewall will have to allow all traffic originating from port 80 and several other key ports and there would be ranges of ports opened for FTP to use in PASV mode...

He NEEDS to secure his web code and patch his servers with all available windows udpates at the very least.  If he cannot secure the web code then he needs some intelligent IDP on the network to mitigate common cross-site scripting and SQL injection attacks. 98% of all breaches are known attack patterns for known unpatched vulns and their run by bots and script kiddies sweeping vast ranges or IP addresses only looking for the easy targets.  The other 2% are targeted work by pro's or "inside jobs" done by ticked off ex-employees.
0
 
BalackAuthor Commented:
How about the Windows servers? I found some traits of authentication failure in audit failure event. I'm thinking all of my windows local users/groups not allowed to logon from the network. Is this possible?
0
 
BalackAuthor Commented:
How about FTP, few developers that remotely access to the servers, need to use them to upload/download files. Shall I ask them to use web-based "YourSendIt" rather than setup a FTP server on the server?
0
 
Sean_D76Commented:
You can strengthen the security on the Linux web servers using basic linux server hardening tactics.  mod_security and some other things.  Especially PHP has a lot of vulns but that really should be posted in the Linux, Apache, or PHP sections.  Juniper's Deep Inspection will protect attacks incoming to the web servers on port 80.  I believe it has some protections for port 21 (FTP) but it won't protect against a dictionary or brute force cracking attempt. It will not protect your RDP either.  As I stated earlier, unless your users have weak passwords or you never update Windows, RDP is not that vulnerable.  There are plenty of vulns for FTP but not too many published ones for Filezilla.  You can (and should) in Filezilla setup IP banning after repeated failed login attempts.  This will thwart your dictionary and brute force crackers.  And your Windows boxes should have Server 2003 Password Complexity enabled so user's are not allowed to set weak passwords.

As I've said... you already had a breach and the attackers managed to execute code, so MOST likely they got you on an IIS vuln on Windows web servers, or a PHP cross-site scripting  or SQL injection vuln in the Linux servers.  The vast majority of such attacks and infections occur because your running some known open source code with known vulnerabilities like phpBB forums or there is a whole bunch of CMS's like joomla and PHPNUKE and such which are full of holes.  If your webmasters never patch and If you can't clean up this code then Deep Inspection is your best solution and should mitigate 99% of those common attack patterns.

The VAST majority (99.99%) of breaches occur from automated scripts which sweep the internet looking for these known weak software (e.g. a certain version of phpBB or phpmailer script, etc).  Because of that Juniper's Deep Inspection will probably recognize a good majority of those making you MUCH less likely to get breached again.  Nothing is ever 100% unless its unplugged because that other 0.01% are some seriously elite hackers which run targeted attacks and with your setup you might as well forget about trying to protect yourself from them. Lucky for you, most of them have better things to do and much bigger networks to attack.  ;-)

I think that's about all the advice I can give you without getting into PHP/Apache hardening or other such off-topic things.
0
 
BalackAuthor Commented:
Good
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.