Re: NAT overload as security [7:66015]
I work with a lot of different vendors firewalls and IMO PAT is a security feature (to a degree). like many other security features its not perfect by itself, but when combined with other features its creates a full firewall. technically PAT alone would be an aspect of stateful inspection/translation, which is a first generation firewall. as you already stated though, you have no idea whats in the incoming packets above layer 4, so thats the risk. of course if you had a static translation or regular NAT, thats a whole different story. scott ""Doug S"" wrote in message news:[EMAIL PROTECTED] > 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 pro
RE: NAT overload as security [7:66015]
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:145612.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,
RE: NAT overload as security [7:66015]
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 LOCALINSIDE 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). Ver
