IPSec Policy Doesn't Really Block

  • Thread starter Thread starter Joseph Melika
  • Start date Start date
J

Joseph Melika

I am having an issue with IPSec. I simply have a server sitting at a co-lo.
It is serving on prts 80, 443, 5274, and 6667. I need to open those ports
to the public but blocking everything else. I also need to permit the
server to be able to talk to its neighboring computers, as well as some
computers at a different subnet with no restrictions.

Here is a list of IPSECPOL.exe commands I am using to create the policy.
Please be aware of the possible word wrap.

=========
ipsecpol -w REG -p "Policy" -r "Local Site" -f
x.x.x.0/255.255.255.0+x.x.x.x:* -f x.x.x.x+x.x.x.0/255.255.255.0:* -n PASS
ipsecpol -w REG -p "Policy" -r "Remote Sites" -f
192.215.60.0/255.255.255.0+x.x.x.x:* -f
206.16.86.0/255.255.255.240+x.x.x.x:* -f
206.16.76.32/255.255.255.240+x.x.x.x:* -f 192.215.11.11+x.x.x.x:* -f
192.215.5.16+x.x.x.x:* -n PASS
ipsecpol -w REG -p "Policy" -r "Applications Ports" -f *+x.x.x.x:5274 -f
*+x.x.x.x:6667:TCP -f *+x.x.x.x:80:TCP -f *+x.x.x.x:443:TCP -n PASS
ipsecpol -w REG -p "Policy" -r "Block Everything Else" -f *=x.x.x.x:*:* -n
BLOCK
==========

x.x.x.x stands for the server's IP address, while x.x.x.0 stands for the 24
bit subnet it's on.

Now the issue is that when I create this policy and assign it, I am still
able to connect to the server from home using Terminal Services. My home PC
is not on any of the subnets listed above. How come the IPSec Policy
doesn't work? I can do a netdiag /test:ipsec and I do see the policy
applied. It just doesn't seem to be doing its job.

One thing is that I did notice that the PASS and BLOCK did not actually use
the existing filter action "Permit" and "Block". Each of those commands
created its own filter action with the same name as the filter itself, i.e.
Local Site. I even tried going to the UI and change the action to Block or
Permit and restarted IPSec Policy agent, but still didn't work.

Has anyone been able to get IPSec to work properly? Can someone give me any
advice on this?

I appreciate it guys!

Joseph Melika
 
I have created ipsec policies that work. I usually start with a mirrored block all IP
rule. The I add mirrored permit rules for the exceptions such as the lan subnet,
individual IP addresses, and then the specific ports/protocols/addresses. Make sure
you have the source and destinations correct as that can be confusing. For instance
to permit port 80 tcp into my computer I would create a mirrored rule for source
address:any IP address, destination address:my IP address, protocol TCP, source
port:any, destination port:80. --- Steve

http://www.securityfocus.com/infocus/1559 -- this may help.
 
Steven,

Thanks for getting back to me on this. I did as you said and basically
blocked all IP's mirrored from Any IP to My IP. I then created a couple of
basic filters to allow port 80 and port 25 inbound from Any to My IP, also
mirrored. That worked like a charm. But then I realized I could not go
outbound, like surfing the web. So I enabled from My IP to Any IP mirrored
policy, any protocol, and permit. That ends up disabling the inbound block
filter. Once the enable outbound filter is set, I can Terminal Service into
the server and hit all ports on it from any public IP.

Any ideas why that happens?

Thanks,
Joseph Melika
 
Ipsec rules can be tricky since they are not like normal firewall rules that
take priority based on their order in the list. Ipsec filters use a method
where specific filters override general filters where there is a conflict.
Instead of a permit all oubound add the exceptions to your permit filter
list which also would be more secure. For instance add entries for ports 80
and 443 TCP and 53 UDP for dns. Of course you may also want to add entries
for ftp/mail/news if needed but try the entries for internet browsing first
to see if that works. Also be sure to read the link below on using ipsec
filtering as an internet firewall and how to disable the default exemptions
with a registry entry which varies depending on the operating system. --
Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;811832
 
Thanks Steven. I was able to get it to work now with specifying the common
outbound ports (80, 21, 20, 25, etc).

I am having a different issue with one of those servers now and I am
wondering if you could help me. I am applying the IPSec Policy using GPO.
I have created the GPO with the policy assigned and linked it to an OU. I
then start moving the servers one at a time to that OU and test it to make
sure all is working. Here are the steps I take:
Move server to OU
Replicate changes between DC's
Go to the server and do secedit /refreshpolicy machine_policy /enforce
Restart IPSec Agent service
Run netdiag /test:ipsec /debug

I usually see the new policy with that last command after the Event Log
gives me an Information msg for SceCli telling me GPO was replicated. On
one particular server, it does not seem to get the new policy. I've already
done the same for 5 other serevrs and they all worked. Any idea? There is
absolutely nothing in Event Log about it.

Do you know what could be causing this? I know I did move the right server
to the right OU ;). Also, do you know if there is any "easier" way of
replicating the new IPSec policy rather than this time consuming way I'm
using?

Thanks a lot!
Joseph
 
Group Policy would be one way to apply ipsec policies. You can also import ipsec
policies into a computer as shown in the link below. Though it discusses Windows 2003
it works the same for Windows 2000. Ipsecpol.exe can be used to batch script ipsec
policies also, though I have not tried it myself as I use Group Policy usually.

http://www.microsoft.com/resources/...2003/standard/proddocs/en-us/IPSec_import.asp

If you are using Group Policy applied to an OU and it works for all computers in the
OU except one I would suspect a configuration/networking problem for that one
computer. Run gpresult on that server to see if it shows as being in the right OU and
if it shows that the GPO computer policy for that OU has been applied to it. If not
by now I would double check the dns configuration on that server making sure it
points to only domain controllers running AD dns for the domain and run netdiag on it
looking for any failed test such as dns, dc discovery, kerberos, and secure channel
to see if there is a related problem. --- Steve
 
Back
Top