dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
27913

Daniel
MVM
join:2000-06-26
San Francisco, CA

2 edits

2 recommendations

Daniel

MVM

NAT vs. SPI: What's The Difference?

Poll
How does NAT technology compare to Stateful Packet Inspection technology in terms of protection?

NAT is completely different - and inferior.

NAT is completely different - but not inferior.

NAT is superior to SPI.

They are very similar - SPI is just more comprehensive.

They are very similar - the differences are in how you define each.

Don't know.


Votes:105


--
In the vein of this thread, I decided it may be helpful to discuss the actual differences between NAT and SPI.

In fact, as mentioned in the thread linked to above, modern-day NAT implementations, even those on the cheapest SOHO routers, employ quite a few elements when populating their state table - not just source and destination IPs and ports. There is TCP flag information, TCP sequence numbers, etc.

This begs the question: "Well if NAT does all that, and builds a table based on all this information, then what does SPI do that makes it better?"

The answer to that question enters into the realm of nebulous definitions given by vendors and general interpretation of what terms mean. For that reason, it's not an easy question to answer.

In short, both technologies build tables in which they house connection information about legitimate traffic. SPI, however, is technology designed to do this in an extensive and thorough fashion, allowing it to go above and beyond what a "simple" NAT table does.

Whether or not this is the case or not for product a or product b remains to be seen.

Thoughts?
qrkx
Premium Member
join:2003-04-26
Montreal, QC

qrkx

Premium Member

"NAT is completely different - but not inferior"

NAT facilitates network transport as it was intended to do. If a packet hits the wan side of a nat device and there is no matching entries it is passed to the nat device operating system TCP/IP stack.

Packet filtering (Stateful or not) drops such packets based on acls and/or state analysis before they reach the os stack.

I would believe the two technologies play fundamentally different roles: one tries to address network transport, the other enforces access control filters.

rgds.

heels_fan
1.20.09 The start of Socialism
Premium Member
join:2003-02-07
Columbia, TN

heels_fan to Daniel

Premium Member

to Daniel
see my post here
»Re: NAT = Hack Proof?
here goes into SPI and NAT

Daniel
MVM
join:2000-06-26
San Francisco, CA

2 edits

Daniel to qrkx

MVM

to qrkx
said by qrkx:

I would believe the two technologies play fundamentally different roles: one tries to address network transport, the other enforces access control filters.
I'd say NAT can be seen as an access control system - albeit a very simple, one-dimentional one. You don't write complex rules for it, but the idea that sans inbound PAT rules you can't generally get traffic in makes for a fairly strong layer in my opinion.
Daniel

Daniel to heels_fan

MVM

to heels_fan
said by heels_fan:

see my post here
»Re: NAT = Hack Proof?
here goes into SPI and NAT
Actually, the topic of whether or not NAT is breakable is separate from the difference between NAT and SPI. That's why rather than hijacking your thread I made a new one.
qrkx
Premium Member
join:2003-04-26
Montreal, QC

qrkx to Daniel

Premium Member

to Daniel
OK. Let's take a simple example:

Internet
|
---WAN (running web based remote administration on 443)
|
|
-------DMZ (web,mail,etc servers)
|
|
LAN

I want to connect to the WAN interface web based admin tool. I send a SYN to WAN IP TCP 443.

There is no match in the NAT table.

Packet gets dropped by NAT. ????

Get it?

rgds.

bbarrera
MVM
join:2000-10-23
Sacramento, CA

bbarrera to Daniel

MVM

to Daniel

SPI protects a block of public IP addresses

My SPI router can route and protect a block of public IP addresses. Impossible with a NAT router.

Go look at CheckPoint's Firewall 1 if you want to see the real power of SPI. After all, they invented the term SPI.

Daniel
MVM
join:2000-06-26
San Francisco, CA

2 edits

Daniel to qrkx

MVM

to qrkx

Re: NAT vs. SPI: What's The Difference?

said by qrkx:

OK. Let's take a simple example:

Internet
|
---WAN (running web based remote administration on 443)
|
|
-------DMZ (web,mail,etc servers)
|
|
LAN

