IPSEC not blocking specific IP address per Ethereal

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!

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



"Alfredo" <alfredo@KILL_SPAM_megapath.net> wrote in message
news:(E-Mail Removed)...
> 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!
>

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

"Alfredo" <alfredo@KILL_SPAM_megapath.net> wrote in message
news:(E-Mail Removed)...
> 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?


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

Alfredo wrote:
> 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.

"T. Sean Weintz" <(E-Mail Removed)> sez :

>Alfredo wrote:
>> it could be that ethereal is
>> capturing the packets before IPSEC gets to block them
>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.

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
--
Stephen Cartwright [MSFT]

"This posting is provided "AS IS" with no warranties, and confers no
rights."

"Alfredo" <alfredo@KILL_SPAM_megapath.net> wrote in message
news:(E-Mail Removed)...
> "T. Sean Weintz" <(E-Mail Removed)> sez :
>
>>Alfredo wrote:
>>> it could be that ethereal is
>>> capturing the packets before IPSEC gets to block them
>>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.
>

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


"Alfredo" <alfredo@KILL_SPAM_megapath.net> wrote in message
news:(E-Mail Removed)...
> "T. Sean Weintz" <(E-Mail Removed)> sez :
>
>>Alfredo wrote:
>>> it could be that ethereal is
>>> capturing the packets before IPSEC gets to block them
>>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.
>

"Alfredo" <alfredo@KILL_SPAM_megapath.net> wrote in message
news:(E-Mail Removed)...
> "T. Sean Weintz" <(E-Mail Removed)> sez :
>
>>Alfredo wrote:
>>> it could be that ethereal is
>>> capturing the packets before IPSEC gets to block them
>>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.
>

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

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...



"Steven L Umbach" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>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
>
>
> "Alfredo" <alfredo@KILL_SPAM_megapath.net> wrote in message
> news:(E-Mail Removed)...
>> "T. Sean Weintz" <(E-Mail Removed)> sez :
>>
>>>Alfredo wrote:
>>>> it could be that ethereal is
>>>> capturing the packets before IPSEC gets to block them
>>>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.
>>
>
>