Invalid TCP flag rule before network rules in processing order

Help for v2
1

Hi
My understanding of the order of processing rules is:

  • Incoming Connections
    1- Network monitor applies filtering if success it passes to application monitor
    2- Application monitor checks the target application, if allowed passes to
    3- Advanced security analysis monitor(component monitor + application behavior analysis)
  • Outgoing connections
    1- Application monitor
    2- Advanced security monitor
    3- Network monitor

However, that does not make sense in light of something I am experiencing:
I use bittorrent and 3 of the external ips have triggered the “ACK FIN RST is an invalid TCP flag combination” on Incoming connection and blocked that connection according to alerts.
I subsequently made 3 network rules to block all incoming/outgoing TCP/UDP packets for any source or dest ports and for source ip used respectively the identified external IP. Restarted Comodo.
Rules are in place by it is still being blocked by the invalid TCP flag rule rather than the network rule that I created.
As such there seems to be some ‘rules’ applied on incoming connections prior to the processing of network rules then application rules then advanced rules.
Further background: I have two nics, one has 3 VLANs on it the other is the local network which has several IP addresses on it multihomed, none related to the VLANs obviously.
Could someone please expand on what exactly these would be? Or is there something buggy?
Also is there a way to do one or all of the following in this or new beta etc:

  1. Select and copy information from the activity - log - details area
  2. Select a log alert and create a rule based on that log automatically to block the IP Address?
  3. Somehow create a rule that will automatically put the external ip address into some block list if it shows up with defined hacking activity eg: Invalid TCP flag rules? And subsequently be able to view a list of banned ip’s which includes info such as whois info, then select to unban, ban network range etc.

Thanks for your help

2

Hey motiv8d,

I’d say it’s time to defer to the experts. I’d log onto http://support.comodo.com and lodge a support ticket. They’re pretty quick there and you generally get a response within a few hours.

When/if they come up with an answer, can you please post the results back here for the benefit of others.

Thanks in advance,
Ewen :slight_smile:

3

Thanks Ewen
I will certainly post back.

Cheers

Motiv8d

4

Liasing with support. Keeping this topic updated. Feel free to chime in if you think you can assist. Thanks.

Comodo Support Advised:
Please go to “Security->Advanced->Advance Attack Detection and
Prevention” section, click on “configure…” button, a dialog box will
popup from there select “Miscellaneous” tab and de-select “Do protocol
analysis” check box and try again.
See if you still get “Invalid TCP flag combination” entries.
And do let us know if we can assist you any further.

Motiv8d advised:

  1. I am not recording any “Invalid TCP flag combination” messages at the moment. However, I have restarted uTorrent to see if they start recurring. Once they do, I will disable “Do protocol Analysis” and inform of the results. Also I have noticed that all options in “Enable Behaviour Analysis” are greyed out. Any idea why this would be as I know that it was not greyed last Friday when first noticed the Invalid flag messages. I really would appreciate clarification of the processing order of rules/checking/analysis though if you have it at hand?

  2. Hi Jonathon
    Upon running uTorrent for a while the invalid flags have started to reappear.
    I added the current source ips to block and log for all ports and disabled the ‘packet analysis’.
    I did not restart Comodo after adding this rule as I don’t believe it is necessary.
    After doing this I captured info with Ethereal.

The alerts of invalid flags stopped so packet analysis must be the rule that checks these.
However, the packets from blocked source Ips were not blocked and logged.
See the attached rule 6 reg file and the ethereal filtered capture. IP: 199.2.114.195 should be totally blocked from my understanding of rule 6 I have created, but it isn’t (unless ethereal can capture before comodo has a chance to look at the packet, in which case it wasn’t logged by comodo anyway?)
The full capture over that time period is available if you require, but it is 16MB.

So the issue seems to be:

  1. Why the rule to block a specific IP address totally does not seem to work?
  2. Why there is these FIN ACK RESET flags? Are they hacking attempts or something with the bittorrent protocol?
  3. Ideally being able to have a text file or section in comodo of banned Ips and being able to right click an alert and add that source IP to the banned list would be good.
  4. A checkbox to automatically put Ips that submit obvious hacking attempts into would be great, so long as this list was accessible like the component monitor eg: allow/block

I hope this gives you enough information to work out the problem.

Thanks for such a great product and great support.

[attachment deleted by admin]

5