I want to connect to the WAN interface web based admin tool. I send a SYN to WAN IP TCP 443.

There is no match in the NAT table.

Packet gets dropped by NAT. ????
True enough. So what's preventing the packet, once it gets to the stack, from being routed inside?

Say for example I spoof a packet to 192.168.1.2 from the WAN side - what stops it from being sent to the stack, the stack seeing that it has a route for that network, and sending it along?

I'd argue that systems with NAT implementations actually are pseudo-DMZ'd so that after NAT the only destination allowed is the external address being listened on. In other words, there aren't multiple paths; you either go through NAT or you don't go at all.

If packets could just make it to the routing engine normally, SOHO routers would be nothing but little routers with no ACLs.

I'll yield to your experience with this, and the topic is invigorating. I am thinking about these issues based on what I have seen, whereas you have coded them.
qrkx
Premium Member
join:2003-04-26
Montreal, QC

1 edit

qrkx

Premium Member

said by Daniel:
True enough. So what's preventing the packet, once it gets to the stack, from being routed inside?

Say for example I spoof a packet to 192.168.1.2 from the WAN side - what stops it from being sent to the stack, the stack seeing that it has a route for that network, and sending it along?

I'd argue that systems with NAT implementations actually are pseudo-DMZ'd so that after NAT the only destination allowed is the external address being listened on. In other words, there aren't multiple paths; you either go through NAT or you don't go at all.

If packets could just make it to the routing engine normally, SOHO routers would be nothing but little routers with no ACLs.

I'll yield to your experience with this. I am thinking about these issues based on what I have seen whereas you have coded them.

Just for historical accuracy: I do not code drivers. Although I am extremely privileged to have the best kernel developers on my team.

Now on to your point: you are once again re-enforcing the difference between "routing" modules and "security" modules. You could send a spoofed packet that m,ight confuse certain nat / router implementations. But that is not the point. The task at hand is what happens to the packet after it doesn't match a nat entry? It either reaches the stack or it is dropped by a packet filtering alg. However subtle - this is the main point.

Consider this scenario:

OS whatever kernel 2.4.x.y panics when a malformed IP packet with strange IP options/length value is sent.

This packet is dropped by proper packet filtering/normalizing analysis (whatever proper means ). NAT has nothing to do with that. You can verify this on your own.

If there is no routing rule - the spoofed packet will have the fate of being discarded by the os stack in the absence of packet filtering. Unless....the nat implementation decides to behave incorrectly.

rgds.

gkweb
join:2003-06-09
Fort Worth, TX

1 edit

gkweb to Daniel

Member

to Daniel
Very great idea to start this topic Daniel

I answered :
"They are very similar - SPI is just more comprehensive."

For me (I may be wrong, I just offer a definition), the basic NAT will works with tuples (srcIP:srcPort - dstIP:dstPort) and will not check packets states (TCP flags, Sequence number, etc...).

The SPI is an improved NAT, in the table it takes in count more than the previous tuple, it can check also various fields such as the TCP sequence number, the timestamp, check if an ICMP packet "port unreachable" coming back is linked to a port that has been tried to be reached with UDP, etc...
There is no "state" between UDP and ICMP, only SPI can handle such case.

