Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Interesting port-scanning attack--anyone seen this?

Status
Not open for further replies.

jmkelly

IS-IT--Management
May 14, 2002
25
US
Don't know how common this is, but my guess is pretty darn common:
A sysadmin reported an intrusion on a fairly well-protected server--it has a private IP address, and no static NAT, so theoretically it would be very difficult for anyone to access it from outside our network. But there was a reported intrusion from 162.244.33.104 (morrisgraves.clientshostname.com). Firewall logs showed lines like these:

6/25/2015 00:25 ... src_ip=162.244.33.104, src_port=80, dst_ip=[our.external.IP.addr], dst_port=62391 ... pckt_len=40, ttl=53
6/25/2015 00:32 ... src_ip=162.244.33.104, src_port=80, dst_ip=[our.external.IP.addr], dst_port=65172 ... pckt_len=40, ttl=52
6/25/2015 00:39 ... src_ip=162.244.33.104, src_port=80, dst_ip=[our.external.IP.addr], dst_port=51802 ... pckt_len=40, ttl=52

That is, many packets from the same host's port 80 (http) to our public IP address + random high-value ports: i.e., to address+port combinations that might, with luck, be identical to existing dynamic NATs of hosts running web browsers. Of course, if you just keep trying, you don't need much luck--eventually you'll hit a working dynamic NAT and your packet will be forwarded right to a host inside the network.
It's simple but kind of slick. My guess is if one of those 40-byte packets gets to a host with the right Trojan running on it, all kinds of fun ensues.
Has anyone else seen this?
 
I think as long as your firewall is properly configured you don't have to worry too much. Since the only thing visible to the outside is your external IP, only the ports you have configured in your firewall via port forwarding will have a chance of anything coming through to the internal servers / workstations. So they only ports you have to worry about are the ones that are naturally open and the forwarded ones.

Please anyone correct me if what I said is wrong. I'm not specialised in IT.

"Knowledge is power. Information is liberating. Education is the premise of progress, in every society, in every family." (Kofi Annan)
Oppose SOPA, PIPA, ACTA; measures to curb freedom of information under whatever name whatsoever.
 
where do those log entries come from? From the looks of it my interpretation would be: these are return traffic to your internal host which accessed (initiated the connections to) the web server at 162.244.33.104. Hence the random high destination ports.
 
iggsterman,
These log entries come from one of our firewalls. They look like HTTP return traffic because that's what they're supposed to look like. Odds are against them fooling the firewall: most of the time, the destination IPaddress:port combination will not correspond to one actually in use, and even when it does the tcp sequence number will almost always be wrong. But every now and then the intruder's going to hit the jackpot, get through, and establish a toehold inside the target net.
Thing is, if you point your browser at 162.244.33.104:80, you get nothing. People browse some pretty silly sites, but generally not sites that give them absolutely nothing. (The guy who runs it would have been smart to put up some cat pictures or something.) The box is spitting out packets crafted to look like http return traffic in hope of getting them forwarded to some host inside the network, I guess because the guy who runs it isn't smart enough to embed them in Flash videos.
The IP supernet involved turns out to be owned by king-servers.net. I contacted their abuse address and got a "we're addressing that" reply. The network seems to comprise mostly porn sites and shareware sites, so I blocked the whole thing. Nothing against porn or shareware, but our network users don't need access to either.
 
You may be right. I have seen this behavior before. Good you caught it. I'd "shun" the the entire IP block.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top