I started my port scan detector, and I saw that the majority of IP packages arriving from the internet to 'illegal' ports of our Unix server arrives to port 137 (netbios nameservice).

The packages come from machines all over the world, from places I never heard of.

Are these packages possibly sent by misconfigured windows machines, or maybe portscanners looking for victims?

Should I be worried about them and deny the senders?
What is your opinion?

Are these packages possibly sent by misconfigured windows machines, or maybe portscanners looking for victims?
How about both? I know, I should read the other thread again, but what was your argument again for not running Snort?

Should I be worried about them and deny the senders?
If there ain't nothing running they can connect to then you shouldn't worry. Denying remote addresses is damn cool. Give me one chance to map your ISP's network, find out your GW addr and some more servers you're bound to connect to and I'll make you DoS yourself :-] Hell no I won't, but you get the idea about unrestricted blocking...

What is your opinion?
You don't want opinions, you're running a business FGS!
You want facts.

Btw, I asked you for a copy of your script (just curious) but I didn't get any reply back. Can I have it? I mean, you already offered posting it...

I would expect it to be mainly portscanners, however I'm sure that there are Windows machines out here broadcasting such traffic. So long as you have nothing listening on that port then you can safely ignore it.

If you are running anything thats listening on 137 then you might want to consider adding some firewall rules to only allowed the clients you want, and configure the software that's listening on 137 to only accept specific clients too if thats possible.

cheers

Jamie...

Learning that there are Windows machines outside broadcasting such packages without any vicious intention, I think I will not block these IP addresses. They do not seem to send packages to any other ports, so they are possibly not scanners.
Besides, they can do no harm: these packages cannot get inside our LAN, they land on our unix server.

You don't want opinions, you're running a business FGS!
The situation is not that hard.
This LAN was build and connected to the internet two years ago by someone else who is still regaded our network administrator.
Ever since we had no firewall, as he did not setup one in those two years. Noone missed it. Even know there is noone else except me who cares about the safety of our LAN. So, I finally decided to setup some kind of firewall. But, you can see, I have time...

Btw, I asked you for a copy of your script (just curious) but I didn't get any reply back. Can I have it? I mean, you already offered posting it...
I know, and I am very grateful for your attention.
However, I still need one or two days to add some essential features. Just an example: I thought that my script need not handle (empty) the tcpdump logfile, this task can be simply delegated to the newsyslog daemon. Now I see that tcpdump no loger uses the logfile if newsyslog emptied it. So I have to add some code to the script.
Besides, I want to have it running for one more day, to see if it breaks anything and what traffic it blocks and what not. Based on that information I can finetune some parameters in the script.

So, I will send it to you on sunday.

I could never imagine, but I got stucked with emptying the tcpdump logfile...
I should ensure that it does not contain data older than 24 hours. I thought the simplest would be to delete and recreate it when it grows older.
You will not believe it: I cannot check if it is older than 24 hours!
It seems that commands like
find /path/to/file -amin -1440
or
find /path -name filename -amin 1440
simply do not work on this unix, even if entered on the command line (unlike in linux where they work fine).
The above commands (and also -cmin) always return the filename, regardless of the value of n. -atime -1 sometimes returns the filename, a minute later not, another minute later it finds it again (meanwhile the file was not deleted or re-created, only tcpdump wrote some data in it).
I google searched the web and found someone reporting a similar bug in 1998. Then again in 2000. It seems that those FreeBSD guys were not very keen to fix it, since I still have it in my release (4.5).
Since find does not work, maybe I could mess with ls, but then I should deal with localisation matters. I could also store the creation date in a separate file, but it would be complicated and not very smart to have a surplus file just to store one single date...

Is there an other easy solution to get the creation date and time of a file?

Hmm. Why not read the first line from the dump and act on that? I mean "tcpdump -tttt" does provide date-time, innit?

You are right, it is a possible solution (still better than the other two).
So far I tried to keep the tcpdump logfile as small as possible. That is why I start tcpdump with the e.g. -q option. The date seemed to be a surplus data, which might slow down grep to find the records of the last two minutes.
However, the script actually runs so fast on this ancient PII 450 server that it finishes in 3 seconds even if the logfile size is near to 100M and the traffic is the heaviest on our 256k line.

Finally I decided to put the date in the first line of the logfile.
It needs a longer code to check it, but still better than being stucked for ten hours on a silly thing like this, while looking for a simple solution that maybe does not exist.