Hi
I have done some further analysis and can advise the following:

  1. Ethereal seems to capture before packets get stopped by comodo
  2. The invalid tcp flags 0x0015 RST FIN ACK all occur as follows:
    A) My pc running utorrent sends out a packet with tcp flag SYN to what I assume is the external pc bittorrent port
    B) The external system replies with a packet that is invalid, tcp flag 0x0015
    C) Communication ends there until sometime later it goes back to A)

It appears that my system always initiates the connection when a system replies with the faulty flag set.
Thus my assumption is that it seems like some broken bittorrent client as it is happening on a large number of ip’s:
Eg: within an hour
220.238.163.66
210.6.68.39
210.11.35.46
203.122.71.107
210.86.79.36
199.2.114.195
86.132.147.26
210.0.115.57
81.156.24.193
85.103.109.5
60.50.165.86
207.55.115.142
58.7.167.119
218.211.165.140
203.177.240.43
210.86.113.204
125.24.154.159
89.241.181.147
124.82.22.175
81.214.91.107

Thanks

6

The following is an excerpt from the CFW log. Please notice that ALL of these alerts are happening in 1 second, and this repeats in my log the same kind, and similar number of alerts every 5 or 6 seconds. Numerous IP addresses, seems strange to me.
I don’t know what to make of it. I just recently installed Comodo and this is the kind of log it generates. I hate to sound like a noob, but is this normal activity? I am actually a little familiar with networking (Net+ certified…). My machine is 192.168.0.2
My first thought is DoS or Smurf attack. but that seems silly right? One very important detail to mention, ever since installing Comodo I have had periods of terrible lag, very low speeds on the 'net and in same cases I couldn’t even make a single page load. However without adjusting any settings, as time passes, my speed comes and goes. This did not happen before installing Comodo, and i really think it has something to do with this logged activity. (though so far i really do like Comodo)
Also worth noting: while this network lag and slow speeds only came after i installed Comodo, exiting Comodo program seemed to have no effect on when my connection speed came and went.

also, im so sorry if similar topics like this already exist, i did spend at least 2 hours searching this forum before posting about my problem.

One of these every 6 seconds:

Date/Time :2007-04-29 03:01:07
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 192.168.0.1, Port = upnp-mcast(1900))
Protocol: UDP Incoming
Source: 192.168.0.1:upnp-mcast(1900)
Destination: 239.255.255.250:upnp-mcast(1900)
Reason: Network Control Rule ID = 7

And lots of these: [See attached text file]

I’ve been checking the IP addresses and they seem to be everywhere from Australia, Amsterdam, Canada, Uruguay and I’m sure there are more. By the way, I am in the US.

Thanks for any insight whatsoever, I am very curious what this is, and if it is related to my slow speeds, naturally I’d love to correct that.

[attachment deleted by admin]

7

Hallo,

One of these every 6 seconds:

Date/Time :2007-04-29 03:01:07
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 192.168.0.1, Port = upnp-mcast(1900))
Protocol: UDP Incoming
Source: 192.168.0.1:upnp-mcast(1900)
Destination: 239.255.255.250:upnp-mcast(1900)
Reason: Network Control Rule ID = 7

Do you have a router at 192.168.0.1 with upnp enabled?
If you answered yes then you should disable upnp if you are not using it or look at Tutorials - Network Rules

And lots of these:

Date/Time :2007-04-29 03:01:07
Severity :Medium
Reporter :Network Monitor
Description:Outbound Policy Violation (Access Denied, ICMP = PORT UNREACHABLE)
Protocol:ICMP Outgoing
Source: 192.168.0.2
Destination: NOT IN RANGE [ 192.168.0.1- 192.168.0.255]
Message: PORT UNREACHABLE
Reason: Network Control Rule ID = 7

These could mean anything.

These IPs attempted an UDP connection on a closed port on your pc ( 192.168.0.2 )

An easy guess would be that a P2P app was running and some client is still attempting to connect to it.
Do you have also any inbound udp blocked?

8

