|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
Vadim - the instant someone sues a Provider for sexual harassment from their spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long, and in fact the problem is that they are not sane providers. What they are, and this is pretty much true across the board, is people that just don't care what they do to earn a buck otherwise we would not have these problems, and this is especially true of those Network Operators that push all those billions of bytes of illicit SPAM and throw their hands up and say "What do you expect us to do" - well the answer is simple. I expect you folks to operate within the law and to cooperate in stopping people who use your services in violation of the laws. And if the providers out there don't like that - then they should find other businesses. Todd Glassey ----- Original Message ----- From: "Vadim Antonov" <[email protected]> To: "Avleen Vig" <[email protected]> Cc: <[email protected]> Sent: Monday, January 20, 2003 7:59 PM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks? > > > On Mon, 20 Jan 2003, Avleen Vig wrote: > > > > > On Mon, 20 Jan 2003, Christopher L. Morrow wrote: > > > > > > I was refering specifically to end user workstations. For example home > > > > machines on dial up or broadband connections. > > > > A lot of broadband providers already prohibit running servers and block > > > > certain inbound ports (eg 21 and 80). > > > > *shrug* just seems like it would make more sense to block all incoming > > > > 'syn' packets. > > > > > Indeed it does break that. P2P clients: Mostly transfer illegal content. > > As much as a lot of people love using these, I'm sure most realise they're > > on borrowed time in their current state. > > Well, blocking TCP SYNs is not a way to block establishment of sessions > between _cooperating_ hosts. > > Simply make a small hack in TCP stack to leave SYN flag clear, and use > some other bit instead. > > To really block something you need an application proxy... and then there > are always ways to subvert those. Elimination of covert channels is one of > the hardest problems. In any case, no sane provider will restrict traffic > only to applications which can be served by its proxies. > > Going further, the growing awareness of the importance of security will > cause more and more legitimate apps to create totally indiscriminate > encrypted traffic... and it is a good idea to routinely encrypt all > traffic, to avoid revealing importance of particular communications. > Leaving identity of applications (different port #s) in the clear is also > a bad idea, security-wise. > > --vadim >
|