Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 5 down vote favorite

When using Windows IPSec for IP filtering whenever a filter is added you need to have a "mirror" rule (by checking the "Mirrored. Match packets..." tickbox).

Because IPSec Filtering is not stateful, if you don't have this option enabled then you can't communicate in both directions. From this article, I quote:

If you don't mirror your rules, then you can't communicate in both directions. IPsec is not "stateful" in the way that Firewall is - if you have a rule from A to B without the B to A component, then IPsec on A will drop all traffic from B, even if it is the response to request sent by A. That's part of what makes IPsec so difficult to effectively use as a firewall.

If I have a rule that says:

Allow inbound connections to my IP address to port 5666 from any port on remote host 172.16.3.200

Which would be implemented as:

netsh ipsec static add filter filterlist="NAGIOS NSClient" 
      srcaddr=172.16.3.200 srcport=0 
      dstaddr=ME dstport=5666 
      mirrored=yes 
      description="Inbound" 
      protocol=TCP

Would the "mirror" rule be:

Allow outbound connections from my IP address from port 5666 to any port on the remote host 172.16.3.200

What are the security risks of such a configuration with regards to unwanted traffic?

share|improve this question
If this is a true stateless rule, does the dstport and srcport function really work or is it possible to craft a request from 172.16.3.200 on srcport 5666 and attempt to access any port on the machine with the above rule? And alternatively does this allow the destination nagios server to use the 5666 srcport and connect to any port on the endpoint device? It seems that may actually be possible even if the rule enforces srcport and dstport – Ori Jun 9 '11 at 6:17
@ori - thanks for the comment. From my reading since asking the question, I'm under the impression this is also also how IPTables work when not connection tracking. Might have to earn some rep for a bounty :) – Kev Jun 9 '11 at 8:02

2 Answers

up vote 1 down vote

Depending on the service the outgoing port is usually different from the incoming port, and is often randomly assigned. So the mirror would be from any port on localhost to 5666 on the remote host. The risk depends on the IPSec mode: transport or tunneling. I would say the most likely threat would be on availability. In transport mone the destination IP and port are in the clear, So an adversary could attempt to flood the destination port.

share|improve this answer
up vote 1 down vote

I am not familiar with Windows, but in general these IPsec SA rules are completely separate from your firewall. They are meant to associate some IPsec-specific information like the session key with the (stateless) packet stream, so that the gateway knows that it is supposed to decrypt a particular ESP packet, and how. If you want to block "unwanted" traffic, use the firewall on top of that.

The main "risk" is regarding the use of higher layer protocol information such as TCP ports. Packets may be fragmented, so that IPsec is unable to identify which SA a packet belongs to. This is discussed in RFC4301. Since en-route fragmentation is generally discouraged and removed from IPv6, I suppose the best solution is to simply drop all fragments, or not use TCP/UDP port info.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.