Port Scan Attack Help...

Two possibilities, after you checked with grc.com that all unnecessary ports are closed, and that your software is up to date and properly protected:
1. Switch off the reporting function on your firewall, or
The ultimate solution:
2. Judicious application of a wire cutter between your router / modem and your telephone line.
 
And now there are like 20 an hour....How can i stop this?! It is p1ssing me off...

Why is it bothering you? You're gonna get port scanning all over the place. It's not always hackers scanning ports, you get other software doing the same. My firewall even picks up "port scanning" from Microsoft when it's doing updates [although the definition on my firewall of "port scanning" actually includes "attempts to send suspicious/fragmented packets to a certain port" ] .

If you're using any P2P software all these "attacks" will probably light your firewall up like a christmas tree. As long as your firewall blocks it, i wouldn't be too worried.

Firewalls pick up zillions of "attacks" per day, they just don't always tell you in detail. When i switched from windows firewall to something more elaborate i also got a shock to see 100+ "attacks" being blocked by my firewall ...i couldn't see this detail on windows firewall.

Anyway as the previous poster said, just turn off the alert/reporting of those attacks [so the firewall detects+block but just doesn't tell you everytime]
 
What legitimate reasons are there to scan other people's IPs?

1. Just plain finger trouble, as I described
2. Security research
3. Any other white hat activity.

I think the knee-jerk response against scanning is a problem, because as a result there are really good guys who are abandoning it as a tool, to the detriment of everyone.

So what do you say to the guy who out of curiosity, and with no intention of cracking anything, runs on his university's network the scanner software he is developing, discovers and reports vulnerabilities, only to be expelled for the unauthorised scanning? I am on his side. I can see the university authorities' point too. But their system failed to discover the problem, so he did them a favour, for which they rewarded him with an application of blanket rules.

The problem is the *idea* that all scanning is illegitimate, regardless of the intention of the scanner. That idea can and has lead to the making of counterproductive rules which may in turn lead to laws. The bad guys will ignore the law anyway. Researchers who need to scan e.g. to understand the scope of vulnerabilities on the Internet, or for whatever reason, may be prevented from doing so. Net loss to all.

I realise that this is a hot-button topic on which we will probably never see general agreement, but I would prefer to be scanned than to see scanning banned.
 
Two possibilities, after you checked with grc.com that all unnecessary ports are closed, and that your software is up to date and properly protected:
1. Switch off the reporting function on your firewall, or
The ultimate solution:
.

I have done this now. not really a solution but its not bothering me so much any more..:p
 
My firewall doesn't report these things as they happen, but they are logged and summarised. During the average day anything between 500-1000 packets are dropped by my system. Mostly Windows machines trying to share their hard drives (:eek: ), but also anything from port scans to automated login attempts.

That machine is off now (on holiday) but I suspect I would have seen the same sort of activity, had I looked. Good to see this sort of thing from time to time - motivates me to recheck my security.
 
ShieldsUp and the such does not report accurately on your PC's firewall.

Reason why - you have to initiate contact with grc.com, and it is because of this that an outbound connection opens a port on your firewall to allow packets to go out and return from grc.com - including the packets used to scan your PC.

A more reliable way (and method) is to ask one of your friends (whom you can trust) to hammer your PC with Nessus or any other portscanning tool.

And do get an dedicated firewall like Smoothwall or IPCop - software firewalls do get bypassed one way or the other.
 
ShieldsUp and the such does not report accurately on your PC's firewall.

Reason why - you have to initiate contact with grc.com, and it is because of this that an outbound connection opens a port on your firewall to allow packets to go out and return from grc.com - including the packets used to scan your PC.

A more reliable way (and method) is to ask one of your friends (whom you can trust) to hammer your PC with Nessus or any other portscanning tool.

Am I wrong when I say that your firewall will (should?) open for reply only the port on which you made the outbound connection, which should be in the 49152–65535 range, so you should get a valid test of at least the well-known ports?

That said, I have seen hosts connected to SAIX ADSL which expose ports in the range 135-9. (Microsoft NBT, I guess) These ports are open to other ADSL users, but are not always visible from elsewhere on the Internet, although they sometimes are. I don't know where this blocking takes place.

So it would seem to me that outside scans may not always show ports which are exposed to other ADSL users.
 
Reason why - you have to initiate contact with grc.com, and it is because of this that an outbound connection opens a port on your firewall to allow packets to go out and return from grc.com - including the packets used to scan your PC.

In principle the grc.com test can do just as good a job as your mate with his port scanner. If you open an OUTBOUND connection to initiate the test, the port used by the outbound connection does not create a sudden new open port for an INBOUND connect request. If the grc.com test then attempts to connect to your computer on a range of ports, there is zero difference to your mate's port scanner, which is doing exactly the same thing ie: attempting to initiate a connection to you on a range of ports. Your tcp/ip stack does not differentiate between grc.com and a mate. Your firewall should be blocking most incoming connect requests ( if not all ) ie: ignore/trash the incoming SYN.
 
Top
Sign up to the MyBroadband newsletter
X