Well, you were right about the UPnP thing. (:CLP) I didn’t realize it was enabled in my router. How embarrassing. :-[ Naturally I disabled it… and it did correct that one type of alert. You also seem to be right about the unreachable alerts. Strange part is I continue to get them while using P2P and long after I close the connects and exit the program. Both incoming and outgoing unreachable. I could imagine how the remote peer continues to try to communicate with me (incoming ICMP), but why would my machine continue to send data (outgoing ICMP) if the incoming was denied by the firewall?
An observation is that while my P2P is running, 99% of the alerts are incoming unreachable, but after I exit the program 99% of alerts are outgoing unreachable. This almost seems backwards to me. In either case, I seem to be getting lots of alerts at all times. Even if this is not a “problem” I still wonder what I can do to stop my computer from sending hundreds of denied outgoing ICMP messages.

Edit:
No, I don’t have any rules set up to block UDP. Only the standard rule to block IP In/Out.
Should I create one?

9
Do you have also any inbound udp blocked?
My bad, I poorly expressed myself. I was asking if there was any blocked inbound udp traffic in the log. TCP & UDP Inbound traffic is blocked if not explicitely allowed in network monitor because the last network monitor rule blocks and logs all IP traffic IN & OUT that was not allowed by preceding network rules.

ICMP: PORT UNREACHABLE is sent to a client that attempted an UDP connection on a closed port. This message usuallly serve the purpose to let the cliient know that no service is listening to that port. Knowing that these clients usually won’t attempt another connection on that port.

When an Inbound ICMP: PORT UNREACHABLE is blocked by network monitor it’ll never reach any running application.

When an Outbound ICMP: PORT UNREACHABLE is blocked by network monitor it’ll never reach any client nor internet.

10

Well, honestly, I was thinking it was something like that, but when you put it that way it all became clear :wink:

Thanks. It all makes sense. At least, it did… until I added a rule that allowed ICMP unreachable, which basically eliminated those alerts. I assumed it was safe after your post, because I then looked it up on uTorrent, and they said they do use UDP ICMP for the DHT and that I should allow this traffic. It made total sense. But then, after I corrected that, it seems to have triggered a different type of alert instead… I don’t want to keep bothering you, you guys are so good and patient, I’m impressed.
Here is the new alert which comes in droves after i started allowing the ICMP Port unreachable.
Date/Time :2007-04-29 21:55:57
Severity :High
Reporter :Network Monitor
Description: Blocked by Protocol Analysis (Invalid Flag Combination)
Direction: TCP Incoming
Source: 60.50.206.1:54822
Destination: 192.168.0.2:3689
Reason: ACK FIN RST is an invalid TCP flag combination

I am not worried about this new alert, i assume its an error from the remote client. I think my original problem is resolved. Thanks for all the help! Isn’t it ironic that the only competent tech support is the kind thats free? (V)

11

Actually, no. I am more concerned that it is a portscanning attempt. I learnt about this from my Certified Ethical Hacker training.

The invalid TCP flag combination, when sent to a port, will generate 1 of 2 responses (I don’t recall which currently) that indicates whether the port is null (i.e. no listener) or not-null (i.e. something has opened that port for listening). Comodo in this regard blocks the packet, so that all ports scanned by ACK-FIN-RST looks like null, effectively making your workstation “invisible”.

I don't want to keep bothering you, you guys are so good and patient, I'm impressed.
Don't worry. We truly want to help new Comodo users to achieve the best security possible on their PC. In short, we're here to help :)
I think my original problem is resolved. Thanks for all the help! Isn't it ironic that the only competent tech support is the kind thats free? (V)

(R)

12

Black Hat eh? (:KWL)

That makes things more interesting, because I am getting lots of these from various IP addresses.
However, since my ports remain stealthed with the help of Comodo there is no further action necessary, right?

13

Heh, no, I’m white hat :stuck_out_tongue:

My server here routinely fields hundreds of such attempts everyday. Backtracing packets (if I feel like doing it :wink: ) usually find me a zombie-ized workstation.

Just several days ago my server got a DDoS attack. Apparently I had experimented allowing an ICMP message (to cut down the log entries), and as a result someone successfully mapped open ports on the server and attempts to overwhelm the server. Thankfully Comodo detects the flooding and immediately went into emergency mode.

14

Oops… that’s what i meant… hehehe

15

All solved then :■■■■

Maybe it was an os fingerprinting attempt, I was not able to find info on that TCP flag combination but an article stated that windows tcpip stack always respond with a rst-ack.

TCP Fin Packet:

A technique also used to detect open and closed ports, and of course, online or offline hosts is a TCP Fin packet scan. An open port will normally drop a packet flagged with the FIN bit. A closed port will respond with an RST/ACK flagged packet. However, notice that a W2K3 server also sends a return packet with RST/ACK flagged no matter if the port is opened or closed. Hmmm, could this be a unique feature of the MS network stack? Hold that thought for later use.

