I am new here and still relatively new to comodo firewall. Sorry if this issue has been brought up before.
I have tried various firewalls (online armor free, pctools, zonealarm free) and finally settled on using comodo. One of the reason being that it did not seem to crash any application and doesnt seem to have too many bugs.
I have a suggestion which I think would be very useful in helping people to judge if they should allow or block a request: To show the hostname that was requested by a DNS call (both in the alerts and the logs). This would save me from having to do a separate reverse DNS check to get an hostname (and unfortunately most of the time, the reverse DNS does not resolve to the original requested hostname).
I understand that DNS requests are done via two different ways. 1) the application sends a UDP packet directly to the DNS server on port 53 and 2) the application uses Windows XP DNS client who may or may not send a packet depending if the name is in its cache already. Method 2 is already detected by Defense+ (DNS/RPC Client) but it doesnt mention the requested hostname.
The PCTools firewall does show the hostnames and I would like to see this in Comodo. So…that’s my suggestion. Thank you!
Actually, my ideal implementation of this is like this:
…have the program’s actual connect request listed.
While most other programs use domain names,
some programs instead have hardcoded IP addresses which they request.
Especially “underground” programs, like trojans etc,
will often have those hardcoded IP addresses.
So I would very much like to see the actual request the program does,
e.g. it should show “comodo.com” if that was what the program tried to connect to,
or it should show “91.199.212.132” if that was what the program tried to connect to.
…an option (default=on) to resolve by DNS lookup all entries that originally were domain names into IP addresses.
This should be listed in a separate field, along with the original domain name, both in the pop-ups and the firewall logs.
…the opposite, an option (default=on) to resolve by reverse DNS all entries that originally were IP addresses
into domain names. Again, this should be listed in a separate field, along with the original IP address request, both in the pop-ups and the firewall logs.
So in practice, it should be 3 fields:
| Original Request: ______ | Domain Name: ______ | IP Address: ______ |
It is of course the “remote” part, not the “local” part that would need this the most.
But - in your UI, the “remote” part can both be “Source IP” + “Source Port”
and also “Destination IP” + “Destination Port”.
So, I guess the only plausible implementation would be first the
Application, Action, Protocol, …
and then
…, Source Original Request, Source Domain Name, Source IP Address, Source Port, Destination Original Request, Destination Domain Name, Destination IP Address, Destination Port
(this is for the firewall logs)
This thing is especially important for those of us who use the “DNS Spoofing to 127.0.0.1” technique,
by editing the %windir%\system32\drivers\etc\HOSTS file.
With the current implementation, we will only get entries with the spoofed “127.0.0.1”,
when the program actually tried to connect to a “bad host” like www . bestwinfixer2009 . com
(just a domain name I made up now!)
Would also like DIRECTION in logs for those with dynamic IP who get
frequently hit by others on same subnet (Three MOBILE, was it me calling
them or them calling me?)
Also, would be lovely to have a RE-INTEROGATE THREATCAST button, as an
alert can be generated whist not internet connected.
Reverse DNS does not nessessarily mean one to multi resolution, frankly spoken it’s not designed for that purpose. The site you linked is a service of it’s own with a huge database / query system behind it.
But for showing the owner of an IP for example a
dig -x 97.74.144.152 (on Linux) / nslookup -type=ptr 97.74.144.152 (on Windows)
in a console is fairly enough and you’ll get p3nlh152.shr.prod.phx3.secureserver.net as a result.
Of course this is a quite confusing entry when I’m browing a website and I’m asked to allow that traffic.
However
this scenario is somewhat more rare than an application contacting a hardcoded IP which we want more information about because usually one allows a browser to do TCP OUT to ANY IP address on port 80, 443 and 8080
and if an IP is not hardcoded in an application, we first have a normal DNS lookup which the firewall could just capture to save and reuse when nessessary
In addition I would prefer the label for the IP or host name to have a popup menu from which further features may be called (like whois or this domain check of yours)
Sure it has an overhead, but it could be processed in background changing the IP to the host name when the result is there.
What have you in mind with “process information”? Something like process parent?
I guess I said something similar but from a different perspective though I got the impression you are focusing on the fact that is possible to get a single result even in case of multiple domains mapped on the same IP (as above)
But even excluding browsers there are also many apps that rely on http updates or alike that could not use an harcoded IP, whereas even in case of hardcoded IP the user may be not aware the IP was hardcoded at all.
The log though would provide another chance of confusion as the standard browser rules often block sometimes some resources (usually ads) served on non standard ports.
I guess the confusion is somewhat related to the user expectations whereas it could be assumed that there is always an one IP to one service/domain match
Though as I understood your point reverse dns would be more meaningful than a single IP and that a major modification of the engine to trap DNS resolves in case of domains could provide a way to address multiple hosts on the same IP.
