8

I'm seriously confused about this, since the program is entirely developed by myself and has no means/functionality to connect to any network/the internet whatsoever.

I'm a software engineer but not knowledgeable about computer security, so while I have it running in the debugger of Visual Studio on Windows XP Professional my Comodo Firewall shows an alert that let's call it "MyProgram.exe" is trying to connect to the Internet.

Since there's no reason for this program to connect to the Internet I choose to block it. At the end in the firewall logs, 5 connection attempts of MyProgram.exe are logged in a time-span of a few minutes listed and the whole incident is listed as "Firewall has blocked 1 intrusion so far".

(Btw the real name of the program and residing folder is very unique and I can definitely not mistake a different program for this.)

The complete source code is written by me except for a parser and lexer that were auto-generated by antlr. The source from which they are auto-generated is written by me as well.

A reverse lookup of both IPs, it seemingly tried to connect to, is listed as belonging to the same big internet company.

(I'm using an up-to-date virus-scanner and I never had virus problems with this pc. I checked the running processes with process explorer and didn't find anything unusual.)

Could that be a bug in the firewall, like a false positive?

Could it be that the connection attempt was actually coming from a different application and got mismatched with my program due to it being run in the debugger?

What would your thoughts/steps be in such a situation?

I assume that a lot more information is necessary to answer this but I'm not sure what's relevant and what's critical or uncritical to post, so what would be important?

Update

Thanks a lot for the answers.

I'm writing a little more verbose about my findings in case someone else has a similar problem so that this is easier to find.

The main thing that had me confused was the combination of the following:

  • It looked random; in other words I couldn't match it with something I did which might have triggered it
  • I couldn't reproduce it (neither with the debugger nor with the standalone exe)
  • I'm developing this program for over a year now and this has never happened
  • Shortly before that another program (which I downloaded just a few days ago) tried to connect to the internet, which didn't seem necessary/not triggered by me as well.

To keep it short, the other programs connection attempt was definitely unrelated to that and very likely just an update check.

The company the IPs belong to was Akamai and after searching again I found an article describing an "alliance between Akamai and Microsoft" and "service available to ... .NET developer tools such as Visual Studio(R)"

So after that I thought it's very likely that it was Visual Studio and tried again to reproduce it and finally accidentally did so when clicking on the +-symbol to expand a CommonTree-variable in the watch-window during debugging. Since I can now always reproduce it with that, this must have been what triggered it the first time as well.

So with hindsight what happened the first time I would say is me clicking on it triggering the connection attempt and since I block it or let it timeout these five tries all belong to one connection attempt by visual studio and expanding or collapsing the CommonTree-variable after such a connection attempt does not trigger another one, which makes it look very random.
All this and the fact that a "debug-run in itself" (without the click) doesn't trigger it is the reason why I couldn't assign it at first to this very specific trigger:
"during debugging expanding a CommonTree-variable in the watch-window".

Improve this question
1
  • 2
    Do you mind posting the pertinent bits of your firewall logs? Feel free to obfuscate the details of your program, and your source IP. The remote IP, protocol, and local/remote port numbers should be enough to help narrow down the problem - if it will be useful at all.
    – Iszi
    Commented Dec 1, 2011 at 3:09

3 Answers 3

Reset to default
5

A couple questions first:

  1. what do you mean by "the same big internet company"?
  2. Is it MyProgram.exe or MyProgram.vshost.exe trying to connect?
  3. What happens when you run the application in release mode without the debugger?

It could be that the Visual Studio debugger is trying to download debug files for CLR assemblies and the firewall is mistaking the request as coming from your app instead of the debugger hosting your app.

Improve this answer
1
  • The company the ips belong to was Akamai. It was MyProgram.exe not the vshost-version. And at first I couldn't reproduce it neither in release mode/standalone nor with the debugger.
    – Jennifer Owens
    Commented Dec 1, 2011 at 20:25
3

The connection between the debug code, injected into your program, and Visual Studio may be based on the internet protocol and the firewall may confuse this with an connection to the Internet. You know, those desktop firewalls have to show to the user that they are worth the money.

The Windows Firewall is known to show a warning when one debugs a Java program via the Eclipse IDE. The Windows Firewall gives enough information to make the cause obvious.

While the debug connection is the most likely reason, there still might be a real threat such as a virus infecting your program. But without the details of what the firewall exactly discovered (protocol, source ip-address, target ip-address, source port, target port), it is impossible to answer.

Improve this answer
2

It is quite possible that it's a false positive.

If possible you can disable the block rule and run (Since you are the developer of the application)

netstat -anob

This will show if MyProgram.ext is making a connection and with what.

If indeed it's making a connection then you can look up the IP it's communicating with (e.g. something belongs to MS or so weird IP).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .