On 12/29/2013 04:00 AM, Dobbins, Roland wrote:
On Dec 29, 2013, at 2:00 AM, MIke <[email protected]> wrote:
Open internet. I don't want to dictate to anyone which port numbers or
protocols they are limited in using, and I want to impose only the absolute
minimum of controls in order to deliver as much of an unfiltered / unrestricted
service as I can.
Causing users to use your recursors by default, plus Open DNS and Google DNS,
and with an opt-out proviso, does not in any way inhibit their ability to
access the Internet, while doing so materially contributes to the security of
your user base.
A default policy exists to deny outbound smtp except to my relays, which
the option to__turn it off for any customer who asks. This stops dead
cold the infected spamming zombies. I don't feel the same about dns
however. Perhaps in the future I would in fact implement something like
that with lots of other filtering and so forth as a value added service.
But back to the main point, the controls I have to deal with this
particular issue are coarse grained and I have a chokepoint in the
network that is - in our system - the right place to do this.
That may be a wonderful design goal in theory, but our 'transit edge' as you
call it, is a pair of linux boxen that do not have any effective interface for
implementing policies or mitigation tools.
In that case, unfortunately, nothing you do is going to matter, anyways, as
even a very small DDoS attack can take those boxes down completely.
Not true. I've seen more than 600mbps of traffic and, while not in the
league of what you see, is still a sizable total of my transit and we
kept chunking along. More than that and there is no filtering / qos /
mitigation I could do on my side which would be effective since the pipe
TO ME would be filled regardless. My upstream doesn't have any blackhole
community or other magic available other than panicked phone call to
their noc. So while we certainly could get blown off the air, theres a
middle ground here where we can fight and remain operational, so thats
what this thread is about really.
Mike-
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/