Invalid TCP flag rule before network rules in processing order

[neph]

@pepoluan post: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.

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.

This sounds exactly like my story. Trying to reduce log entries and believing it was legit traffic for uTorrent. I will re-block ICMP and disconnect my network tonight and see if that helps tomorrow.

@gibran post:20

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.

Actually, I was unable to compare the logs because uTorrent doesn’t exactly have a log.:-[ It does, however, have a list of currently connected IPs, and I wasn’t able to match those with any of the IPs listed in the Comodo log. I see what you were trying to determine though, but it’s still a little perplexing. The Comodo log alerts would change a bit depending on when uTorrent is/was running, however when I received that SYN flood and port scan, I had not run uTorrent in days. I can’t figure if it is related or not, but I cannot match any of the IPs with my peers in uTorrent. Would you still like to see the Comodo log? I think its pretty much the same as before except for the SYN floog which is posted above.

[system]

Hi neph. I replaced your log as a text file to shorten the post. Also, if the issue isn’t completely gone, it’d be better to remove the [resolve] indicator in the topic title to accurately reflect the situation for now.

[gibran]

@neph post:21

Actually, I was unable to compare the logs because uTorrent doesn’t exactly have a log.:-[ It does, however, have a list of currently connected IPs, and I wasn’t able to match those with any of the IPs listed in the Comodo log. I see what you were trying to determine though, but it’s still a little perplexing. The Comodo log alerts would change a bit depending on when uTorrent is/was running, however when I received that SYN flood and port scan, I had not run uTorrent in days.

SYN flood and port scan are attacks but 10 days is rather a long time, but if you had those attacks during the last 10 days then those activities are likely closely related. I downloaded uTorrent 1.7 beta this version has logging in the events section (right mouse button: enable log peer traffic, extended, errors, log to file options)

[system]

@neph post: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?
oh well i guess i’m ok so long as i have Comodo

That IP belongs to the Shields UP! domain which is a firewall leak-test service. I think it wasn’t a hacker atack but an intended scan.

I’ve got also that strange Invalid flags combination alerts. After googling it and reading this forum I come to conclude that it may be a port scaning. Sometimes I’ve got handreds of these alerts in log and all come from only several IPs. If it was P2P client problem, it would come from different IPs. Besides, as far as I know bittorrent protocol is an application layer protocol and TCP is a transport layer protocol. I don’t see how bittorrent could affect TCP flags.

[gibran]

@fOrTy_7 post:24

That IP belongs to the Shields UP! domain which is a firewall leak-test service. I think it wasn’t a hacker atack but an intended scan.

I’ve got also that strange Invalid flags combination alerts. After googling it and reading this forum I come to conclude that it may be a port scaning. Sometimes I’ve got handreds of these alerts in log and all come from only several IPs. If it was P2P client problem, it would come from different IPs. Besides, as far as I know bittorrent protocol is an application layer protocol and TCP is a transport layer protocol. I don’t see how bittorrent could affect TCP flags.

Welcome to this forum.
If you don’t mind please read the entire thread and related links. You’ll find some clues and suggestions about what it is needed to really solve this matter…

If you are going to compare BT and CPF log another useful thing would be to know each BT client name for every ip.

[Neglacio]

Please, don’t let Comodo block the TCP packets with as flag ACK FIN RST. This packet is mostly used by P2Pprograms, especially Gnutella clients. If blocked, you won’t connect to the network.
Thanks in advance

Greetings,
Neglacio

[Little_Mac]

Welcome to the forums, Neglacio. Are you experiencing a situation where Comodo is blocking your p2p application(s)? If so, have you configured the Network MOnitor rules in accordance with the tutorials in this link (and added appropriate Application Monitor rules to allow the p2p client access? https://forums.comodo.com/index.php/topic,6167.0.html

LM

[Neglacio]

Well, I’m using Shareaza, and I’m one of the few people who test it and translate it.
So I know how to set up my firewall
I observated the logs from Comodo Firewall, and observated Shareaza’s behaviour.
Whenever Comodo Firewall blocked ACK FIN RST Acknowledge Final Reset, Shareaza stops Handshaking Gnutella2 Hubs and Gnutella Ultrapeers.
If I turned Protocol Analyse *literally translated from Dutch * off, nothing went wrong.

Greetings,
Neglacio

[Little_Mac]

Well, Comodo is a SPI firewall with a powerful engine (it should be able to accurately analyse the packets for validity) for that purpose (which disabling Protocol Analysis effectively turns off), with a layered ruleystem different than other firewalls. For inbound, it goes thru Network Monitor, Application Monitor, and finally the Advanced Monitor (combination of Components and other Advanced features). For outbound, the sequence is different - Application, Advanced, then Network. If the connection attempt fails (ie, it is not explicitly or implicitly allowed) at any of those, it will be blocked.

I say that not to denigrate your ability to configure a firewall as part of your testing; only that this firewall works differently than most others, and has left many experts scratching their heads. If you have not checked out the tutorials for configuring CFP for p2p apps, it might be worth your time.

Then too, in some cases, the rulesets that should work for p2p apps have not done so, and disabling protocol analysis was the only thing that did the trick.

LM

PS: I’m merging this with an existing thread on the same topic - ACK FIN RST and p2p apps