I am currently responsible for our PIX firewall in the company I work at. We are a company of approx 100 users and most of them are quite IT savvy.
We all know that most security breaches and risks come from inside the firewall (or at least are present because of things happening inside the firewall) and can be caused by a number of different reasons.
To put this thread into context, I'm having an internal struggle with whether to start controlling all our outgoing traffic and not just incoming traffic. I'm still running the PIX with an open outgoing policy, i.e.
access-list inside_access_in permit ip any any
access-group inside_access_in in interface inside
I am worried that I'm not doing enough to control the flow of traffic and actually keep a tab on anything and everything that goes on with the firewall. The firewall is one of many responsibilities that I have, and although I know that this needs to be high up on my list of priorities, I don't want to create unnecessary work for myself.
I've been reading this forum for a while now and notice that some people run like this and others run very tight outgoing ACLs. I personally have the view that perhaps I should stay the way I am.
Most applications that "encourage" security loopholes (e.g. messaging apps like ICQ and file-sharing apps like Kazaa) are now intelligent enough to use well-known ports (especially port 80) for their communication if they cannot connect using their own ports. If this is the case, then why do I need to bother with controlling these applications? My time would probably be better spent attempting to educate our users as to the risks and actively discourage it...
Any feedback on this would really be appreciated - I need to settle my thoughts on this issue once and for all!!!
what you do with your firewall should be dictated by your Security Policy. If you are going to run an acl for the outbound traffic, you should at least limit it to your IP subnet(s) instead of everything to prevent your network from being used for attacking another. If you are concerned about the use of well-known ports, you should look into an IDS solution. Just my 2 cents.
Allowing all outgoing is definitely easier, and I used to be a big proponent of allowing free access out. But the longer I work in security, the more I lean toward locking things down. I'm even reconsidering my negative position on web proxies.
At the very least, block outgoing access to IRC. Many DDOS apps use this as a comm channel. Also consider blocking access to POP mail, 110. I saw a nasty instance where people checking their email accounts kept downloading viruses inside an organization, bypassing the mail gateway virus checker. And of course they had turned off local virus checking because it slowed down their pc's. The more tech-savvy your people, the more they are likely to bypass whatever security measures you have taken.
And yes, many annoying things can be set up to use port 80 for access. The best advice I have here is to use a url scanner, like WebSense or N2H2 to validate and control outgoing port 80 traffic.
Or, make everyone log in before allowing outbound access, and let them know that they are being logged. This often cuts WAY back on inappropriate use.
Whatever you do, make sure you have a written security policy in place and have management sign off on it. Be sure to list things like Kazaa as forbidden activities.
First thing, it's better to filter outgoing traffic than do nothing. But, you can partially filter the outgoing traffic, leave traffic from users going out and completely block traffic from your precious internal servers, where your valuable data are.
About ICQ & messenging service, i'm not sure if they will pass the fixup protocol http (activated by default). It's a test to do.
Thanks for your responses on this. Its given me some food for thought...
As a result, I'm currently doing the following:
o Creating a security policy!
o Considering a web proxy server - I've started testing Microsoft ISA 2000 server (in cache mode only) - it is currently placed on the DMZ and is handling requests from the inside. Because its in the DMZ it has been installed as a standalone server (unfortunate because I would have liked to gather logs on a per windows2000 user basis). MSN works OK through it (although slower) and I'm impressed that RealPlayer and Windows Media streaming seems to be working. The only hangup I have is that its Microsoft!!! ;-)
o Taking a look at WebSense and N2H2, although I don't think we need to go down this route - as far as I can see the only benefit that these products will give me is URL logging, and URL blocking. Not really any fundamental security benefits (I thought it may give me some IDS fuctionality).
I think the security policy is a good place to start - I'm going to need to document the raft of functionality that I see our users wanting, plus the connectivity needed to our 20 or so servers in the DMZ. Sigh!
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...