If I’m correct inbound tcp destination port 3689 is opened in network monitor. Could you enable logging on it?
It would be interesting to know what’s going on…

16

It was more than just 3698 though, I have attached a txt with the long string of invalid flag combination alerts. It certainly does look like a port scan.

[attachment deleted by admin]

17

Ok,

I looked at invalidflagcombo.txt.
It look like destination ports range from 1024 to 5000. So I assume these are inbound traffic responses to your pc initiated connections.

Looking around for info I found a related thread named “Invalid TCP flag rule before network rules in processing order”

Hi I have done some further analysis and can advise the following: 1. Ethereal seems to capture before packets get stopped by comodo 2. The invalid tcp flags 0x0015 RST FIN ACK all occur as follows: A) My pc running utorrent sends out a packet with tcp flag SYN to what I assume is the external pc bittorrent port B) The external system replies with a packet that is invalid, tcp flag 0x0015 C) Communication ends there until sometime later it goes back to A)

It appears that my system always initiates the connection when a system replies with the faulty flag set.

and an old paper named “Detecting Network Intrusions via a Statistical Analysis of Network Packet Characteristics”

The next type of packets with invalid TCP flags were packets that had both FIN and RST flags set and were sent to close a connection. Such packets were sent:
  1. In response to first SYN to reset the connection as RST
    packets;
  2. As the second FIN after the first FIN packet went in the
    other direction;
  3. After both FIN packets when the connection is almost
    closed
  4. After a RST packet in the same direction.

There is no one single explanation of all such packets. A
number of them, especially packets sent to close longer con-
nections, were most likely legitimate packets. However, we
believe that such packets should still be blocked because they
violate existing standards.
Other packets that had both FIN and RST flags set were sent
on their own without any other communication between the
hosts. Since packets from this group do not have connections
associated with them, the packets could be a part of a host de-
tection or fingerprinting attack.

If you compare your p2p log with cpf log when an invalid combo
is logged by cpf and you find matching IPs then we could assume
that is not a portscan.

18

(S)
I believe this verifies a few suspicions…
For the length of this time I have continued to get the strange Invalid flag combination alerts, as well as lag on my network even to the point of complete lack of response. and today I saw this one.

Date/Time :2007-05-09 23:40:41
Severity :High
Reporter :Network Monitor
Description: DDOS Attack (SYN Flood)
Duration: 20 seconds # of packets: 64 # of attackers: 1
Attacker(s): 4.79.142.206
The firewall has switched to EMERGENCY mode

Date/Time :2007-05-09 23:40:21
Severity :High
Reporter :Network Monitor
Description: TCP Port Scan
Attacker: 4.79.142.206
Ports: 4608, 6656, 6912, 7168, 7424, 7680, 7936, 0, 256, 512, 768, 1024, 1280, 1536, 1792, 2048, 2304, 2560, 2816, 3072, 3328, 3584, 3840, 4096, 4352, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
The attacker has been temporarily blocked

my router log also indicates SYN flood attack.
the weird thing is every IP address from every alert is different. could this be from IP spoofing or something? is this ever going to stop? :stuck_out_tongue:
oh well i guess i’m ok so long as i have Comodo :smiley:

19

My DDoS attacks happened after I allowed the ICMP Port Unreachable message to reach my server, in an (admittedly, rather stupid) effort to reduce the number of log entries.

Several hours after I enabled ICMP Port Unreachable in, I got my first DDoS attack. Comodo protected me. Then another attack 2 hours afterwards. And then the attacks went like clockwork, i.e. 1 every hour.

I unplug the Internet connection, restarted, and then re-block the ICMP Port Unreachable. I don’t connect for 2 hours first. No more DDoS attacks.

In my defense, I thought the ICMP Port Unreachable’s are due to my server also running uTorrent, since the source IP’s came from a whole lot of different IP’s. But apparently not.

As to why the sender IP’s are different… I think it’s suffice to say that the great (depressing) majority of people in the Internet are not protected by Comodo.

20

Hallo neph,

Glad to see you again (:WAV)

Did you compare your p2p log with cpf log when an invalid combo was logged by cpf?
There were any matching IPs?
Please post both logs, this could provide additional info about this behaviour.