Port Scan Strangeness in Version 5.9

Has anybody checked the firewall’s behavior on inbound port scans and noticed
any strangeness? I’m picking up something weird and new on 5.9, an issue I
did not appear to have with 5.8; at least not that I ever noticed.

For instance, tonight, a scan of my first 1056 ports produced a firewall alert telling
me that mirc.exe was accepting inbound connections on port 1038, and did I want
to allow or block it. I immediately did a netstat to see what was occurring, and
picked up th following:

Active Connections

Proto Local Address Foreign Address State PID
TCP local:1038 punch.va.us.dal.net:7000 ESTABLISHED 2668
[mirc.exe]

As you can see, mirc.exe did have an active connection up, but it was an outbound
connection with a local port of 1038 and a remote port of 7000.

Naturally, mirc.exe is not configured to listen for any connections on that port.

My firewall rule for mirc.exe hasn’t changed since 5.8. As a matter of fact, just
for the sake of a test, I imported my old 5.8 configuration into 5.9. The result
was the same. The only rule I have set for inbound connections to mIRC is for
ident on port 113, and that port only listens for a few seconds while the main
connection is being established.

The issue is repeatable. In addition, if I close things down, restart the PC.,
fire up mirc, and re-run the scan, the firewall produces and inbound alert on
whatever port mirc happens to be using the next time for the outbound
connection.

I think what I’m going to do tomorrow, since the hour is late, is remove 5.9 and
reinstall 5.8 to see if I can reproduce the issue. I might also see if I can duplicate
this with a streaming media connection. I will report my results back to the forum.

Regards.

I’m not able to reproduce this. Would you mind providing some details about the settings you’re using for the firewall please.

See below :embarassed:

Update:

Yes, it’s confirmed. I get the same firewall inbound alert with a streaming media
connection, using Windows Media Player. This time on port 1116.
Here’s the netstat:

Proto Local Address Foreign Address State PID
TCP local:1116 pro02.live365.com:http ESTABLISHED 2656
[wmplayer.exe]

I’ll try this with 5.8 tomorrow. Stay tuned.

Regards.

General Settings:
Custom Firewall Security
The only option ticked is show tray animation.

Alert Settings:
Alerts on high.
All options ticked except for computer is an Internet gateway.

Advanced Settings:
Nothing ticked.

More info tomorrow. I’m hitting the sack.

Regards.

No worries, it’s me being a twonk, I forgot to connect the test PC directly to the Internet, so the scan was probing my router ports, not the firewall.

What you’re seeing is actually quite normal. Basically, a port scan works by sending a message to one or more ports and depending on the response received from the scan, the ‘scanner’ can determine the state of the port. So, an open port will obviously respond differently to a closed port.

With regard to the alert you’re seeing, this will depend on your settings you have for Global firewall rules. If you have installed the full CIS suite, or you’ve run Stealth Ports Wizard with the third option:

Block all incoming connections and make my ports stealth for everyone

There should be a Global firewall rule - the last in the list - that blocks IP in from anywhere. If you don’t have this rule, basically, anything with an open port, should generate an alert when an inbound connection request is received.

Hi. Thanks for writing.

That’s all well and good, but we’re not talking about open ports here. It’s not like mirc
is sitting there like a server with an open port waiting for someone to connect to it.
We’re talking about ports involved in established connections, that appear as closed
from the outside. As such, mirc was not “listening” on port 1038, which was
referenced in my original post.

If the firewall alert had been:

“Someone at xxx.xxx.xxx.xxx iis trying to connect on port 1038, which is closed.
Would you like to stealth this port?”

…then I could have dealt with it appropriately.

Instead, I got “mirc.exe is trying to receive a connection from the Internet.”
No, it wasn’t really doing that at all. Although mirc contains a built-in ident server
which listens on port 113 during connection, mirc itself is not a server application.

With regard to the alert you're seeing, this will depend on your settings you have for Global firewall rules. If you have installed the full CIS suite, or you've run Stealth Ports Wizard with the third option:

Block all incoming connections and make my ports stealth for everyone

There should be a Global firewall rule - the last in the list - that blocks IP in from anywhere. If you don’t have this rule, basically, anything with an open port, should generate an alert when an inbound connection request is received.

That wouldn’t work for me. I can’t create a blanket rule like “stealth port wizard”
does, because I have legitimate applications that need to accept, as servers,
inbound connections on certain ports.

I agree that anything with an open port should generate an alert, but again,
we’re not talking about open ports.

What I have done, as a workaround, is created a global rule to block any inbound
connection attempts on ports 1024 through 5000. A port scan now reports full
stealth in this range, regardless of what I have running at the time. I may extend
the high end of that port range in the future.

Part of the problem I have adjusting to Comodo, is that I’m used to firewalls that
stealth by default and block incoming connections, but allow you to configure
exeptions for apps that need to act as servers.

Regards.

Just thinking out loud and slightly out of the box. May be you are trying to connect to a slow reacting server breaking Stateful Inspection. Can you reproduce this issue when trying to access various servers?

The port is ‘stealthed’ to the outside world but it’s still responds to a ‘TCP syn’ locally. It’s this that generates the alert. You can counter this in one of two ways, block all unsolicited inbound connections via a Global rule or add a block rule for inbound connections specifically against the application.

Part of the problem I have adjusting to Comodo, is that I'm used to firewalls that stealth by default and block incoming connections, but allow you to configure exeptions for apps that need to act as servers.

Regards.

That’s pretty much what you do with CIS. Run the stealth Ports Wizard (the firewall already has this configuration if the full suite is installed) to create a Global Block for inbound connections, you then create exceptions for any server processes above the block rule.

[attachment deleted by admin]

Hi. Thanks for writing!

You read my mind… stateful inspection is something that I’ve been thinking about
since my original post.

As far as various servers are concerned… I generally use mirc on two of the most
responsive servers with the least latency that I can connect to, but that may still
be too slow for the firewall. I’ll try some different ones and see if the results are
any different. Generally, the RTT on the server is about 31 milliseconds.

As I mentioned in one of my previous posts, I am also noticing the alerts when
I use Windows Media Player connected to streaming audio sources, while my
ports are being scanned. I have not, however, experienced any issues with
running Internet Expolorer during a scan.

I also ran into another unexpected alert last night during a port scan… “System
wants to receive a connection from the Internet.” That was an inbound
alert on port 1025. The port scan showed that port as closed.

Anyway… my new global rule is taking care of all these issues, so maybe it’s
time for me to stop pulling my hair out over this.

Again… thanks for sharing your thoughts. I’ll post back if I find out anything
new.

Okay… I understand what you’re saying. That’s not how I initially configured the firewall.
I used the stealth ports wizard, but I didn’t choose the “block all” option.

Because I originally wanted to get familiar with how the firewall alerts were produced,
and also because I like to manually tweak stuff, I chose the “make my ports stealth
on a per-case basis” option, then filtered all of the port-level stuff in the application
firewall rules. In hindsight, this may not have been the wisest choice. Your method
would certainly have prevented the alerts I’ve been seeing over the past few days.

Thanks for your insight.