RE: Source port 445,80

["Wong Yu Liang" <wong.yuliang () vads com>]

Thanks valdis, 
 That makes a lot of sense. 172.16.1.254 is a sever with a lot of
critical 
Services running so it's a bit hard to troubleshoot. But of course these
are not the real IPs :p. Thanks again 

-----Original Message-----
From: Valdis.Kletnieks () vt edu [mailto:Valdis.Kletnieks () vt edu] 
Sent: Friday, September 07, 2007 12:56 AM
To: Wong Yu Liang
Cc: incidents () securityfocus com
Subject: Re: Source port 445,80

On Thu, 06 Sep 2007 12:17:47 +0800, Wong Yu Liang said:
> Thanks valdis=20
>  I suspected so. Possibly a worm propagation and the ips detected the
> *return* traffic. But yet the alerts from my ips is very strange. Some
> alerts
>
> 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
> 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
> And the list goes on to different destination IP addres

OK, that's a *different* well-known pattern - as mssql in fact lives on
1434.

What the attacker is doing is using a hand-set source port of 80, to get
through
those older firewalls that don't do stateful connection tracking.

Newer firewalls will watch the traffic, and if they see a TCP SYN packet
going
*out* to a given port/IP pair, will automagically whitelist the return
path,
so the SYN/ACK packet makes it back, but traffic from *other* sites
still
won't be able to enter inbound.

Older non-stateful firewalls would simply be configured with two rules:
allow outbound to port 80
allow inbound from port 80
so you could talk to webservers.  So some hacking tools abuse the
existence
of such rules to improve their chances of getting in through the
firewall...

Incidentally, this sort of thing is hard to troubleshoot when both
addresses
are in the 172.16/12 address block, that's an RFC1918 reserved space.
So
either the source is inside your own network, or you need to go look at
whatever
is doing your NAT at the border and get it to cough up the *real* IP
address
of the source....


-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics

ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
It's as simple as placing additional SQL commands into a Web Form input box
giving hackers complete access to all your backend systems! Firewalls and IDS
will not stop such attacks because SQL Injections are NOT seen as intruders.
Download this *FREE* white paper from SPI Dynamics for a complete guide to protection!

https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------