TCP Reset Attack?

I’ve recently installed Windows 8 in my computer. I’ve configured a very restrictive profile so that it allows me accessing only IP addresses in the Steam network, so I can freely play online with no interruptions.

What I observed using Wireshark is that lots of TCP RST ACK packets are reaching my computer and they come from IP addresses NOT in the Steam network. I can block them only when I set a Global Rule blocking all IP OUT packets. It seems there may be a bug in Comodo.

Also, I have a question. Where does Comodo store its running configuration? Maybe in the Windows registry?. It seems remote attackers are able to change it and Comodo becomes not responsible with alert windows being quickly dismished, so I can’t react on time. Changing to other profiles also doesn’t work. The only solution I’ve found is to reinstall Comodo. A test I’ve done is exporting running config in that cases and I’ve noticed changes when I compare them with exported configurations prior to the attack.

Alert windows disappearing is a known issue if I’m not mistaken, I have had it myself. From what I’ve heard they’ve found the bug so now I’m waiting for next program update.

Make an outgoing only rule for steam (or more specific, but the direction just OUT).
Block ip IN any in global rules.
Play.

If your computer receives packets, and this behavior is blocked by blocking outgoing, something on your computer is requesting these packets.
To get rid of unrequested packets from the net without question, use
Block IP in any
in gloabal rules.

In your case make sure what is requesting these packets.

Some of the changes I’ve observed when I save config when Comodo is not very responsible:

  • In the section of the .cfgx file, ‘Alerts=“55”’ is substituted with ‘Alerts=“22”’.
  • In ‘DontShowVirtualKioskWarn=“0”’ is substituted with ‘DontShowVirtualKioskWarn=“1”’.

Can you share the capture? if so send me a PM please.
It’s pretty hard to determine what’s going on only based on ‘TCP RST’ packets seen.

I’ve attached an screenshot of a wireshark capture.

Several of the source IPs are of well known networks (213.199.134.233: Microsoft). So I suppose the attackers are using forged IPs. As you can see, they are scanning ports in the 493xx range. I suspect they’re trying to reach some process that use svchost.exe to transmit their data. Yesterday I received an error message trying to erase a file on my Desktop (“You can’t erase the file because it’s being used by Windows Audio Endpoint Builder”). I believe I may have a trojan that injects code into executable .dll or .exe, changing their memory image. Windows Audio Endpoint Builder uses svchost to Access Internet.

[attachment deleted by admin]

I would very much doubt this is an indication of being attacked. The source addresses are, as you mentioned, Microsoft and Akamai, which MS use for content delivery. Unfortunately, without the rest of the capture it’s impossible to say why these are occurring.

With regard to Windows Audio Endpoint Builder, it’s a standard Windows service and is part of the audio subsystem.

I think you’re right. I’m mistaken and this isn’t an TCP ACK Attack. I’ve seen in Comodo’s log entries of blocked output packets to these networks (Microsoft and Akamai). What I suppose is that packets are really going out and not being captured by Wireshark and then an RST ACK packet is received in response. I forgot to tell you that I have a rare network card. It’s an integrated Bigfoot Networks E2100 “killer” NIC, which has a dedicated physical processor. Also, a Bigfoot Network Manager is installed in my system and is used to prioritize network traffic. I don’t know who is first accesing the TCP pile, Comodo or Bigfoot Network manager, but I think the result may be a malformed outgoing TCP packet that receives an RST ACK in response. The outgoing packet is not being logged at Wireshark maybe because it has problems capturing data when Bigfoot Network Manager is active.