new port scans ??

Hi Bill,

From what you've shown, it doesn't look like these scans are related. The TCP scans have incrementing remote ports, and I'm assuming the local port on your machine is staying the same (TCP port 6963, though you don't show enough to be sure of this). In this case, it's probably just some application looking for some service at your IP address. Is the source IP address always the same as the one shown?

The UDP scans just look like the usual port 137 NetBIOS Name scans (i.e. from Bugbear or Opaserv Opsserv)? Can you confirm that by looking at dest. port number?

If your IP address is dynamic, and is readily change-able, then I'd suggest changing it to cut off the TCP scans.

Best Wishes,
LowWaterMark

- Edit: darn typos

 

Changing the source (remote) port is of no advantage to the person at the other end in a situation like this. That changing won't have any effect on your PC's security, or whether or not your port 6963 is responding. So, I doubt this is intentional. It is more likely that the way the program is coded is that each request simply comes from the next available source port, which is normal.

There is no profit in someone intentionally doing this from a single source IP address. It is not fast enough to be a DoS attempt, and it can't be using any significant portion of your available bandwidth. So, I still think the person / program at the other end is trying to connect to some service it thinks is at your IP and port 6963. (Maybe the person just mistyped the IP address.)

As to what to do about it, given you are on a static IP address... The first idea is to just wait it out. It started at some point in time, and it will end likewise. If the person never gets a response, why keep sending requests. You could just wait.

If it goes on and on, and doesn't end, you could try reporting it. You'll need to send your text firewall logs to their ISP for that. I'm not sure you'll get much action on it, but you could try it.

You could also look at http://www.mynetwatchman.com/ to see if that source IP address is on their incident lists. Do you submit your logs to a service like myNetWatchman? Getting patterns of such events helps a great deal in resolving issues like this.

Right now, ZA (you're using ZA Pro, right?) is stealthing response to these SYN requests. That's fine and all, however, the calling program may just think the server they are looking for is off the air and may keep trying until it does get a response. Changing ZAP so that it allows a closed response is also an option. This would be a normal response expected by software that is trying to get to a service that is not running at an address...

If you want to try it, in ZAP, you can go to the Firewall > Main > Internet > Custom > "Allow incoming TCP ports: " and enter: "6963". See diagram. (Sorry, I've been away from home for several days and do not have access to most of my software or tools, so this is an old screen shot that shows allowing port 80. You'd use 6963, of course.)

What this ZAP feature does is to allow incoming requests to the specified port(s) to be passed to the OS. If you are not running any listener on port 6963, then an immediate closed response would be returned to the caller. That response, or perhaps several, may discourage the calling program. Just another option. (I have several ports in this list just so I'm never bothered by these types of requests: 1214, 1433, 6346-6348 (kazaa, MS SQL server, and gnutella). I stopped being interested in all these requests long ago, so I let my system respond as closed and I never see these.)

Hope some of this helps,
LowWaterMark

- Fixed image - "What port 80, root?"

 

That's the problem when you have to recycle images.

It's been rough working away from home. Using an old Pentium Pro 200 Mhz, running Windows 95 and using 28.8 dialup. (It'll be nice to get home. )

 

You have to love a happy ending.