| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
![]() |
| Thread Tools |
| SuperIce |
|
|
|
| |
|
PES
Guest
Posts: n/a
|
"SuperIce" <> wrote in message news:. .. > Hi Folks, > > I've run into a bit of a problem using statics, having "proper" security > and having outside access from the DMZ. Hopefully I can explain this > clearly. (The public IPs are not our real ones.) > > I've grabbed what I think is all of the relevant info in my current > config and dumped it at the bottom. > > Previously I used NAT for everything. > Inside -> Outside PAT with a global > Inside -> DMZ NAT with a specific pool (see just below) > DMZ -> Outside (all of the server had static Public IPs mapped) > DMZ had no access inside. > > I wanted to give some of the DMZ hosts access to specific internal > services (i.e. FTP, DNS, NTP to specific machines and ports). I was > reading that statics were required and also it was better than NATting > to the DMZ since using statics is simpler to figure out which host was > which. So... > > The previous admin had the following: > global (outside) 1 100.100.100.110 netmask 255.255.255.240 > global (dmz1) 1 172.17.2.1-172.17.2.254 netmask 255.255.0.0 > global (dmz1) 2 172.17.3.1-172.17.3.254 netmask 255.255.0.0 > nat (inside) 0 access-list 150 > nat (inside) 1 172.16.1.0 255.255.255.0 0 0 > nat (inside) 1 172.16.2.0 255.255.255.0 0 0 > nat (inside) 1 172.16.3.0 255.255.255.0 0 0 > nat (inside) 2 172.16.4.0 255.255.255.0 0 0 > nat (inside) 1 172.16.5.0 255.255.255.0 0 0 > nat (dmz1) 0 access-list 150 > nat (dmz1) 1 172.17.1.0 255.255.255.0 0 0 > nat (dmz1) 1 0.0.0.0 0.0.0.0 0 0 > static (inside,outside) 100.100.100.99 172.16.1.50 netmask > 255.255.255.255 0 0 > static (dmz1,outside) 100.100.100.102 172.17.1.30 netmask > 255.255.255.255 0 0 > static (inside,outside) 100.100.100.106 172.16.3.15 netmask > 255.255.255.255 0 0 > access-group 130 in interface outside > access-group 110 in interface inside > access-group 120 in interface dmz1 > > I removed the nat (dmz1) 1 172.17.1.0 255.255.255.0 and setup some > statics > i.e. static (inside,dmz1) 172.16.1.0 172.16.1.0 netmask 255.255.255.0 0 > 0 > > This works correctly allowing inside to dmz without NAT. But the > previous admin had an ACL (on the dmz interface) that allowed ALL > traffic from dmz1 to inside. Since it was doing NAT without statics > before, this error didn't actually allow access. But adding the statics > removed the usual security that blocks lower to higher interfaces. > - access-list 120 permit tcp 172.17.1.0 255.255.255.0 any > > I removed it, and left only the few ACLs to allow dmz to inside that I > wanted. > i.e. access-list 120 permit udp 172.17.1.0 255.255.255.0 host > 172.16.1.10 eq ntp > access-list 120 permit udp 172.17.1.0 255.255.255.0 host 172.16.1.10 eq > domain > > This is where it breaks. Removing the access-list 120 permit tcp any > (dmz) corrects the problem of dmz having full access to inside (and > limits it to the ACLs), but now dmz hosts cannot go to outside. (Note > that all the dmz hosts have statics to outside with public IPs). Maybe > a non static host in DMZ would work, but we don't plan on having any. > > Hopefully that makes sense? I have to remove the ACL 120 that has a > permit ALL since it defeats the purpose of having a DMZ, but I still > retain the dmz to outside access for dmz hosts. > > If you have any suggestions, let me know. I'm probably staring the fix > in the face, but I am a bit lost, looks like I have spent too much time > coding and not enough managing the network. Any suggestions for fixing > the current problem are appreciated and I am always looking to improve > security if there are serious flaws in the rules below. > > Thanks! > > - James > To email me, remove the reversed "no-spam" from my address. > > This is the way the pix is designed to work. If there is no access list, everything is permitted to the less secure interfaces (than the source). If there is an access list, there is an implicit deny any any at the end. Therefore, as you previously mentioned, this is not a real issue except for where you build the statics back into the inside. To fix this, you would need to put a deny statement above for any of your statics and put a broader permit statement at the end. One might think that this would affect the traffic originating at interface (inside) to (dmz). However, this is not the case. Traffic that initially came in from the outside to dmz will also have its return traffic permitted. This is true because even though you have put a deny statement that exactly matches the traffic, the Pix ASA algorithm will place higher priority entries virtually that will allow the return traffice, assuming that it properly meets the criteria (src/dst prt/address, sequence numbers). example access-list dmz deny ip dmzaddress netmask publicaddressonstatic netmask access-list dmz permit ip dmzaddress netmask any > PiX v6.0(1) > access-list 150 permit ip 172.16.0.0 255.255.0.0 172.18.2.0 > 255.255.255.0 > access-list 150 permit ip 172.17.0.0 255.255.0.0 172.18.2.0 > 255.255.255.0 > access-list 150 permit ip 172.16.0.0 255.255.0.0 150.100.0.0 255.255.0.0 > access-list 110 permit tcp 172.16.5.0 255.255.255.0 host 10.10.10.29 eq > 3306 > access-list 110 permit tcp 172.16.5.0 255.255.255.0 host 10.10.10.245 eq > 3306 > access-list 110 permit tcp 172.16.5.0 255.255.255.0 172.17.1.0 > 255.255.255.0 > access-list 110 permit udp 172.16.5.0 255.255.255.0 172.17.1.0 > 255.255.255.0 > access-list 110 permit tcp 172.16.5.0 255.255.255.0 150.100.0.0 > 255.255.0.0 > access-list 110 permit tcp 172.16.5.0 255.255.255.0 host 20.10.10.138 eq > 3389 > access-list 110 permit ip 172.16.1.0 255.255.255.0 any > access-list 110 permit ip 172.16.2.0 255.255.255.0 any > access-list 110 permit ip 172.16.3.0 255.255.255.0 any > access-list 110 permit ip host 172.16.4.5 199.243.65.0 255.255.255.224 > access-list 110 permit tcp 172.16.5.0 255.255.255.0 host 20.10.10.136 eq > 22 > access-list 110 deny ip any any > access-list 120 permit icmp any any > access-list 120 permit udp 172.17.1.0 255.255.255.0 host 172.16.1.10 eq > ntp > access-list 120 permit udp 172.17.1.0 255.255.255.0 host 172.16.1.10 eq > domain > access-list 120 permit tcp host 172.17.1.31 host 172.16.1.50 eq smtp > access-list 120 permit tcp 172.17.1.0 255.255.255.0 any > access-list 120 permit udp 172.17.1.0 255.255.255.0 any > access-list 130 permit tcp any host 100.100.100.99 eq smtp > access-list 130 permit tcp any host 100.100.100.99 eq www > access-list 130 permit tcp any host 100.100.100.100 eq 22 > access-list 130 permit udp any host 100.100.100.100 eq domain > access-list 130 permit udp any host 100.100.100.101 eq domain > access-list 130 permit tcp any host 100.100.100.102 eq www > access-list 130 permit tcp any host 100.100.100.103 eq www > access-list 130 permit tcp any host 100.100.100.103 eq 443 > access-list 130 permit tcp any host 100.100.100.104 eq www > access-list 130 permit icmp any host 100.100.100.100 unreachable > access-list 130 permit icmp any host 100.100.100.100 time-exceeded > access-list 130 permit icmp any host 100.100.100.100 echo-reply > access-list 130 permit icmp any host 100.100.100.108 unreachable > access-list 130 permit icmp any host 100.100.100.108 time-exceeded > access-list 130 permit icmp any host 100.100.100.108 echo-reply > access-list 130 permit icmp any host 100.100.100.109 unreachable > access-list 130 permit icmp any host 100.100.100.109 time-exceeded > access-list 130 permit icmp any host 100.100.100.109 echo-reply > access-list 130 permit tcp host 10.10.10.29 host 100.100.100.103 eq ftp > access-list 130 permit tcp host 10.10.10.29 host 100.100.100.103 eq ftp- > data > access-list 130 permit tcp host 10.10.10.29 host 100.100.100.103 eq 3306 > access-list 130 permit tcp host 10.10.10.29 host 100.100.100.103 eq 22 > access-list 130 permit tcp host 10.10.10.245 host 100.100.100.103 eq ftp > access-list 130 permit tcp host 10.10.10.245 host 100.100.100.103 eq > ftp-data > access-list 130 permit tcp host 10.10.10.245 host 100.100.100.103 eq > 3306 > access-list 130 permit tcp host 10.10.10.245 host 100.100.100.103 eq 22 > access-list 130 permit tcp host 65.217.14.89 host 100.100.100.102 eq ftp > access-list 130 permit tcp host 65.217.14.89 host 100.100.100.102 eq > ftp-data > access-list 130 permit tcp host 65.217.14.89 host 100.100.100.102 eq > 1433 > access-list 130 permit tcp host 65.217.14.89 host 100.100.100.102 eq > 1723 > access-list 130 permit gre host 65.217.14.89 host 100.100.100.102 > access-list 130 permit tcp host 65.217.14.89 host 100.100.100.102 eq > 3389 > access-list 130 permit tcp host 65.217.14.89 host 100.100.100.104 eq > 8080 > access-list 130 permit tcp host 65.217.14.89 host 100.100.100.104 eq > 3389 > access-list 130 permit tcp host 68.209.107.216 host 100.100.100.102 eq > 1433 > access-list 130 permit tcp host 68.209.107.216 host 100.100.100.102 eq > 3389 > access-list 130 permit tcp host 68.209.107.216 host 100.100.100.104 eq > 3389 > access-list 130 permit tcp host 68.209.107.216 host 100.100.100.104 eq > 8080 > access-list 130 permit tcp host 66.172.134.58 host 100.100.100.102 eq > 1433 > access-list 130 permit tcp host 66.172.134.58 host 100.100.100.102 eq > 3389 > access-list 130 permit tcp host 66.172.134.58 host 100.100.100.104 eq > 3389 > access-list 130 permit tcp host 66.172.134.58 host 100.100.100.104 eq > 8080 > access-list 130 permit tcp 24.1.172.0 255.255.255.0 host 100.100.100.102 > eq ftp > access-list 130 permit tcp 24.1.172.0 255.255.255.0 host 100.100.100.102 > eq ftp-data > access-list 130 permit tcp 24.1.172.0 255.255.255.0 host 100.100.100.102 > eq 3389 > access-list 130 permit tcp 24.1.172.0 255.255.255.0 host 100.100.100.104 > eq ftp > access-list 130 permit tcp 24.1.172.0 255.255.255.0 host 100.100.100.104 > eq ftp-data > access-list 130 permit tcp 24.1.172.0 255.255.255.0 host 100.100.100.104 > eq 3389 > access-list 130 permit esp 50.50.50.0 255.255.255.224 host > 100.100.100.105 > access-list 130 permit gre host 60.60.60.204 host 100.100.100.108 > access-list 130 permit gre host 60.60.60.204 host 100.100.100.109 > access-list 130 permit tcp host 70.70.70.226 host 100.100.100.106 eq > 5954 > access-list 130 permit tcp host 70.70.70.227 host 100.100.100.106 eq > 5955 > access-list 160 permit ip 172.16.0.0 255.255.0.0 150.100.0.0 255.255.0.0 > ip address outside 100.100.100.98 255.255.255.240 > ip address inside 172.16.0.2 255.255.0.0 > ip address dmz1 172.17.0.1 255.255.0.0 > ip address dmz2 127.0.0.1 255.255.255.255 > ip address pix/intf4 127.0.0.1 255.255.255.255 > ip address pix/intf5 127.0.0.1 255.255.255.255 > ip audit info action alarm > ip audit attack action alarm > ip local pool pptp-pool 172.18.2.1-172.18.2.50 > global (outside) 1 100.100.100.110 netmask 255.255.255.240 > global (dmz1) 2 172.17.3.1-172.17.3.254 netmask 255.255.0.0 > nat (inside) 0 access-list 150 > nat (inside) 1 172.16.1.0 255.255.255.0 0 0 > nat (inside) 1 172.16.2.0 255.255.255.0 0 0 > nat (inside) 1 172.16.3.0 255.255.255.0 0 0 > nat (inside) 2 172.16.4.0 255.255.255.0 0 0 > nat (inside) 1 172.16.5.0 255.255.255.0 0 0 > nat (dmz1) 0 access-list 150 > nat (dmz1) 1 172.17.1.0 255.255.255.0 0 0 > nat (dmz1) 1 0.0.0.0 0.0.0.0 0 0 > static (inside,outside) 100.100.100.99 172.16.1.50 netmask > 255.255.255.255 0 0 > static (inside,outside) 100.100.100.109 172.16.2.1 netmask > 255.255.255.255 0 0 > static (inside,outside) 100.100.100.108 172.16.2.5 netmask > 255.255.255.255 0 0 > static (inside,outside) 100.100.100.100 172.16.1.10 netmask > 255.255.255.255 0 0 > static (inside,outside) 100.100.100.101 172.16.1.11 netmask > 255.255.255.255 0 0 > static (dmz1,outside) 100.100.100.102 172.17.1.30 netmask > 255.255.255.255 0 0 > static (dmz1,outside) 100.100.100.103 172.17.1.7 netmask 255.255.255.255 > 0 0 > static (dmz1,outside) 100.100.100.104 172.17.1.31 netmask > 255.255.255.255 0 0 > static (inside,outside) 100.100.100.106 172.16.3.15 netmask > 255.255.255.255 0 0 > static (inside,outside) 100.100.100.105 172.16.4.5 netmask > 255.255.255.255 0 0 > static (inside,dmz1) 172.16.1.0 172.16.1.0 netmask 255.255.255.0 0 0 > static (inside,dmz1) 172.16.2.0 172.16.2.0 netmask 255.255.255.0 0 0 > static (inside,dmz1) 172.16.3.0 172.16.3.0 netmask 255.255.255.0 0 0 > static (inside,dmz1) 172.16.4.0 172.16.4.0 netmask 255.255.255.0 0 0 > static (inside,dmz1) 172.16.5.0 172.16.5.0 netmask 255.255.255.0 0 0 > access-group 130 in interface outside > access-group 110 in interface inside > access-group 120 in interface dmz1 > route outside 0.0.0.0 0.0.0.0 100.100.100.97 1 > route inside 10.10.10.0 255.255.255.0 172.16.0.1 1 |
|
|
|
|
|||
|
|||
| PES |
|
|
|
| |
|
James
Guest
Posts: n/a
|
In article <>,
NO*SPAMpestewartREMOVE**SUCKS says... > > "SuperIce" <> wrote in message > news:. .. > > Hi Folks, > > > > I've run into a bit of a problem using statics, having "proper" security > > and having outside access from the DMZ. Hopefully I can explain this > > clearly. (The public IPs are not our real ones.) > > > > I've grabbed what I think is all of the relevant info in my current > > config and dumped it at the bottom. > > > > Previously I used NAT for everything. > > Inside -> Outside PAT with a global > > Inside -> DMZ NAT with a specific pool (see just below) > > DMZ -> Outside (all of the server had static Public IPs mapped) > > DMZ had no access inside. > > > > I wanted to give some of the DMZ hosts access to specific internal > > services (i.e. FTP, DNS, NTP to specific machines and ports). I was > > reading that statics were required and also it was better than NATting > > to the DMZ since using statics is simpler to figure out which host was > > which. So... > > > > The previous admin had the following: > > global (outside) 1 100.100.100.110 netmask 255.255.255.240 > > global (dmz1) 1 172.17.2.1-172.17.2.254 netmask 255.255.0.0 > > global (dmz1) 2 172.17.3.1-172.17.3.254 netmask 255.255.0.0 > > nat (inside) 0 access-list 150 > > nat (inside) 1 172.16.1.0 255.255.255.0 0 0 > > nat (inside) 1 172.16.2.0 255.255.255.0 0 0 > > nat (inside) 1 172.16.3.0 255.255.255.0 0 0 > > nat (inside) 2 172.16.4.0 255.255.255.0 0 0 > > nat (inside) 1 172.16.5.0 255.255.255.0 0 0 > > nat (dmz1) 0 access-list 150 > > nat (dmz1) 1 172.17.1.0 255.255.255.0 0 0 > > nat (dmz1) 1 0.0.0.0 0.0.0.0 0 0 > > static (inside,outside) 100.100.100.99 172.16.1.50 netmask > > 255.255.255.255 0 0 > > static (dmz1,outside) 100.100.100.102 172.17.1.30 netmask > > 255.255.255.255 0 0 > > static (inside,outside) 100.100.100.106 172.16.3.15 netmask > > 255.255.255.255 0 0 > > access-group 130 in interface outside > > access-group 110 in interface inside > > access-group 120 in interface dmz1 > > > > I removed the nat (dmz1) 1 172.17.1.0 255.255.255.0 and setup some > > statics > > i.e. static (inside,dmz1) 172.16.1.0 172.16.1.0 netmask 255.255.255.0 0 > > 0 > > > > This works correctly allowing inside to dmz without NAT. But the > > previous admin had an ACL (on the dmz interface) that allowed ALL > > traffic from dmz1 to inside. Since it was doing NAT without statics > > before, this error didn't actually allow access. But adding the statics > > removed the usual security that blocks lower to higher interfaces. > > - access-list 120 permit tcp 172.17.1.0 255.255.255.0 any > > > > I removed it, and left only the few ACLs to allow dmz to inside that I > > wanted. > > i.e. access-list 120 permit udp 172.17.1.0 255.255.255.0 host > > 172.16.1.10 eq ntp > > access-list 120 permit udp 172.17.1.0 255.255.255.0 host 172.16.1.10 eq > > domain > > > > This is where it breaks. Removing the access-list 120 permit tcp any > > (dmz) corrects the problem of dmz having full access to inside (and > > limits it to the ACLs), but now dmz hosts cannot go to outside. (Note > > that all the dmz hosts have statics to outside with public IPs). Maybe > > a non static host in DMZ would work, but we don't plan on having any. > > > > Hopefully that makes sense? I have to remove the ACL 120 that has a > > permit ALL since it defeats the purpose of having a DMZ, but I still > > retain the dmz to outside access for dmz hosts. > > > > If you have any suggestions, let me know. I'm probably staring the fix > > in the face, but I am a bit lost, looks like I have spent too much time > > coding and not enough managing the network. Any suggestions for fixing > > the current problem are appreciated and I am always looking to improve > > security if there are serious flaws in the rules below. > > > > Thanks! > > > > - James > > To email me, remove the reversed "no-spam" from my address. > > > > > > > This is the way the pix is designed to work. If there is no access list, > everything is permitted to the less secure interfaces (than the source). If > there is an access list, there is an implicit deny any any at the end. > Therefore, as you previously mentioned, this is not a real issue except for > where you build the statics back into the inside. To fix this, you would > need to put a deny statement above for any of your statics and put a broader > permit statement at the end. One might think that this would affect the > traffic originating at interface (inside) to (dmz). However, this is not > the case. Traffic that initially came in from the outside to dmz will also > have its return traffic permitted. This is true because even though you > have put a deny statement that exactly matches the traffic, the Pix ASA > algorithm will place higher priority entries virtually that will allow the > return traffice, assuming that it properly meets the criteria (src/dst > prt/address, sequence numbers). > > example > > access-list dmz deny ip dmzaddress netmask publicaddressonstatic netmask > access-list dmz permit ip dmzaddress netmask any Thank you for the insight. I knew it wasn't a problem with the PIX but that my approach was missing something. Sometimes one needs a little nudge in the right direction (or a good example in this case to figure it out). I'll give it a whirl after hours tonight and see what happens. Thanks again! - James |
|
|
|
|
|||
|
|||
| James |
|
|
|
| |
![]() |
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| help with pix inside->outside + dmz->outside + inside->outside->dmz | Jack | Cisco | 0 | 09-19-2007 01:57 AM |
| lifetime of global statics vs. statics in functions | Stuart MacMartin | C++ | 5 | 07-27-2005 04:19 PM |
| how to config 515-e-dmz dmz routes & ACL? | JohnC | Cisco | 9 | 12-07-2004 09:14 AM |
| procs/blocks - blocks with procs, blocks with blocks? | matt | Ruby | 1 | 08-06-2004 01:33 AM |
| PIX 515 - Slow performance to DMZ and outside Interface | Skipdog | Cisco | 1 | 02-09-2004 11:51 PM |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc..
SEO by vBSEO ©2010, Crawlability, Inc. |




