CFP 3 is blocking Avast? (V3.0.1.12 x32) [RESOLVED]

Keep getting a few logs like this…

[Topic Closed: If issue returns PM an online mod to open]

[attachment deleted by admin]

Have you checked the application rules in Firewall / Advanced / Network Security Policy?

Yes, Avast is allowed to access the internet and everything…

Incoming connections…Allow port.

Not exactly blocking avast! These are various servers that host website pieces, from Google, some ISPs, etc. trying to make a connection to you to send you stuff (ads, ?, etc-needs more expertise than I have). Do a whois on some of the IPs. Your portal to the internet is usually ashwebsv.exe, the Avast! web scanner, and when it tries to make an inbound connection, gets blocked, unless you allow inbound connections. I made a separate rule to block and not log stuff coming from the http ports of the various websites, and most of the logged stuff went away. And didn’t miss anything important. Maybe an expert on the current web server scene will jump in, but I haven’t found any reason to allow this stuff in.

a few were Google and “cerfnet” and RIPE something from Amsterdam… so i guess Avast is actually fine then :slight_smile: Thanks for everyones help :■■■■

Edit: How does one delete logs in CFP 3?

Firewall → View Firewall Events → More

Here you can delete both firewall and D+ logs.

LA

I have a P4 HT, My system internet browser is Firefox, OS: XP sp2 32bit, AV: Avast Other Security Apps: Comodo Memory Guardian 1.6b
Log enties for System idle process and ashwebSv blocking inbound tcp traffic from Port 80.
blocked IP included traffic from Comodo, opera, and avast owned IPs.

I have no global rule to allow http inbound traffic.

Wireshark Traffic analysis showed that these are RST packets and some of them are not blocked (no log entry)

Does this mean that V3 is actually blocking RST Packets?

This is an old Bug

Regards,
gibran

Gibran, most of the TCP in requests we receive have nothing to do with Comodo, or Avast!, but could be browser requests coming back from Opera. Except they come from IP addresses that have nothing to do with the Opera requests. My concern is that they are the result of the constant redirection of addresses that happens for a modern web page. Hard to believe we get that many RST responses, and that they mostly come from redirects. They look like a way to get around the NAT router if you are an advertiser/data collector/ hacker, by responding to outbound requests from a redirect. But certainly not an expert-only thing I can tell you is that blocking them makes absolutely no difference. And so I will keep them blocked until a problem comes up. Don’t think it is a Comodo problem at this point, except for maybe adding blocking to the default web browser policy.

Redirection has nothing to do with this.

If you really want to contribute please try to test what I reported. Even a negative test result will do ;).

Not sure what you are asking to be tested in your previous message-use of wireshark? Both Goose17 and I have verified via WHOIS that these are not directly from the sites we are accessing, and come from various ISPs and countries. Or is WHOIS that unreliable? There may be some Comodo, Avast!, Opera owned IPs but we are unable to recognize them. Try a WHOIS on Goose17s page and help us understand. Thanks; Ed.

If you really want to be sure that is unrelated traffic then log outbound connection on port 80. You should see that you get blocked inboud on the same addresses you got outbond connections.

This is not a BUG. Those are delayed RST packets. There is no such thing as allowing every RST packet. Stateful inspection makes sure proper RST packets are received. If a RST packet delays, it is just a garbage.

Thanks, for you reply.I see that this should correspond to V2 Protocol Analysis Log entries. Will the Log be redesigned to report those informations in future adding a way to filter only protocol analisys entries?