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

| Subject: | Re: Source port 445,80 |
|---|---|
| Date: | Thu, 06 Sep 2007 12:55:49 -0400 |
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....
pgp9wFwK5tsou.pgp
Description: PGP signature
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Source port 445,80, Valdis . Kletnieks |
|---|---|
| Next by Date: | RE: Source port 445,80, Wong Yu Liang |
| Previous by Thread: | RE: Source port 445,80, Wong Yu Liang |
| Next by Thread: | RE: Source port 445,80, Wong Yu Liang |
| Indexes: | [Date] [Thread] [Top] [All Lists] |