However, not all SPI handle the same things.
For instance, while NetFilter from Linux is a statefull firewall, it does not check the TCP sequence number (at least it didn't the last time I checked), whereas
Packet Filter from BSD OSs does (for NetFilter this capability is available throught an experimental extension).

So I suppose that out there, many "SPI" commercial products in fact could be very different in strenght.

That's just my point of view, not facts taken from RFCs, I am interested in other opinions as well.

Regards,

gkweb.

BeesTea
Internet Janitor
Premium Member
join:2003-03-08
00000

BeesTea to Daniel

Premium Member

to Daniel
said by Daniel:

Poll: How does NAT technology compare to Stateful Packet Inspection technology in terms of protection?
In terms of protection, real protection, the answer is no comparison really.

This question is very similar to the comparison years ago between ethernet hubs and switches. Many people swore that a switched network provided a layer of security. When in reality it did not. It did provide the appearance of protection, but that appearance was but an illusion. Then along came tools like dsniff. Dsniff demonstrated to everyone that a switch was infact not a security layer, but rather just what it was designed to be. An ethernet switch.

So here we have a similar question. We have NAT, a network address translator, and we have "SPI", a true packet filter. These tools were designed for completely different purposes. One to provide networking, and one to provide security. There exists tools readily available right now that are the "dsniff" of NAT. Tools like nemesis, for example, allow the crafting and injection of any packet one could possibly dream up. Those packets can be crafted to comply to whatever policy a NAT may be told to honor and a NAT will do just that, pass them right along.

NAT as a security mechanism is an illusion, a side-effect if you will. It may appear to control you connection, but in reality it's only a one way mechanism. SPI filtering on the other hand is an actual security mechanism by design. It's sole purpose is to enforce policy.

Containment is a large part of security, NAT provides none. Once something gets in, it's all over.

I'm certain that a lot of folks believe that this is all BS, and that so long as someone on the internet cannot directly access their system, they must be fine. What protects those users from the IFRAME injected, uniquely compiled, polybot that is undetectable by their AV software ? It isn't NAT, as NAT will simply allow that outbound tcp connection to the rogue IRCD acting as command ad control. What protects them is their outbound stateful packet filter that allows tcp connections only to intended services and destinations.

I'll take real security any day over the appearance of it.

Cheers,
-BeesT

TerryMiller
Premium Member
join:2003-10-23

TerryMiller to Daniel

Premium Member

to Daniel
I voted that Nat is completely different-but not inferior.

It was a tough choice and I was definitely conflicted.

Nat will not pass traffic that doesn't have matching SIP, DIP, sPort & DPort entries.

SPI may include not receiving a second ACK packet on an already in-place connection, but who really knows given the state of current vendors.

What is "Stateful" now, just monitoring the state to not accept the second ACK. Or is it checking to ensure that the command is legitimate based on the protocol. The definition of SPI seems to differ with the vendor. How much application level control is required to qualify as "true SPI" varies with the vendor.

What level the user requires also varies. Any Nat works well with a home network and no ports forwarded. As soon as an expoitable port is forwarded then all bets are off based on the exploitability of the service behind it, the application running and the risk tolerance of the person running the network.

Nerdtalker
Working Hard, Or Hardly Working?
MVM
join:2003-02-18
San Jose, CA

Nerdtalker to Daniel

MVM

to Daniel
I voted " They are very similar - SPI is just more comprehensive."

When used together, the two are very powerful. Stateful packet inspection tracks each connection traversing all interfaces of the firewall and makes sure they are valid. NAT (by definition, from what I understand) simply allows more than one private IP address behind the device to use a single routable, public IP. NAT, as far as I'm concerned, is synonymous with the level of security most home routers provide.
dave
Premium Member
join:2000-05-04
not in ohio

1 recommendation

dave to TerryMiller

Premium Member

to TerryMiller
said by TerryMiller:

The definition of SPI seems to differ with the vendor.
Well, that's because as long as you 'inspect' a 'packet' in the context of some 'state', it qualifies. 'SPI' is an almost meaningless term. Vendors should spell out what exactly their equipment does.

EGeezer
Premium Member
join:2002-08-04
Midwest

EGeezer to Daniel

Premium Member

to Daniel

NAT vs. SPI: Wrench vs. Turkey Baster

To me, it's like asking "which is a better weapon against attackers - a torque wrench or a turkey baster?"

My recollection is that NAT was employed to reduce the need for public IP addresses for every device that might communicate over the internet by allowing people to set up private networks. It wasn't designed or introduced as a security standard but had the serindipitous characteristic of providing some protection against intrusion from outside the private domain.

I also recall SPI was implemented to complement NAT and reduce the problems caused by volumes of extraneous traffic not meant for target system(s) inside a private network. It, too, has the ability to provide some security function in addition to its LAN bandwidth conserving capabilities.

So you could whack an attacker with a torque wrench and squirt scalding gravy in an attackers face to protect you from assaults, but neither were specifically designed for those defensive purposeses.

Therein lies the problems with TCP/IP as it stands today. It wasn't designed and constructed to be a secure protocol, but has been adapted and wielded about to achieve a partially effective one.

Daniel
MVM
join:2000-06-26
San Francisco, CA

Daniel to BeesTea

MVM

to BeesTea

Re: NAT vs. SPI: What's The Difference?

said by BeesTea:

We have NAT, a network address translator, and we have "SPI", a true packet filter. These tools were designed for completely different purposes. One to provide networking, and one to provide security.
Ultimately though, what was going through the mind of the designers of a particular thing isn't so important when looking at the result. Let's look at the similarities.

1. Both construct a table which contains various pieces of information about the connections being kept track of.
2. Both stop a certain type of processing when those checks are not completed successfully.

So, both have a "state table", and both check against said table in order to determine whether or not something is legit or not. You mention that NAT can be bypassed if one were to create a packet that matched all the rules in the table. Well, the problem with pointing this out is that the same is true for the SPI table. If you create a packet using whatever tool that matches all rules in that table, the traffic will go right through as well.

What, fundamentally, is different about these two "state tables" other than the fact that rules are ANY->ANY=ALLOW when going from inside to outside for the NAT side? Obviously that's a huge problem if it was being used as the only layer for security, but many security layers are weak in and of themselves.

The question is whether or not it offers any additional protection when used in conjunction with packet filtering for processing inbound packets. I'd say it does. This doesn't make it "strong" or "true" security, but it does mean that when enabling access on a NAT/Filtering firewall device, one must enable both portions of the connectivity to get it to work. If you make the packet filter rule without doing the translation, you don't get passed traffic.

Recognize that just about every single security layer can be broken. Tripwire can be bypassed, as can Cisco IOS ACLs. This, however, doesn't mean that installing one or both of those doesn't equate to adding layers of security. I'd argue that the addition of NAT to the equation of a simple packet filtering (or stateful) firewall system follows this same vein.

TerryMiller
Premium Member
join:2003-10-23

TerryMiller to Daniel

Premium Member

to Daniel
Maybe "SPI" should now be subdivided.

State Inspection: Once a connection is made no further connections can be made.

DOS protection: Recognize common malformed packets that cause Denial of Service.

Protocol Inspection: Include State Inspection and ensure that the commands are valid for a given protocol.

Application Inspection: Include the previous two and also inspect for common exploits.

From then on come the specialized appliances. Even State Inspection though is enough to protect most home users.

Daniel
MVM
join:2000-06-26
San Francisco, CA

Daniel to qrkx

MVM

to qrkx
said by qrkx:

Consider this scenario:

OS whatever kernel 2.4.x.y panics when a malformed IP packet with strange IP options/length value is sent.

This packet is dropped by proper packet filtering/normalizing analysis (whatever proper means ). NAT has nothing to do with that. You can verify this on your own.

If there is no routing rule - the spoofed packet will have the fate of being discarded by the os stack in the absence of packet filtering. Unless....the nat implementation decides to behave incorrectly.
Ok, this is getting interesting. Could you somehow diagram out what the traffic path looks like with:

1. A NAT/Firewall system where the inbound packet doesn't match the state table.
2. A NAT/Firewall system where the inbound packet does match the state table.

My first thought here (after coming up fruitless with cursory google searches) is that access to routing is restricted unless a packet has *successfully* passed the NAT table. In other words, the packet doesn't "die", but it's not able to pass through to the other interfaces on the box. The destination port in the request better be listening on the "external" address, i.e. the one in the original IP header, or else the packet will be dropped.

I'll tell you what would be awesome is some links (if anyone can find some) containing diagrams of data paths of traffic moving through various NAT/Packet FIltering devices. I'll try and dig some up for Check Point and IPTables. If anyone could find some for some common SOHO routers that'd be great.
Daniel

Daniel to TerryMiller

MVM

to TerryMiller
said by TerryMiller:

Maybe "SPI" should now be subdivided.

State Inspection: Once a connection is made no further connections can be made.

DOS protection: Recognize common malformed packets that cause Denial of Service.

Protocol Inspection: Include State Inspection and ensure that the commands are valid for a given protocol.

Application Inspection: Include the previous two and also inspect for common exploits.
Well, yeah, the problem does lie in the definitions often times. Stateful inspection or the newer "deep" inspection is so fuzzy. I spent over an hour with the regional SE for Check Point discussing it a while back, and what it basically boiled down to after stripping out the detail is simple:

It's the amount of detailed information that a system provides for determining whether or not a given data stream is legitimate or not.

That's my definition - not an official one. The trick here is that all these various implementations are trying to do the same thing; they are trying to peer into various layers and figure out this and that about a connection. But ultimately they are all trying to do the same thing, which is figure out whether or not something malicious is taking place.

Bad IP addresses, incorrect TCP flags, erroneous sequence numbers, harmful HTTP or FTP payload - all of these things are covered with different technologies. Application proxies, packet filters, stateful inspection, etc. Ultimately though, they are just looking at different layers (3 or 4 in this case) and trying to make sure that the only thing passing the device is legitimate traffic.

Each time an additional check along this same vein is added, and a marketing team is alerted to this fact, a piece of literature is produced describing the "deep", "full", "true", "stateful", or whatever inspection that they and no one else has. This is what has lead to all the confusion.

It's all still TCP/IP traffic with 7 layers. Finding out a way to populate a table with more and more information about one or all of these layers (and then checking vs. it) is an incrimental improvement on existing technology - not a new one. Some do it better than others, but the goal is the same.

TerryMiller
Premium Member
join:2003-10-23

1 recommendation

TerryMiller

Premium Member

I guess then is how do you explain to the average user the difference between the SPI checkbox on a Linksys WRT54G, a Pix or a Check Point appliance. After all they all have SPI.

This is the stuff that makes people's eyes glaze over and look at me like I'm talking about chicken bones and Tarot cards.

Daniel
MVM
join:2000-06-26
San Francisco, CA

1 edit

Daniel

MVM

said by TerryMiller:

I guess then is how do you explain to the average user the difference between the SPI checkbox on a Linksys WRT54G, a Pix or a Check Point appliance. After all they all have SPI.
The number of, and quality of, checks that occur on traffic traversing the two systems. You can check just the basics (the tuple and make sure SYNs only go outbound) and be SPI by definition, since all you have to do to gain that title technically is "track state".

Proving that you do more than that is a very technical matter (as you point out), and this is what the marketing trash has been invented to address. Check Point's offering is based on INSPECT, which is kept quite secret. They don't want anyone doing it the way they do it.

I think what I'll do after I get over my WoW obsession is do some testing with hping and nemesis using a few different NAT/Filtering systems. Check Point, IPTables, and a couple SOHO offerings. That should be fun.

Link Logger
MVM
join:2001-03-29
Calgary, AB

Link Logger to Daniel

MVM

to Daniel
OK in layman's terms the difference between NAT and SPI. NAT is a big dumb brute, don't have a key (an entry in the NAT table), your not getting past period, he bops you in the head and chucks you in the bit bucket, however the brute isn't very smart and can be fooled by a stick that looks like a key, so he lets you by. SPI is a keymaster who actually inspects the key and figures out if the key is real and will actually open the lock (NOTE some keymasters look a little more closely then others). Why do the two work so well together, because the brute is fast and the keymaster is meticulous so they are a perfect match. The brute reduces the amount of work the keymaster has to do, plus the brute has big pockets and can keep a lot of information which the keymaster can use to determine if the key is legit. NAT is a network layer, SPI is the security layer. So NAT on its own has security issues, SPI on its own has performance issues (want to inspect every packet?).

Blake

BeesTea
Internet Janitor
Premium Member
join:2003-03-08
00000

BeesTea to Daniel

Premium Member

to Daniel
Here's an example of a system with NAT as it's protection in action. This is pulled from the stream of an infected system. I've obfuscated the source, remote victim, and victim on my network.

Captured with ngrep.
T 2004/12/03 00:29:46.545478 xxx.xxx.xxx.xxx:6669 -> xxx.xxx.xxx.xxx:1641 [AP]
:[SCAN]-LOLZ-5135!~A1C2@xxx.xxx.xxx.xxx PRIVMSG ##l0lz## Random Scanner: 192.168.x.x:44
*5 delay 3 seconds...

T 2004/12/03 00:29:48.316342 xxx.xxx.xxx.xxx:6669 -> xxx.xxx.xxx.xxx:1641 [AP]
:[SCAN]-LOLZ-5135!~A1C2@xxx.xxx.xxx.xxx PRIVMSG ##l0lz## :[lsass]: Exploiting IP: 192.16
*8.0.3...

(*) WARNING 2 long line(s) split

This is a host, behind a NAT, that was somehow infected with a bot. The bot then scanned other systems behind the NAT, resulting in at least one additional compromise. The NAT did nothing to keep these hosts from participating in the botnet. Along with this channel, the botnet was also keylogging.

Had this network been using a filter, or these systems a host-based firewall, this likely would not have happened. The initial host would have been compromised, but at no point would anyone else have had control of the host, nor would the bot been able to receive it's orders from the channel topic. Note the timestamp. It took 2 seconds to 445 scan and attack the other host.

Initial analysis of the bot payload results in no hits from symantec, f-prot, or clamav. Likely this is a unique bot. Something seen daily. I'll check it against other scanners in the morning once I have access to a win32 system.

Cheers,
-BeesT

Link Logger
MVM
join:2001-03-29
Calgary, AB

Link Logger

MVM

So are you saying you had unsolicited traffic which got past a NAT? Could you tell us what NAT was in use as I see thousands of these scans a day bounce off a 'NAT' box here (1992 hits to TCP port 445 of them on Nov 30 for example).

Blake

BeesTea
Internet Janitor
Premium Member
join:2003-03-08
00000

1 edit

BeesTea

Premium Member

said by Link Logger:

So are you saying you had unsolicited traffic which got past a NAT? Could you tell us what NAT was in use as I see thousands of these scans a day bounce off a 'NAT' box here (1992 hits to TCP port 445 of them on Nov 30 for example).

Blake
No, I clearly posted "that was somehow infected with a bot". The infected NAT protected host isn't on my network, I'm seeing it reporting to the channel to the infected host on my network. The host on my network was likely infected via p2p.

Are you under the impression that you have a unidirectional network connection ? There's more to network security than keeping unsolicited traffic out. This is just an example of the additional risk of just a NAT. No extrusion control.

As with the other thread, I'm done posting to this one as well. The technical reality is present, what you choose to believe or disbelieve is your own business, and really no concern of mine. I'm not interested in debating the weather with you.

-BeesT
jetspeed
join:2004-02-19
Flushing, NY

jetspeed to Daniel

Member

to Daniel
It's interesting how NAT can even be compared with SPI. I think this security perspective has been grossly taken out of context. The original intent of NAT was to provide a short-term solution for the depletion of public IPv4 addresses. The solution was to enable the reuse of IP addresses in private networks until other long-term solution for depletion of IP address gets developed (Such as IPv6). See RFC. 1631

The original design of NAT was not intended for security as the other thread might suggest. NAT introduced privacy not security in that the internal host behind a NAT router cannot be directly monitored because the real IP address of the internal host is hidden and translated. If you want to call this NAT translation a "security" feature that is fine however, that was not what it was designed for.
Firewalls with SPI was designed for that "security" purpose and it cannot be compared with NAT. A different thing altogether.

Just my 2 cents.
qrkx
Premium Member
join:2003-04-26
Montreal, QC

qrkx to Daniel

Premium Member

to Daniel
said by Daniel:
Ok, this is getting interesting. Could you somehow diagram out what the traffic path looks like with:

1. A NAT/Firewall system where the inbound packet doesn't match the state table.
2. A NAT/Firewall system where the inbound packet does match the state table.

My first thought here (after coming up fruitless with cursory google searches) is that access to routing is restricted unless a packet has *successfully* passed the NAT table. In other words, the packet doesn't "die", but it's not able to pass through to the other interfaces on the box. The destination port in the request better be listening on the "external" address, i.e. the one in the original IP header, or else the packet will be dropped.

I'll tell you what would be awesome is some links (if anyone can find some) containing diagrams of data paths of traffic moving through various NAT/Packet FIltering devices. I'll try and dig some up for Check Point and IPTables. If anyone could find some for some common SOHO routers that'd be great.

I'm trying to think what is the best way to diagram this...Not very good at art but let's try this:

SYN ---> NAT---->SPF--->Socket (e.g.some TCP service listening on port 3000)

SPF may be in front of NAT depending on implementations (e.g optimization reasons).

So Incoming SYN dstport=3000 is checked against nat and then spf rules (or viceversa). If a match is found in the nat table AND is not denied by pf rules packet gets nat-ed and the SYN will never be passed to the daemon listening on 3000. Packet does not have a match in the nat table AND is not dropped by the spf then it is delivered to the daemon and normal handshake occurs.

Hence:

1.NAT does not discard packets with no matching entry.
2.The spf will if there are matching acls.

The only variation in implementations would be which module deals with the packet first and whether they are mutually exclusive. (e.g. a packet matching nat tables is not checked against spf rules). That is a logical implementation choice and it does not affect our discussion.

One other factor would be routing (not nat-ing) tables, for instance if ipforwarding is enabled AND the packet doesn't get dropped by the spf then you might be able to pass a spoofed srcaddr packet on the lan interface.

Sorry for my lack of skills in the diagramming department.

rgds.

Daniel
MVM
join:2000-06-26
San Francisco, CA

Daniel to jetspeed

MVM

to jetspeed
said by jetspeed:

If you want to call this NAT translation a "security" feature that is fine however, that was not what it was designed for.
Ice picks weren't designed to be murder weapons either. Do me a favor and describe the difference between a modern firewall's NAT state table and an SPI state table. You'll find they are rather similar.

So which is it? NAT provides a lot of security, or SPI doesn't supply much? Whether or not something was designed many years ago for a given purpose often has very little to do with how it's being employed today. This applies to many technologies; NAT is just one of them.
Daniel

Daniel to qrkx

MVM

to qrkx
said by qrkx:

Hence:

1.NAT does not discard packets with no matching entry.
2.The spf will if there are matching acls.
Well, this begs the question then. What keeps spoofed packets destined for valid internal addresses from being passed right through on a SOHO router, or even a high-end solution?

In other words, if traffic that doesn't match an existing entry in the NAT table is handed to the router normally, then just as any other TCP/IP stack it's going to check its routing table and see that it knows where that network is, and then pass it along to the internal interface where that host resides.

Since we know this doesn't happen, the question is "why"? I'd argue that the handoff to the stack is not done in a normal fashion when a NAT rule is not matched. My suspicion is that NAT checks to see if the external host is listening on that port, and if it is not the packet is dropped.

A "standard" handoff to the stack would mean SOHO routers are not doing what we all know they are. Unless (and this is a big one), the only precaution against this is a simple anti-spoofing rule. If that's the case then the whole game is changed. I'm definitely going to be looking into this deeper.
Daniel

Daniel to bbarrera

MVM

to bbarrera

Re: SPI protects a block of public IP addresses

said by bbarrera:

My SPI router can route and protect a block of public IP addresses. Impossible with a NAT router.
Not correct, sir. Check Point, for example, uses both NAT and SPI. Using this solution, however, I can protect both public or private addresses.

Perhaps you mean that there are no configuration options in low-end, SOHO devices that allow you do do static NAT'ing vs. hide NAT'ing, and you'd be correct. But this functionality is available on other NAT/SPI soutions other than Check Point. Astaro, Smoothwall, IPCop, any of the BSD-based solutions - they all do it.