Applying SECURITY to LAN to LAN VPN traffic!

[jeremy.buck]

I have a question to the forum,

Can you apply security to incoming ipsec traffic once it has been decrypted? I've done some research and can only come to this conclusion, with a LAN to LAN Vpn using the sysopt permit ipsec command you bypass all ACL checking (The inbound access-list or conduits applied to the outside interface) and can therefore apply no security to traffic coming into your internal network over the VPN no matter which interface the VPN terminates at. It is my understanding that instead of using the sysopt permit ipsec command you can allow protocol 50 (esp) into your firewall allowing the encrypted traffic to reach the firewall and be decrypted BUT can you then apply any security to it? Will it reevaluate itself against the inbound ACL applied to the outside interface?

-Jeremy

[mhoda · Accepted solution]

Hi Jeremy,

Your understanding is to the point accurate. Once the packet is decrypted, it will not reevaluate itself against the inbound acl applied on outside regardingless of whetther you configure acl or use sysopt. Thanks,

Mynul

[jeremy.buck]

Thankyou,

Do you know if CISCO plans to change this?, as many times IPSec tunnels are just one tier in the great world of security and it is viable that people will want to protect internal networks from other VPN's. I.E. what if they only need to access a SQL server and nothing more.

-Jeremy

[mhoda]

Jeremy,

To the best of my knowledge its not on the road map. But, you can talk to your account team to request for this feature. Thanks,

Mynul

[anatolya]

For example you have:

LAN1 ---- int1[Cisco]int2 ------>VPNlink<-------- int3[Cisco]int4 -------- LAN2

You can check security of decrypted traffic on the following interfaces:

int1 inbound (Traffic from LAN1 to LAN2)

int1 outbound (Traffic from LAN2 to LAN1)

What do you need else?

[jeremy.buck]

On the PIX firewall you cannot bind access-lists to interfaces in an outbound fashion.

-Jeremy

[anatolya]

But you can use inbound access list.

Any traffic based on TCP can be blocked because attacker will never establish connection.

Any UDP traffic from LAN1 can be blocked too.

Any ICMP reply traffic too.

[jeremy.buck]

Roger that,

After you have established an IPSEC tunnel your packets are encrypted and handled by separate services on the PIX. They are now considered IPSEC traffic which your rulesets must allow in order to accomplish a VPN. In other words if you deny this traffic you deny the VPN connection. ACL bounds checking is only accomplished once in the initial review of the packet, this happens when the packet is still encrypted (Protocol 50) so that after it is decrypted there is no way to evaulate whether or not you want to accept the packet (This is the packet that was intentionally sent through the VPN). The routing services handle the packet after it is decrypted so its free reign on your Internal burb.

-Jeremy

[ontrack]

If you set sysopt connection permit-ipsec to disabled, then all your VPN traffic is processed by the outside interface access list of the PIX that is receiving the VPN traffic. The VPN setup is handled before the incoming outside access list so you do not need any permit's for protocol 50. All you would need is the permits for the tunneled traffic.

[jeremy.buck]

This is true,

Although the call setup for the IPSEC negotiation is not protocol 50. Protocol 50 is ESP (Ecapsulated security payload/Encrypted security payload). IKE (internet key exchange) or ISAKMP (Internet Security Association and Key Management Protocol) which utilizes UDP port 500 is what you speak of. IKE is what establishes the agreed upon attributes for IPSEC to take place there are no bounds checking on IKE, it must be allowed by default-- You still however need to allow protocol 50 (ESP) into your external interface. Sysopt permit-ipsec also accomplishes this 'permit'.

-Jeremy

[anatolya]

Jeremy,

Yes, that's correct, you cannot evaluate whether you want or not to accept the packet when it is still encrypted. But if you really want to filter the traffic, you can do this on other interfances of the PIX, there is no need to use for these purposes the ACL on the interface which receives the encrypted traffic.

[jeremy.buck]

How?

Since you cannot apply access groups in an outbound fashion I see no possible way to supervise this traffic. How might you do this with other interfaces? The decryption happens internal to the PIX after it clears the Inbound ACL as an encrypted packet, It is then handed to the routing process for normal routing.

-Jeremy

[HEATH FREEL]

I have tested and used this feature many times.

If you use

no sysopt connection permit-ipsec

then you can use ACL Inbound on the outside interface to control IP's Ports and Protocols. This would tell me that the IPSec traffic now gets terminated on the outside interface - so you do not need UDP 500 or Prot 50 allowed inbound. You now need to specify the local and remote proxy IP's with protocols and ports that you would like to allow through the FW.

The only issue I have found with this is that it is ten possible to use the remote proxy IP's to gain inbound access without VPN capabilities. This is how I tested that theory.

my inbound ACL permited 10.1.1.1 on TCP 23 to 10.1.2.1

with no sysopt connection permit-ipsec configured when I used the VPN 10.1.2.1 port 23 was the only service I could get to.

Then I connected to my Internet router - created a loopback IP of 10.1.1.1 - and then telneted to 10.1.2.1 from the source of 10.1.1.1 - and presto - I was in.

Apparently IOS FW's get around this by comparing the ACL to the Crypto proxies.

[anatolya]

Jeremy,

For example we have:

PC1 ------ int1[PIX]int2 ----VPN----[PIX] ------PC2

and you need to block TELNET from PC2 to PC1

Just add:

ACL 101 deny host PC1 eq 23 host PC2 gt 1023 (block response)

ACL 101 .....

and apply ACL 101 to int1 to filter inbound traffic.

Regards,

[jeremy.buck]

This will work!, but it is a work around solution.

I have pondered doing such a thing but this will break ASA within the firewall and will become an administrative headache., especially when I'm working with large production networks.

Ultimately if you miss any potientially harmful protocol/service it will be allowed by your permit ip any statement at the end of this ACL which is _required_ to allow your inside clients access outbound, so it's not like you can permit only the necessary services and then deny the rest. Do you really want traffic to reach your internal clients? Plus, it is trivial to change the source port of initiator, this makes it extremely difficult to manage --all an attacker would have to do is find a source port that was allowed by the permit any statement.

A couple of the other threads in this post are claiming that you can still use your inbound ACL on the outside interface to check the traffic if you specify Global addresses or external addresses in your crypto map access-lists but I still haven't got any replies concerning this, although it will surprise me if this is true as I've always thought the first thing that is checked was the inbound acl.

-Jeremy