port scans

They don't. Are all four systems equally visible from the world? Does each one have it's own `world reachable' IP address? Are they all in the same range of IP addresses, in the same facility? Are they all using the same version operating system? Are all of them equally active? Are all of them equally `clean'? Work stations generally don't offer services to the Internet, but if you are offering FTP service to the world, more people know about the server than the non-serving systems. It's something obvious that you aren't thinking about.

Old guy

There is 1 external, non-static IP ==>modem==>router(DMZ)==>SonicWall==>

linux FTP server, windows xp3, windoes xp3.

The latter all use LAN ip addresses of course.

Since any ftp "user" would have to know the secret handshake I am wondering how the chinese and the koreans know about the ftp server!

- just curious

Am Sun, 21 Feb 2010 13:54:13 -0500 schrieb Rick:

They don't they just check for ports in an IP range. btw: get rid of the sonic crap. cheers

If it's on the internet, it's gonna get portscanned and actively attacked a lot. By your countrymen, and the boogeymen overseas.

Depending on how you are providing that ftp server out to the internet (or any other services) will determine how much port scanning you will see. And naturally, your ability to see the port scan requires some sort of software being able to identify a port scan as such.

I have been able to stop "countrymen" attacks by showing them that they have an infected server. But the overseas admins are so flooded that they can do/find nada.

What do you mean by "how you provide"?

I thought it just sat there until someone accessed it. So that must mean that my access is being seen all over the world - is it?

Ok, I'm not seeing "port scans" as much as I am seeing attempted access

- which the Sonicwall stops quite nicely, thank you.

i.e. Is your server plopped into your DMZ by way of sonicwall configuration, or are specific ports forwarded from the external IP to a single or subset of ports on the internal IP of the ftp server?

How you are providing ftp service will affect how port scans will display to you.

Poor choice of subject for the thread then? :-)

Well, then I guess there's no problem then, you're welcome. :-)

More constructively, though the upshod here is that access attempts and port scans should be quite expected on any internet facing IP address.

What's not clear to me, though, is whether that explains what you're seeing in your logs adequately. Your question never mentioned whether the FTP server was the only externally facing service you were providing, for instance.

The FTP service IS the only service provided. However, I do see occasional attempts to access http!

Here are a few selected LOG samples:

02/19/2010 13:11:13.320 - Notice - Network Access - TCP connection dropped - 221.195.73.86, 12200, X1 - 192.168.1.205, 7212, X1 - TCP Port: 7212

02/19/2010 14:28:37.576 - Notice - Network Access - TCP connection dropped - 209.62.68.168, 80, X1 - 192.168.248.207, 4285, X0 - TCP iMesh

02/19/2010 17:13:50.576 - Notice - Network Access - UDP packet dropped - 222.37.37.33, 1186, X1 - 192.168.1.205, 1434, X1 - UDP Port: 1434

02/19/2010 17:18:44.848 - Notice - Network Access - UDP packet dropped - 218.30.22.82, 1122, X1 - 192.168.1.205, 1434, X1 - UDP Port: 1434

02/20/2010 00:44:48.144 - Notice - Network Access - Web access request dropped - 218.240.36.7, 30518, X1 - 192.168.1.205, 80, X1 - TCP HTTP

02/20/2010 01:37:28.624 - Notice - Network Access - TCP connection dropped - 218.66.104.146, 22, X1 - 192.168.1.205, 22, X1 - TCP SSH

02/20/2010 02:25:25.752 - Notice - Network Access - UDP packet dropped - 61.160.234.5, 1155, X1 - 192.168.1.205, 1434, X1 - UDP Port:

note that

192.168.1.205 is the address of the sonicwall from the router and is not the LAN address of the ftp server.

One external address -> several systems. How is the SonicWall told to route packets. Send them equally to all systems? Of course not. Obviously it's not going to send packets for port 20-21/ftp to the workstations, because that's not where the FTP server is. So look at the way you've configured the SonicWall.

So it's all the SonicWall that's deciding how to route packets.

Unlikely that they do - they're scanning the entire external IP range - perhaps as widely as 1.0.0.1 to 222.255.255.254 looking to see "what is there". Linux server - do you have nmap installed? The man page is extensive, and there's probably a lot more documentation in /usr/share/nmap*/. They scan your address - let's say it's 192.0.2.11 on the external side, and your SonicWall forwards those packets to....

Do you intend to offer FTP service to every IP address in the world, or are you only intending to offer to North America, Pennsylvania, or New York City? IP addresses are not allocated/assigned in a simple manner arranged for convenient filtering. For example, the IPv4 address range 130.0.0.0 - 130.255.255.255 is allocated/assigned to 228 networks in ten countries from New Zealand and Japan through Europe (Denmark and France) to North America (Canada and USA). See

for regional clues. As of the 15th, there were 3007 million IPv4 addresses in 228 countries in 100341 IP blocks.

Old guy

Nope, the Sonicwall LOG FILE says that those packets have been DROPPED (unceremoniously I presume).

To get past the sonicwall you have to have the password (global vpn client) or the "secret" for the SSL tunnel (I think that's what it's called.).

This shouldn't be overly surprising, though.

This one's a little unique, but you're not alone.

You're in an elite group of about 60,000-84000 or so hosts per day that reported something trying this port recently:

Quite possibly just a probe or slow port scan looking for a web server. Everyone loves web servers.

Quite possibly just a probe or a slow port scan looking for an ssh server to try to brute force.

I see nothing at all unusual here for an internet connected IP. Your firewall is simply doing its job, and denying traffic you haven't allowed by policy.

I agree utterly with your assessment.

Are you saying that they are checking EVERY POSSIBLE IP number?

That should take a pretty LONG TIME, yet here they are back-again the next day:

