IOS Firewall SPI and NAPT

IOS: C2600-IK9O3S-M, Version 12.3(26)

I'm using SPI and NAT (partial cfg below). If an attacker knows my public address and guesses an active port in the translation table for a computer on the inside, will incoming packets be allowed or blocked? If they are blocked, is it NAT or SPI process that's doing the blocking?

ip inspect name myfw tcp ip inspect name myfw udp ip inspect myfw out (applied to outside interface)

ip nat inside source list 101 interface FastEthernet0/0 overload (no static mappings)

Reply to
bobneworleans
Loading thread data ...

snipped-for-privacy@yahoo.com schrieb:

The inspection creates temporary access list entries in the inbound ACL of your FastEthernet0/0 interface for the returning traffic when the connection is created from the inside to the outside.

These ACEs contain both source ip address/port and destination address/port and are inserted on top of the access list.

So if an attacker guesses the source port he also needs to spoof the source address to get his packet through the pinhole. No matter if there is a port address overload or not which makes the guessing only a little bit harder. IOS provides countermeasures against ip spoofing.

Reply to
Uli Link

As already mentioned, but with a bit more detail here, TCP or UDP sessions are identified as SourceIP:SourcePort:DestIP:DestPort

This is a 32 + 16 + 32 + 16 =3D 96 bit number all of which must match to correctly identify the session. This applies to dynamic NAT and to dynamic firewall "holes" and to the IP stack in the hosts.

The number of different such combinations when written as a decimal number will be about 30 digits long (29 I think) so there are quite a few to choose from if you want to influence an existing session.

Additionally decent firewalls will likely look at further information such as the presence of plausible TCP sequence numbers/ack numbers or other deeper information. This is why it is important to use good randomisation when selecting the TCP initial sequence number. Some older TCP stacks did not do this well enough but they will be mostly long gone by now I would think.

sh ip nat tr Pro Inside global Inside local Outside local Outside global tcp 93.7.21.29:64389 10.0.3.130:64389 67.44.85.106:80 67.43.85.106:80

The packet will be dropped by whatever mechanism fails to find a match first.

If you look at the Cicsco document "NAT order of operation" you will likely find whether the firewall code or the NAT code is run first on an inbound packet.

Reply to
bod43

bod43 gave an example of a nat table entry:

I've noticed that all of my outside local addresses always exactly match the outside global. Assuming that you mistyped one of your second octets, this is true in your example too. Is this because "ip nat inside" only translates inside addresses while outside addresses never need translation?

Thank you. That was very helpful. Based on that document, the packet is actually blocked by the inbound access list applied to the outside interface with its implicit deny all. (Combined with the fact that ip inspect did not create a pinhole that exactly matched the 5-tuple of protocol, source ip & port, destination ip & port for the incoming packet.)

Reply to
bobneworleans

Ah yes I mangled the adresses:) - but not very well.

Well for Internet access the outside addresses do not normally need to be translated since they are "registered" addresses that are supposed to be globally unique.

You can do double NAT (not the official term I wouldn't suppose) if required. Indeed the very first NAT work I ever did was to be sent to a customer as a "Consultant" to sort out their internal double NAT.

My head hurt a LOT but it all miraculously burst into life:)

Some service providers (private networks) use double NAT in all cases to ensure that no address clashes can ever occur. They typically connect two customers over a private network. Each customer of course uses their own internal addressing scheme, and the service provider has their own too.

BT Radianz for example do this. This of course is troublesome to manage and especially to troubleshoot but serious problems are very rare. I would guess that if they were starting now they might use MPLS or some other tunneling that the customer need not be aware of instead.

Reply to
bod43

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.