Applications:
Avira Premium Security Suite (without firewall last version)
Comodo 3.0.15.277
Avira has a webguard that checks information through port 80.
Rule for Avira webguard (avwebgrd.exe):
Allow IP Out From IP Any To IP Any Where Source Port Is Any And Destination Port Is Any
Its treated as Custom.
Now an example, utorrent sometimes has a connection to an IP with port 80 (direction out). TCP of course.
For utorrent, I have a rule that permits these kind of connections, but just because ASK does not work well (Comodos BUG that still is NOT fixed). HTTP requests.
But here is what happens, Avira webguard Allows it allways, therefore even if I had a block rule for HTTP requests in utorrent, COMODO will not block it, because of Avira.
I supose this will happen with all Antivirus that guards port 80. Avira, Kaspersky, etc.
So:
What is the solution for this? A special rule for avwebgrd.exe (NOT CUSTOM)…
When is the bug going to be fixed for HTTP requests???
It’s not a bug. It’s the way all firewalls work with proxies.
If you have “Enable alerts for loopback request” enabled in Firewall Behavior Settings you should get an alert, something like
“UTORRENT.EXE is trying to connect to internet”
Application: utorrent.exe
Remote: 127.0.0.1 - TCP
Port: [Some port]
However it’s likely that your current rules for utorrent allow that connection.
Could you post your rules for utorrent.exe?
Now, what I’m saying, avwebgrd.exe checks whats going on on port 80 (checks if a malware is downloaded, scrpit, etc while surfing). If avwebgrd.exe is enabled, when ANY application uses port 80, AVIRA will scan it. Avira’s RULE is USED, NOT utorrent.exe.
It’s not a bug. It’s the way HTTP scanning works in most antivirus. The AV creates a transparent proxy. The HTTP request are redirected to localhost to the port where the AV is listening. The AV process receives the request, perform the request in behalf of the application. The AV receives the response from the remote server, scans it for malware and then sends it to the application through a loopback connection as well.
In Network Security Policy edit the rules for utorrent.exe. Create the following rule before Rule 2:
Ask/Allow/Block TCP Out
Source Address Any
Destination Address 127.0.0.1
Source Port 1025-65535
Destination Port 1025-65535
Now close utorrent.exe if it’s running and execute it again.
I know which port Avira uses to scan HTTP, I think… It listens 44080, so it should be that right?
Ask/Allow/Block TCP Out (Which one should I choose??)
Source Address Any
Destination Address → I have Loopback Zone, would that work??
Source Port 1025-65535 (I supose)
Destination Port 44080 (or 1025 - 65535 ??)
And by the way, OK, AV’s way of scanning is not a bug, OK, but what about, putting ASK in HTTP REQUESTS and Comodo does NOT ASK but it BLOCKS without asking??? Thats a bug right?
Putting ALLOW in the RULE:
Allows it and logs, OK.
Putting ASK in the RULE:
NO ALERT. Allows the connection and LOGS.
Putting BLOCK in the RULE:
It blocks and logs, OK.
and 3) seem reasonable.
very stange:
I supose it ALLOWS because the next RULE says so. I imagine it is configured as PERMIT has more PRIORITY over ASK (NOT by position in the SET of rules). Now, but the strange thing is that it LOGS the connection.
AND I supose BLOCK has more PRIORITY over PERMIT. NO just tried it. BLOCK DOES NOT have more PRIORITY over ALLOW.
By the way I use a Predefined Firewall Policy named as utorrent.
It’s ignoring the rule with ask action and applying the next suitable rule (the first one that match protocol, direction, source and destination of the connection). If logging is enabled in the former rule, then the latter rule inherits the logging.
With the bug I think ASK is useless now as the purpose of ASK is being placed before other ALLOW or DENY rules to receive a prompt.
I’ve seen the same behavior with Kaspersky 7’s HTTP scanning module (which actually scans any traffic on ports you specify). It seems that Kasperksy installs a network minidriver of some sort, which intercepts IP packets (or TCP/UDP segments) and re-routes those on specified ports via it’s scanner. This is outside the scope of normal TCP/UDP operations (with server listening on some port, and client addressing it), so the whole process is beyond Comodo’s reach, which sees Kaspersky as the originator of those connections.
The BUG with ASK rule, I don’t think it has do to anything with the AV. I don’t want to uninstall the AV just to prove it… Its a long procedure, uninstalling, cleaning, proving, installing AV again. UUFF!!
I would say ASK rule is COMODOS problem. I’ve seen many people with this problem in the forum. I think Comodos developers are the ones that have to prove it and FIX it. Some time that this BUG exists. (:AGY)