02/19/2010 59:05.5 " TCP" " 125.65.112.161," snipped-for-privacy@mail.sc.cninfo.net 12200, X1 - " 192.168.1.205," 8000, X1 - " TCP" Port: 8000 02/20/2010 06:30.2 " TCP" " 125.65.112.161," snipped-for-privacy@mail.sc.cninfo.net 12200, X1 - " 192.168.1.205," 7212, X1 - " TCP" Port: 7212 02/20/2010 23:03.2 " TCP" " 125.65.112.161," snipped-for-privacy@mail.sc.cninfo.net 12200, X1 - " 192.168.1.205," 7212, X1 - " TCP" Port: 7212 02/20/2010 55:58.8 " TCP" " 125.65.112.161," snipped-for-privacy@mail.sc.cninfo.net 12200, X1 - " 192.168.1.205," 7212, X1 - " TCP" Port: 7212 4 failed attempts from the same originator. I can only see explaining that by assuming that they somehow KNOW my server is there. How do they know it is there? Would it help to get a new IP address?

That's what I'm trying to indicate. If you didn't set the SonicWall to forward this crap somewhere, what is it supposed to do? The only thing it _can_ do is drop or reject the packet. This happens all the time. No big deal at all. Even if it forwarded the crap to one of your systems _by_default_ (which it shouldn't), if there's nothing listening on the destination box, there is nothing that is going to happen except that the destination box may reject/drop the packet. So?

You've got to have it configured to forward stuff _somewhere_ As mentioned in the other response, these consumer grade firewalls are next to useless, but try to appear useful. The CPU cycles and disk space it's wasting producing those scary messages are why they aren't used in serious installs.

Old guy

The usual problem is the idiots who build these consumer grade firewalls want to prove that they're doing something, even if it has no effect or is totally unnecessary.

Well then even WITHOUT the firewall, nothing is going to happen. If there is no server listening, the network stack is going to reply "your call did not go through..." From one of your windoze boxes, try to connect to the other using... I dunno - telnet.

[compton ~]$ telnet spitzer Trying 192.168.1.62... telnet: Unable to connect to remote host: Connection refused [compton ~]$

You will get the same result - "connection refused" because neither your windoze boxes or the Linux box are running a telnet server. You don't need a toy firewall to stop what isn't going to happen.

Oh, Brave Firewall!! Well Done!!! Now why is it bothering you with meaningless noise like this? It did it's job, now does it also expect you to pat it on the ass or give it a piece of candy?

Chinese drone controller trying to access a bot which isn't installed on your system. Firewall served no useful purpose. Last time I bothered logging this crap, I saw the same handful of hosts trying to connect about six times per hour, mainly late afternoon to mid evening - when they expect infected boxes to be turned on.

Dropping a connection your system initiated to a remote web server

[compton ~]$ host 209.62.68.168 168.68.62.209.IN-ADDR.ARPA domain name pointer superantispyware.com [compton ~]$

Sounds like the usual windoze snake-oil crap. I don't run windoze, so I've no use for such a site.

Someone trying to find a windoze SQL box

More noise. I'd kick the SonicWall in the nuts to get it to stop bothering me with noise. It dropped a packet that couldn't go to a destination - so what. My firewall (in the physical location of your SonicWall) is what's left of a 386SX-16 laptop (no display, no keyboard, in a cardboard box) running a minimal Linux. It does it's job, and I rarely bother enabling logging because it serves no useful purpose. I have a public IP that's visible - and every skript kiddie and bot tries to connect to that address, but I'm not running a server, so there is nothing to accept the connections. The 386 only has a 345 Meg hard drive, so it really doesn't have space to waste on meaningless noise logs.

Old guy

Regis wrote in news: snipped-for-privacy@e6g2000prf.googlegroups.com:

Even to the level of the ordinary home user logging in to their ISP on a dialup modem.

I recall watching my software firewall back in those days routinely blocking occasional port scans.

Brian

Not necessarily. Maybe. Probably. Depends on who's doing the scanning. Could be some other subscriber on your ISP scanning from afar out of curiosity, could be an attacker mapping out known registered DHCP pools from your ISP, or all ISP's. The bot herders are just looking for targets, and a lot of it may be automated scans done by other malware. You never know.

Not as long as you might think, and with so many computers, attackers and enterprising blackhats with botnets to distribute the work, it's doable.

Do not ascribe to directed malice that which can be more adequately explained by the usual, happens every day to everybody large scale reconnaissance.

Sam Spade says that is definitely not the case.

Checking the attacker ip shows that is not the case either. I certainly agree that it COULD be, and one time it was and believe-it-or-not I actually got them to fix their vampired server.

Yes, I know, but I think we should institute our own Fire-Back Bot Herd!

One assumes that IP6 will make such work more difficult!

Actually, I did not say 'malice' although it's fair for you to assume it

- they might just be curious, as I am, about what's out there.

I have 32 IP addresses and a Commercial Grade firewall on our network. We see about 8000 attempts per day across those IP's - it's almost always a range of ports they scan from the same IP - the ones I consider the largest threat are the ones that scan 5-10 ports every day, slowly, so that they are harder to detect if you're not sure what you're looking for.

Do I worry about them - not much, but I have about 60 IP subnets in our permanent block list (mostly outside the USA).

Have you seen one of these, and what might it mean?

02/21/2010 00:05:40.608 - Notice - Network Access - UDP packet dropped - 192.168.1.70, 5353, X1 - 224.0.0.251, 5353 - UDP Apple Bonjour 02/21/2010 00:06:44.608 - Notice - Network Access - UDP packet dropped - 192.168.1.70, 5353, X1 - 224.0.0.251, 5353 - UDP Apple Bonjour

Sam Spade says 224.... is reserved...