[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipsec vs. firewalls

(Sorry for the repost if any, my first try was not relay to the list)

I'm not an IPSEC expert, having no experience with it, but it seems to me
that even in tunnel mode, a clear text IP header is available to route the
secure datagram from the origin to the destination?

Couldn't we use a statefull-like packet filtering on the firewall? 
It will, for each outgoing IPSEC connection, update/create an entry in a
dynamic table, recording the source and dest IP addresses (no port) and
create a dynamic ACL to allow *all* packets back from this dest IP
addresses to the source address, this for a certain TTL (TTL reset on each
outgoing packets)? 
=> just like the firewall-1 packet filtering engine does for udp, except
that the port is not even in the table.

It won't provide the same level of security than the established scheme,
but at least a scan/attack could come *only* from a host your are already
talking with.

Also, you already are in trouble if your security policy allows outgoing
connection for protocols which can be used to tunnel others
protocols/application inside (And there is a *lot* of them). 
Using such encapsulation, your internal user can easily overwrite your
firewall policy and establish full IP connectivity between internal and
external host. The only way to prevent such tunneling is to look at the
application protocol and verify that what's going on the wire is really
what you expect, but it becomes really hard to detect when encryption is use. 
The simple example of establishing a ppp connection over an 'outgoing' ssh
link illustrate quite well this problem: the tunnel was establish from an
internal host but the result is that your security policy dealing with
incoming packet is overwritten: no control any more. One guy inside could
fully open your network.

	\jean

At 08:12 PM 5/6/98 -0700, someone using Steve Bellovin's login wrote:
>I came up with a disturbing conflict between ubiquitous IPSEC and
>common firewall policies.  I'm not certain how to resolve it,
>either.
>
>A common firewall policy permits most outgoing calls.  (The
>requirement to authenticate such calls, say via AH from the inside
>host to the firewall, wouldn't affect what comes next.)  Suppose,
>though, that the inside host wants to use ESP for end-to-end
>encryption to the destination.  How will the firewall inspect the
>return packet?
>
>To implement that firewall policy, the return packet *must* be a
>reply to the outbound packet -- say, the SYN+ACK in response to
>the SYN.  But if it's encrypted, there's no way to tell; it could
>be a probe from the outside host to some vulnerable ports on the
>inside client machine.
>
>There are a number of possible solutions; each has its limitations.
>
>The most obvious, of course, is to prohibit end-to-end encryption,
>and require that all packets be decrypted at the firewall.  Apart
>from the obvious security risks, this complicates the topology
>discovery process.
>
>Another pretty good solution is per-connection keying.  But that
>only works if the firewall *knows* that the inside machines will
>indeed enforce that, and drop packets to different ports than are
>bound to the SPI.
>
>A third solution is to use some sort of auxiliary header with
>cleartext port numbers, similar to that suggested by Greg Minshall.
>Again, the firewall would have to *know* that hosts would drop
>packets where the outer and inner port numbers didn't match.
>Furthermore, in both this case and the previous one, all the firewall
>knows is the packet direction; SYN, ACK, and FIN bits are still
>invisible.  (Well, we could expose more of the TCP header.)  This
>reduces the ability of a dynamic firewall to handle TCP to its
>ability to handle UDP.
>
>Fourth, we could restrict end-to-end encryption to trusted outside
>hosts, and in particular to machines that comprise the VPN.
>Obviously, this works against general use of encryption.
>
>Finally, I suspect that some people will regard anything that
>cripples firewalls as a feature.  With all due respect, I tend
>to differ...
>
>I'm not suggesting any changes to anything at this point.  I do
>suggest that IPSEC vendors -- including IPSEC implementations that
>will live on firewalls -- work towards per-connection keying.
> 

   - jean -
Follow-Ups: