Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

RE: Source port 445,80

Subject: RE: Source port 445,80
Date: Fri, 7 Sep 2007 09:05:50 +0800


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
--------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>