popularity-contest

[Tony Arnold]

Jeffrey,

On Thu, 2007-03-29 at 20:54 -0400, Jeffrey F. Bloss wrote:

> > Good question. The SYN ACK packet is a response to an initial SYN packet
> > sent from your machine when trying to make a connection to a remote
> > system. So the only time you would be interested in such packets is if a
> > SYN ACK arrived when no corresponding SYN packet had been sent. I'm not
> > aware of any attack vectors that do this at the moment and can't see
> > what such an attack would achieve. So yes, I think you can safely ignore
> > such messages.
> 
> One of the things such an attack can achieve is clogging up pipes
> in what's sometimes called a "distributed reflection" attack. And as far
> as current events goes, I'm pretty sure Cisco still has open tickets for
> the last "crashes your router" vulnerability of this general type
> discovered in some/most of their firmware. Could be wrong about the
> time line, I don't keep up with those things like I use to.

OK, that applies to Cisco routers and presumably requires a large number
of such packets to cause a problem. It's not clear to me that such a
vulnerability exists in Ubuntu.

> Network scanners like nmap also use SYN/ACK packets to "camouflage"
> their activity and circumvent certain obstacles.
> 
> I don't think the activity described in this sub-thread is nefarious
> necessarily, but unsolicited SYN/ACK packets should *never* be ignored.
> That would be a blatant contradiction to the very reason stateful
> firewalls exist in the first place.

Agreed.

> At the least this should be considered "broken behavior". You should
> nail down the specific firewall rule that's generating the error and
> fix it, contact the owner of the broken equipment at the other end of
> the pipe and have them do some of their own housekeeping, and/or give a
> little attention to the issue to rule out the possibility it's not just
> the "tip of the ice berg"... that it's not the coincidentally
> detectable portion of a larger collection of odd packets.

And if none of that is feasible or practical, I still think the OP could
safely ignore these log messages.

Regards,
Tony.
-- 
Tony Arnold, IT Security Coordinator, University of Manchester,
IT Services Division, Kilburn Building, Oxford Road, Manchester M13 9PL.
T: +44 (0)161 275 6093, F: +44 (0)870 136 1004, M: +44 (0)773 330 0039
E: tony.arnold at manchester.ac.uk, H: http://www.man.ac.uk/Tony.Arnold