A couple of reasons why its not enough .. imagine you inadvertently run and execute a trojan on your home pc. This will then connect out to the internet and would be valid remote control access. Often these trojans head out to IRC, where peolpe can actually access / manage your computer user various DCC commands. Since the irc connection is initiated from your PC, all the return traffic will be allowed and excuted locally.
Just one example. Some other to think about are those "special" traffic that have control ports and data ports, eg FTP, multilmedia apps etC? dave petit wrote: > > That,s not enough, download and read the cisco security > executive summary at > the link below for good tips on hardening your router. > > http://www.nsa.gov/snac/cisco/download.htm > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of > Doug S > Sent: Saturday, March 22, 2003 11:35 PM > To: [EMAIL PROTECTED] > Subject: NAT overload as security [7:66015] > > > On my home network, I rely almost exclusively on NAT overload > for security. > Even though I know it's not a security measure, I've yet to > hear anyone with > a good explanation of why it's not enough, at least for a home > network. I > know there's a bunch of really bright people here, so if anyone > would point > out the flaws in my reasoning, I'd love to hear it. > > Below are some exerpts from an email converstation with a > friend that > explain how I think about it: > > --------------------------------------------------------------- > > I mostly rely on NAT overload for security. The only traffic > that will be > allowed in is traffic for which a translation has been > created. Since these > translations are only created by outbound traffic, no one from > the outside > can initiate a connection unless they bypass NAT by using the > actual private > ip addresses configured on the workstation. To do that, > they'de have to > have no routers between them and my router (meaning my ATT > segment only) as > any other router would drop packets for these addresses. To > protect against > that, I deny traffic for the ip's configured behind the router. > > access-list 151 deny any 192.168.0.0 0.0.0.255 > access-list 151 permit any any > (this whole acl could just as well be: > access-list 165 permit any host (outside int IP address) > > access-list 50 permit 192.168.0.0 0.0.0.255 > > Int e0 > ip address 192.168.0.1 255.255.255.0 > ip nat inside > > Int e1 > ip address dhcp > ip nat outside > ip access-group 51 in > > ip nat inside source list 50 int e1 overload > > ---------------------------------------------------------------- > > Even though NAT isn't a security feature, I think overload > works pretty well > for security because no traffic will be allowed in unless an > inside host has > created a NAT entry by originating the flow. All legitimate > flows on a home > network are going to be created by CLIENT processes running on > the machine, > so what do I care if someone tries to connect to that port. > What I mean is: > > 1) I go to surf the web at 200.200.200.200, my workstation uses > tcp port > 1456 to connect to tcp port 80 > > 2a) tcp port 1456 is taking in traffic only for web browser, > which is a > client application that's only going to display what's sent > back to my > browser. > > 2b) as this traffic passes through the router a NAT entry is > created: > INSIDE LOCAL INSIDE GLOBAL OUSIDE GLOBAL > 192.168.0.100:1456 12.228.99.129:1456 200.200.200.200:80 > > 3) A 'hole' has been created that now allows traffic to my > workstation. > > 4) A really good hacker wants to exploit this hole. To do > this, s/he's > going to have to do a few tricky things: > > First, since this translation is only going allow traffic only > from > 200.200.200.200:80 to be sent to 192.168.0.100:1456, s/he's > going to have to > figure out how to spoof that address/port pair AND get the > return traffic > back to his machine (if he wants any return traffic there might > be) > > Second, since it's only my web browser, and not some service > that's running > on port 1456, the only traffic that could possibly even be > interpreted on > that port would be html. And since that port is maintaining > the tcp stream > info from the original connection (seq #'s ack's) s/he's going > to have to > accurately spoof that too. If all this is sucessful, I guess > there is > malicious html code that s/he could run, but wouldn't it have > been easier > for the hacker just to put it up on a website and let me click > on it myself? > > To me it seems like NAT overload on home computers meets the > security idea > of making it more difficult than what it's worth for the > hacker. There is > no way I would ever rely on this on a production network with > services > available, themselves initiating connections. I'd really like > to hear a > security expert's views about these ideas, but so far, no one > I've talked to > has explained to me a way that a hacker could get past NAT > overload. > > The only two ways I can think of are > 1)bypass NAT by using the actual configured ip's of the > workstations inside > > 2)Get you to install software on you're machine that will both > create a nat > translation to the outside and let them connect back through > that > translation to a SERVICE that's listening on that port. If > they are able to > do that, even CBAC isn't going to stop them anyhow. > > Access lists trying to protect home workstations that are being > NAT'ed seem > for the most part redundant to me. > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003 > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66065&t=66015 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
