IPSEC not blocking specific IP address per Ethereal

[Alfredo]

Win2k advanced server, updated service packs, IP sec with a few pinholes
for some daemons, port blocking working well per GRC's "Shields UP",
etc.

However, when I try to block a specific IP address by using IPSEC, the
packets get through anyway according to my ethereal sniffer which is
running on the same machine. I have added a very specific filter
against those IPs but ethereal still shows their packets getting in past
the front door.

(At least that's what I think is happening, it could be that ethereal is
capturing the packets before IPSEC gets to block them, which would be
worrisome because that would certainly be an exploitable
vulnerability.)

The hacker (a worm, really) is attacking ports 139 and 445. The packets
come in but my machine does not respond, probably because the port
blockers are working. Yes, I am blocking specific ports rather than
"everything else", I have my reasons, it's temporary, please ignore this
idiosyncracy, the filter against this IP is specific enough that IPSEC
should match it and block it.

Anyway when I try to block this specific IP from sending any packets at
all, it's as if the filter didn't do any work whatsoever. Ethereal
shows the evil packets coming in as they please.

Here is how I have configured IPSec:
IP FILTER LISTS:
httpd allow
smtpd allow
other daemons allow
VulnerablePorts block
evil ips block

EVIL IPS: (only 1 ip is "evil" right now)
Mirrored: yes
Description: ips known to be evil
Protocol: (I've tried both ANY and TCP)
Source Port: ANY
Dest Port: (I've tried ANY and 445 and 139)
Source DNS name: A specific IP addr
Source Address: aaa.bbb.ccc.ddd (the specific worm's IP)
Source Mask: 255.255.255.255
Destination DNS: Any IP address
Destination Address: (Tried both "My IP Addr" and "Any IP addr")
Destination Mask: 0.0.0.0

I then click OK all the way out so all IPSEC and MMC windows are closed,
but Ethereal shows the packets still flooding in from that IP.

Any ideas, tips, tricks, and rumors greatly appreciated. Thanks!

 

[Steven L Umbach]

Try to block it from a specific IP address that you have and then see if
that works blocking that IP address. Use telnet to verify that port is open
or not. It may take a reboot to refresh the ipsec policy. Not always, but I
have seen that to be the case before. You can also use netdiag to see the
filters that the computer is currently using as in [ netdiag /test:ipsec
/debug ]. --- Steve

 

[Duane Arnold]

So you're saying that with IPsec up and running and is active, you have set
some rules to block traffic to an remote IP with IPsec and it's not doing
it?

Then I would say if it's happening and you know it's happening with IPsec
active on the machine, then the rules must not be configured correctly. The
AnalogX Public Configuration file may help you with this in how to make the
rules correctly.

http://www.analogx.com/contents/articles/ipsec.htm

Secondly, the packets may be leaving the machine at the boot process when
the malware can get to the TCP/IP connection first before IPsec or any host
based FW solution can start up and get to TCP/IP and stop it. You could
hack the registry and mess around with service dependencies in an attempt
to set the start order on the services like the TCP/IP service cannot start
before the IPsec service starts. I wouldn't recommend that if you don't
know what you're doing as you could hose the machine.

Thirdly, IPsec or any host based FW solution is not some kind of stops all
and ends all solution. If there is a exploit on the machine, then you need
to remove it off the machine *PERIOD* and not try to use IPsec or any other
such program and/or application to block it.

The tools in the link like Active Ports and Process Explorer will help you
pin point what's doing it. You put Active Ports in the Start-up folder with
refresh rate at High and you may be able to see it if this is happening at
the boot process. You use PE to look at running processes and look inside a
running process to see what is using the process. You right-click on a
process in the Upper Pane and go to Properties and it will tell you
everything about a process. You can right-click on a DLL that is running
with or using the process in the lower pane and select Properties there
too.

http://tinyurl.com/klw1

Duane

 

[Herb Martin]

Win2k advanced server, updated service packs, IP sec with a few pinholes
for some daemons, port blocking working well per GRC's "Shields UP",
etc.

However, when I try to block a specific IP address by using IPSEC, the
packets get through anyway according to my ethereal sniffer which is
running on the same machine. I have added a very specific filter
against those IPs but ethereal still shows their packets getting in past
the front door.

Have you tried (just for test) adding a filter on that
address and those SPECIFIC ports (139 & 445) separately
and explicitly?

There is an odd thing about IPSec block and pass which
means that it isn't always obvious when you have a specific
port filter and a general address, vs. a specific address and
a general port.

Block on the EXACT address/port should always take precedence.

(At least that's what I think is happening, it could be that ethereal is
capturing the packets before IPSEC gets to block them, which would be
worrisome because that would certainly be an exploitable
vulnerability.)

The hacker (a worm, really) is attacking ports 139 and 445. The packets
come in but my machine does not respond, probably because the port
blockers are working. Yes, I am blocking specific ports rather than
"everything else", I have my reasons, it's temporary, please ignore this
idiosyncracy, the filter against this IP is specific enough that IPSEC
should match it and block it.

Anyway when I try to block this specific IP from sending any packets at
all, it's as if the filter didn't do any work whatsoever. Ethereal
shows the evil packets coming in as they please.

Here is how I have configured IPSec:
IP FILTER LISTS:
httpd allow
smtpd allow
other daemons allow
VulnerablePorts block
evil ips block

EVIL IPS: (only 1 ip is "evil" right now)
Mirrored: yes
Description: ips known to be evil
Protocol: (I've tried both ANY and TCP)

TCP and a separate UDP (if you need it) are
more specific so less chance of screwing it up
with a PASS filter.

Source Port: ANY
Dest Port: (I've tried ANY and 445 and 139)

The individual ports are more specific so more reliable.

Source DNS name: A specific IP addr
Source Address: aaa.bbb.ccc.ddd (the specific worm's IP)
Source Mask: 255.255.255.255
Destination DNS: Any IP address
Destination Address: (Tried both "My IP Addr" and "Any IP addr")

Assuming you only have one IP on machine.

Destination Mask: 0.0.0.0

I then click OK all the way out so all IPSEC and MMC windows are closed,
but Ethereal shows the packets still flooding in from that IP.

Are you updating the policy on the machine?

 

[T. Sean Weintz]

Win2k advanced server, updated service packs, IP sec with a few pinholes
for some daemons, port blocking working well per GRC's "Shields UP",
etc.

However, when I try to block a specific IP address by using IPSEC, the
packets get through anyway according to my ethereal sniffer which is
running on the same machine. I have added a very specific filter
against those IPs but ethereal still shows their packets getting in past
the front door.

(At least that's what I think is happening, it could be that ethereal is
capturing the packets before IPSEC gets to block them, which would be
worrisome because that would certainly be an exploitable
vulnerability.)

Yup. That is what's happening. Winpcap, which allows the captures for
ethereal, is snagging the packets before they get passed to the IP
stack. Think about it - winpcap is non layer 3 specific - it will
capture IPX, etc. -- not just IP. It HAS to work before things get
passed to the IP stack. The IPSEC settings in windoze are of course IP
specific, therefore are higher level than winpcap.

 

[Alfredo]

Yup. That is what's happening.

Wait, that can't be it, because there's also the case of the flooding
spammer trying to relay through me.

I placed his IP on the same "block" list, and yet my SMTP inlog still
shows his flood of email attempts *after* I put him on the IPSEC block
list exactly like I did with the worm above. His packets are still
getting through. This is an IPSEC issue.

Can anyone see what I have done wrong in my IPSEC policy? I am getting
overwhelmed with worms and spammers doing what amounts to a DOS attack
on my server and I would like to stop them.

 

[Stephen Cartwright [MSFT]]

Hard to tell from the ipsec policy details on your first post exactly what
you have in place or indeed if your box might already be compromised.
However the more specific the ipsec policy, e.g. specific ip address,
protocol, port then the higher the weight it has for being applied before
others of less specificness. Double check your policies. This is a local
ipsec policy you have in place?
Have you tried restarting policy agent service after the last filter block
addition just in case that improves things.
Actually maybe that might not be the best idea as there would [might?] be a
period of vulnerability whilst the service restarts. Perhaps then a reboot,
drastic measure that it is.
Good luck

 

[Steven L Umbach]

I did try Ethereal after configuring an ipsec policy on a test computer.
Ethereal DID show the connection attempts as a syn packet. My computer did
not respond because of the ipsec policy. If your ipsec policy is configured
correctly Ethereal would show that your computer is not responding to
connection attempts from blocked traffic.

Having said that, ipsec is not meant to be an internet facing firewall. At
best it is a non stateful packet filtering mechanism that also has default
exemptions. Since ipsec is not stateful, attackers can gain information
about your computer by using a scanner that use a source port that your
ipsec policy allows. Blocking access by IP addresses is effective only as
long as that attacker is using that IP address that is blocked. If at all
possible use some sort of firewall device in addition to ipsec. There are
low priced NAT/PAT router firewalls that would help you quite a bit by doing
a better job of filtering traffic and keeping unwanted traffic off of your
computers network interface.. --- Steve

 

[Duane Arnold]

Wait, that can't be it, because there's also the case of the flooding
spammer trying to relay through me.

I placed his IP on the same "block" list, and yet my SMTP inlog still
shows his flood of email attempts *after* I put him on the IPSEC block
list exactly like I did with the worm above. His packets are still
getting through. This is an IPSEC issue.

Can anyone see what I have done wrong in my IPSEC policy? I am getting
overwhelmed with worms and spammers doing what amounts to a DOS attack
on my server and I would like to stop them.

You put a router a border device in front of the machine a let it block the
attacks so that the machine doesn't have to use resources in blocking the
attacks slowing the machine down in doing more productive things. You can
get a router that can set rules to block a specified IP and block it at the
border. Even If you were able to set some IPsec rule and block things, it is
still going to require that the machine use unnecessary resources to
continue to block them slowing the machine down while it's doing it.

The machine seems to be compromised and you need to focus on removing the
exploit or exploits ;-) off the machine and not try to block them with
IPsec. IPsec is just one part of the security solution and is not a stop and
ends all solution. You have to help IPsec out by doing the right things in
your security setup for the machine.

You might also want to find out how to secure or *harden* the NT based O/S
to attack. The information is out on Google or dogpile.com on the how to(s).

Duane

 

[Steve Clark [MSFT]]

Best practice is to use the Windows Firewall *with* IPsec to achieve
stateful filtering.

WF will control inbound behavior and IPsec filters will control outbound...

 

[Steve Clark [MSFT]]

Maybe the information is on www.microsoft.com already?

Search for "Security Guide" and the OS you want (such as 2000, 2003, XP).

 

[Steven L Umbach]

If you are using an operating system that has Windows Firewall. --
Steve

 

[James Morey]

There is also a bunch of new documentation for IPsec (under the auspices of
Domain Isolation) for Windows Server 2003 SP1. These are available on the
download center (will be on TechCenter soon). Unfortunately, these documents
are very difficult to find - sigh. So, I'll put the direct links to them
with a short abstract below:

"Introduction to Server and Domain Isolation with Microsoft Windows"
This is the place to start if you are new to IPsec or domain isolation.
Also, at the end of the paper is a roadmap to all the other domain isolation
docs (quoted in part below).
http://www.microsoft.com/downloads/...28-1D76-4A73-8225-CE3A059B5638&displaylang=en

"Domain Isolation with Microsoft Windows Explained"
This paper provides a detailed overview of domain isolation. It explains how
domain isolation protects domain member computers and the benefits of
deploying domain isolation. It also provides a brief overview of how to
deploy domain isolation. This paper is intended for IT professionals in
organizations that are investigating using the Microsoft implementation of
Internet Protocol security (IPsec) in Windows to deploy domain isolation. It
assumes that you are somewhat familiar with the Microsoft implementation of
IPsec and would like more detailed information about using that technology
to deploy domain isolation.
http://www.microsoft.com/downloads/...39-10B8-4476-9527-4B67F90CFFF5&displaylang=en

"Server Isolation with Microsoft Windows Explained"
This paper provides a detailed overview of server isolation. It explains how
server isolation protects isolated servers and the benefits of deploying
server isolation. It also provides a brief overview of how to deploy server
isolation. This paper is intended for IT professionals in organizations that
are investigating using the Microsoft implementation of IPsec in Windows to
deploy server isolation. It assumes that you are somewhat familiar with the
Microsoft implementation of IPsec and would like more detailed information
about using that technology to deploy server isolation.
http://www.microsoft.com/downloads/...29-B52C-41A4-9EE5-D95916FFE53E&displaylang=en

"Domain Isolation Planning Guide for IT Managers"
Designed for enterprise IT managers who are investigating using IPsec in
Microsoft Windows to deploy domain isolation, this paper will help you and
your IT staff to gather the information required to develop a domain
isolation deployment plan and to design your IPsec policies. It includes an
overview of the deployment process, a step-by-step guide to the planning
process, and links to resources that you can use to plan and design your
deployment. It does not explain how to deploy domain isolation.
http://www.microsoft.com/downloads/...45-F977-4BB4-9D17-A6B9B3E3F56F&displaylang=en

"A Guide to Domain Isolation for Security Architects"
Designed for network architects of enterprise organizations that are
investigating using IPsec in Microsoft Windows to deploy domain isolation,
this paper describes the implications of deploying domain isolation in an
enterprise environment and explains how to assess the enterprise environment
and plan domain isolation. Read this guide after you have developed a
working knowledge of domain isolation.
http://www.microsoft.com/downloads/...AA-F5B3-401F-BD91-DF06F1E23077&displaylang=en

"Setting Up IPsec Server and Domain Isolation in a Test Lab"
This paper demonstrates how to set up IPsec domain and server isolation in a
limited test environment. It provides procedures for setting up a basic
deployment, which you can use as the basis for your own deployment. This
paper is designed for network architects who are investigating using IPsec
in Microsoft Windows to deploy server and domain isolation.
http://www.microsoft.com/downloads/...8F-7D7A-4955-A3F6-318FEE28D825&displaylang=en

"Interoperability Considerations for IPsec Server and Domain Isolation"
This paper describes interoperability between IPsec-secured hosts running
Windows Server 2003, Windows XP with Service Pack 2 (SP2), and Windows 2000
Server with Service Pack 4 (SP4) in a domain or server isolation scenario
and hosts that cannot use IPsec, including computers running earlier
versions of Windows or non-Microsoft operating systems. It is intended for
IT professionals in organizations that are investigating using IPsec in
Microsoft Windows to deploy server and domain isolation.
http://www.microsoft.com/downloads/...69-EF11-499A-9E1F-85DA3FCA608C&displaylang=en

In addition to these, Microsoft IT has a rather detailed and comprehensive
paper on how they deployed domain isolation - "Improving Security with
Domain Isolation"
http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx


--
=====================
NOTE - This posting is provided "AS IS" with no warranties, and confers no
rights.
James Morey | Microsoft | Windows Server UA | Networking
=====================

 

[Duane Arnold]

Maybe the information is on www.microsoft.com already?

Search for "Security Guide" and the OS you want (such as 2000, 2003, XP).

That's money in the bank and a good start -- maybe *someone* will use it.
;-)

Duane