Mailing List Archive

DNS deluge for x.p.ctrc.cc
We have recently noticed a deluge of DNS requests for "ANY ANY" records
of x.p.ctrc.cc. The requests are coming from thousands of sources,
mostly our own customers. There are currently no records for
x.p.ctrc.cc, or even for p.ctrc.cc. A google search for x.p.ctrc.cc
comes up with only 2 hits. One is a DNS log showing references to this
name. The other one shows that somebody else is seeing the same behavior
as we are:



http://weblog.barnet.com.au/edwin/cat_networking.html



However, this site has the benefit or providing a history that p.ctrc.cc
had (a week ago) delegated NS record pointing to 321blowjob.com. At that
time, 321blowjob.com's nameserver was responding with a TXT record for
x.p.ctrc.cc.



It would appear that ctrc.cc was the victim of some DNS hijacking.
Whatever malware is attempting to lookup this name, however, is doing so
at a horrific rate. I have some addresses that have made >250000
requests for this name in a short period of time.



I was thinking that I could simply put an authoritative zone for
p.ctrc.cc in our nameservers and return something for the lookups,
however based on the writeup on the above mentions blog, I am now not
certain this will have any effect. As you'll note, that individual had
only 2 machines hitting his name server, and even though a response was
provided to the lookup, the hosts continued to hammer his access link.



When the lookup flood occurs, every host starts at the same time, as can
be seen on the graphs of traffic to and load of our nameservers. It's
all or nothing - the flood is either on or off. There's no background
trickle.



Is anybody else seeing these events?



--Paul
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
other cctld servers have seen what are effectively ddos. rob thomas
seems to have the most clue on this, so i hope this troll will entice
him to speak.

randy
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On Fri, 24 Feb 2006, Estes, Paul wrote:

> We have recently noticed a deluge of DNS requests for "ANY ANY" records

They are trying to abuse similar holes that caused most of us add
"no ip redirects" and "no ip directed broadcast" to routers, but this
time its about dns

> of x.p.ctrc.cc. The requests are coming from thousands of sources,
> mostly our own customers.

Why am I not surprised ....

> There are currently no records for x.p.ctrc.cc, or even for p.ctrc.cc.

http://www.completewhois.com/cgi-bin/whois.cgi?query=28242102&options=retrieve

I don't think this is a hacker-setup domain, probably their dns servers
were at some point hacked. They are associated with legacy ip block
192.238.16.0/21. It is also notable that CTRC.CC A record points to
192.168.202.72

> A google search for x.p.ctrc.cc
> comes up with only 2 hits. One is a DNS log showing references to this
> name. The other one shows that somebody else is seeing the same behavior
> as we are:
>
> http://weblog.barnet.com.au/edwin/cat_networking.html
>
> However, this site has the benefit or providing a history that p.ctrc.cc
> had (a week ago) delegated NS record pointing to 321blowjob.com. At that
> time, 321blowjob.com's nameserver was responding with a TXT record for
> x.p.ctrc.cc.

> It would appear that ctrc.cc was the victim of some DNS hijacking.
> Whatever malware is attempting to lookup this name, however, is doing so
> at a horrific rate. I have some addresses that have made >250000
> requests for this name in a short period of time.
>
> I was thinking that I could simply put an authoritative zone for
> p.ctrc.cc in our nameservers and return something for the lookups

You might want to consider returning the same thing in lookups as ctrc.cc
themselves have for direct A lookups...
,
> however based on the writeup on the above mentions blog, I am now not
> certain this will have any effect. As you'll note, that individual had
> only 2 machines hitting his name server, and even though a response was
> provided to the lookup, the hosts continued to hammer his access link.
>
> When the lookup flood occurs, every host starts at the same time, as can
> be seen on the graphs of traffic to and load of our nameservers. It's
> all or nothing - the flood is either on or off. There's no background
> trickle.
>
> Is anybody else seeing these events?
>
> --Paul
RE: DNS deluge for x.p.ctrc.cc [ In reply to ]
Actually, what we are seeing does not appear to be an amplification
attack. It appears to be a request flood from infected machines.

We have anti-spoofing filters on our upstream connections as well as our
subscriber's access lines. The source addresses are not spoofed. They
are valid subscriber source IP's.

Based on some cached entries I have found in other nameservers, CTRC.CC
was apparently hacked and was delegating a number of subdomains to
another nameserver that was issuing the 4K TXT record. The delegation
has now been removed, and the nameserver they were delegated to appears
to be offline.

--Paul

-----Original Message-----
From: william(at)elan.net [mailto:william@elan.net]
Sent: Friday, February 24, 2006 9:47 AM
To: Estes, Paul
Cc: nanog@merit.edu
Subject: Re: DNS deluge for x.p.ctrc.cc


On Fri, 24 Feb 2006, Estes, Paul wrote:

> We have recently noticed a deluge of DNS requests for "ANY ANY"
records

They are trying to abuse similar holes that caused most of us add
"no ip redirects" and "no ip directed broadcast" to routers, but this
time its about dns

> of x.p.ctrc.cc. The requests are coming from thousands of sources,
> mostly our own customers.

Why am I not surprised ....

> There are currently no records for x.p.ctrc.cc, or even for p.ctrc.cc.

http://www.completewhois.com/cgi-bin/whois.cgi?query=28242102&options=re
trieve

I don't think this is a hacker-setup domain, probably their dns servers
were at some point hacked. They are associated with legacy ip block
192.238.16.0/21. It is also notable that CTRC.CC A record points to
192.168.202.72

> A google search for x.p.ctrc.cc
> comes up with only 2 hits. One is a DNS log showing references to this
> name. The other one shows that somebody else is seeing the same
behavior
> as we are:
>
> http://weblog.barnet.com.au/edwin/cat_networking.html
>
> However, this site has the benefit or providing a history that
p.ctrc.cc
> had (a week ago) delegated NS record pointing to 321blowjob.com. At
that
> time, 321blowjob.com's nameserver was responding with a TXT record for
> x.p.ctrc.cc.

> It would appear that ctrc.cc was the victim of some DNS hijacking.
> Whatever malware is attempting to lookup this name, however, is doing
so
> at a horrific rate. I have some addresses that have made >250000
> requests for this name in a short period of time.
>
> I was thinking that I could simply put an authoritative zone for
> p.ctrc.cc in our nameservers and return something for the lookups

You might want to consider returning the same thing in lookups as
ctrc.cc
themselves have for direct A lookups...
,

[snip]
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
Estes, Paul wrote:
> Actually, what we are seeing does not appear to be an amplification
> attack. It appears to be a request flood from infected machines.
>
> We have anti-spoofing filters on our upstream connections as well as our
> subscriber's access lines. The source addresses are not spoofed. They
> are valid subscriber source IP's.
>
> Based on some cached entries I have found in other nameservers, CTRC.CC
> was apparently hacked and was delegating a number of subdomains to
> another nameserver that was issuing the 4K TXT record. The delegation
> has now been removed, and the nameserver they were delegated to appears
> to be offline.

Do they all happen to be connecting to one outside IP address? :)
RE: DNS deluge for x.p.ctrc.cc [ In reply to ]
It may be coincidental, but TXT and ANY queries for this
zone were the ones used in the multi-gigabit reflected dns
DDOS against us earlier this month.

Ejay Hire
ISDN-Net Network Engineer

> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]
On
> Behalf Of Estes, Paul
> Sent: Friday, February 24, 2006 11:26 AM
> To: nanog@merit.edu
> Subject: DNS deluge for x.p.ctrc.cc
>
> We have recently noticed a deluge of DNS requests for "ANY

> ANY" records of x.p.ctrc.cc. The requests are coming from
> thousands of sources, mostly our own customers. There are
> currently no records for x.p.ctrc.cc, or even for
p.ctrc.cc.
> A google search for x.p.ctrc.cc comes up with only 2 hits.

> One is a DNS log showing references to this name. The
other
> one shows that somebody else is seeing the same behavior
as we are:
>
>
>
> http://weblog.barnet.com.au/edwin/cat_networking.html
>
>
>
> However, this site has the benefit or providing a history
> that p.ctrc.cc had (a week ago) delegated NS record
pointing
> to 321blowjob.com. At that time, 321blowjob.com's
nameserver
> was responding with a TXT record for x.p.ctrc.cc.
>
>
>
> It would appear that ctrc.cc was the victim of some DNS
> hijacking. Whatever malware is attempting to lookup this
> name, however, is doing so at a horrific rate. I have some

> addresses that have made >250000 requests for this name in
a
> short period of time.
>
>
>
> I was thinking that I could simply put an authoritative
zone
> for p.ctrc.cc in our nameservers and return something for
the
> lookups, however based on the writeup on the above
mentions
> blog, I am now not certain this will have any effect. As
> you'll note, that individual had only 2 machines hitting
his
> name server, and even though a response was provided to
the
> lookup, the hosts continued to hammer his access link.
>
>
>
> When the lookup flood occurs, every host starts at the
same
> time, as can be seen on the graphs of traffic to and load
of
> our nameservers. It's all or nothing - the flood is either
on
> or off. There's no background trickle.
>
>
>
> Is anybody else seeing these events?
>
>
>
> --Paul
>
>
>
>
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On Feb 24, 2006, at 11:30 AM, Ejay Hire wrote:

>
> It may be coincidental, but TXT and ANY queries for this
> zone were the ones used in the multi-gigabit reflected dns
> DDOS against us earlier this month.

this would be a fine thread to discuss on dns-operations, which a
bunch of you here have already joined.

list details here if not already subscribed:

http://lists.oarci.net/mailman/listinfo/

-b
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
> this would be a fine thread to discuss on dns-operations, which a
> bunch of you here have already joined.
> http://lists.oarci.net/mailman/listinfo/

i joined but have never seen a message on that list. and this
discussion seems useful. maybe we should not do a gadi?

randy
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
Randy Bush wrote:
>>this would be a fine thread to discuss on dns-operations, which a
>>bunch of you here have already joined.
>>http://lists.oarci.net/mailman/listinfo/
>
>
> i joined but have never seen a message on that list. and this
> discussion seems useful. maybe we should not do a gadi?
>
> randy
>

Or a Randy. Oops, you just did.
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On Feb 24, 2006, at 11:47 AM, Randy Bush wrote:

>> this would be a fine thread to discuss on dns-operations, which a
>> bunch of you here have already joined.
>> http://lists.oarci.net/mailman/listinfo/
>
> i joined but have never seen a message on that list. and this
> discussion seems useful. maybe we should not do a gadi?

just a suggestion, but:

http://lists.oarci.net/pipermail/dns-operations/2006-February/
000005.html

there has been one topical post (ignore a handful of test messages).

-b
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
Hi, NANOGers.

] other cctld servers have seen what are effectively ddos. rob thomas
] seems to have the most clue on this, so i hope this troll will entice
] him to speak.

Did someone say "troll?" :)

Yes, this is a real problem. These attacks have exceeded several
gigabits per second in size, and during one attack 122K DNS name
servers were abused as amplifiers. Ouch!

This abuse can be mitigated. Here are a few tips.

Limit recursion to trusted netblocks and customers. Do not permit
your name servers to provide recursion for the world. If you do,
you will contribute to one of these attacks.

Watch for queries to your name servers that ask for "ANY" related
to a DNS RR outside of the zones for which you are authoritative.
This DNS RR will be LARGE.

Limit UDP queries to 512 bytes. This greatly decreases the
amplification affect, though it doesn't stop it.

Scan your IP space for name servers that permit recursive queries.
It's amazing just how many of these name servers exist.

Refer to the following guides for some excellent insight and
suggestions.

<http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf>
<http://cc.uoregon.edu/cnews/winter2006/recursive.htm>
<http://dns.measurement-factory.com/surveys/sum1.html>

Note we have our own Secure BIND Template which will help on the
BIND side of life.

<http://www.cymru.com/Documents/secure-bind-template.html>

If you need assistance with any of this, have endured one of these
attacks, or have any other questions, please don't hesitate to ping
on us at team-cymru@cymru.com. We're here to assist!

Thanks!
Rob.
--
Rob Thomas
Team Cymru
http://www.cymru.com/
ASSERT(coffee != empty);
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
> Note we have our own Secure BIND Template which will help on the
> BIND side of life.
>
> <http://www.cymru.com/Documents/secure-bind-template.html>
>
> If you need assistance with any of this, have endured one of these
> attacks, or have any other questions, please don't hesitate to ping
> on us at team-cymru@cymru.com. We're here to assist!

... and if you have used the Secure BIND Template in the past but
perhaps haven't perused it lately, please take this opportunity to
examine the change log helpfully supplied at the top of the page. In
particular, some prefixes have been removed from the Secure BIND
Template's embedded bogon list; if you don't keep that information
current on authoritative nameservers, you'll ignore requests from
caching nameservers in FORMER bogon-list space that is now VALID
space.

Remember - bogon lists aren't just for routers, and must be kept up to
date.

Stephen
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
Once upon a time, Rob Thomas <robt@cymru.com> said:
> Limit recursion to trusted netblocks and customers. Do not permit
> your name servers to provide recursion for the world. If you do,
> you will contribute to one of these attacks.

One thing to note: we've discovered that on some common DSL routers, the
internal DNS caching server is on by default and answers requests on the
outside IP address. IIRC some even do it when configured for NAT.

So, even when you disable outside recursion, things you may not think of
on the inside of your network may still allow outside DNS recursion.

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
> ] other cctld servers have seen what are effectively ddos. rob thomas
> ] seems to have the most clue on this, so i hope this troll will entice
> ] him to speak.
>
> Did someone say "troll?" :)
>
> Yes, this is a real problem. These attacks have exceeded several
> gigabits per second in size, and during one attack 122K DNS name
> servers were abused as amplifiers. Ouch!
>
> This abuse can be mitigated. Here are a few tips.

<there has -GOT- to be a better name for this>

> Limit recursion to trusted netblocks and customers. Do not permit
> your name servers to provide recursion for the world. If you do,
> you will contribute to one of these attacks.

<recursion is a fundamental DNS design feature,
restricting it to "walled gardens" cripples its usefullness>

> Watch for queries to your name servers that ask for "ANY" related
> to a DNS RR outside of the zones for which you are authoritative.
> This DNS RR will be LARGE.

<a valid concern, w/ the following caveat: LARGE, relative
to current traffic>

> Limit UDP queries to 512 bytes. This greatly decreases the
> amplification affect, though it doesn't stop it.

<limiting UDP to 512 has other, unwanted effects,
edns0 for one... crippling ENUM, DNSSEC, IPv6, etc...
is this really what is wanted?>

> Scan your IP space for name servers that permit recursive queries.
> It's amazing just how many of these name servers exist.

<yup... again, a feature that has made the DNS as useful as
it has become>
>
> Refer to the following guides for some excellent insight and
> suggestions.
>
> <http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf>
> <http://cc.uoregon.edu/cnews/winter2006/recursive.htm>
> <http://dns.measurement-factory.com/surveys/sum1.html>
>
> Note we have our own Secure BIND Template which will help on the
> BIND side of life.
>
> <http://www.cymru.com/Documents/secure-bind-template.html>
>
> If you need assistance with any of this, have endured one of these
> attacks, or have any other questions, please don't hesitate to ping
> on us at team-cymru@cymru.com. We're here to assist!
>
> Thanks!
> Rob.
> --
> Rob Thomas
> Team Cymru
> http://www.cymru.com/
> ASSERT(coffee != empty);

ok, so i'm being a bit of a curmudgion here but just how,
if we throttle DNS to the minimum suite for todays services,
can we be expected to add new features/services? grump grump grump...

-- (grumpy) bill
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
bmanning@vacation.karoshi.com wrote:
>> Limit recursion to trusted netblocks and customers. Do not permit
>> your name servers to provide recursion for the world. If you do,
>> you will contribute to one of these attacks.
>>
>
> <recursion is a fundamental DNS design feature,
> restricting it to "walled gardens" cripples its usefullness>
>
>
I don't really think that preventing every Tom, Dick, and Harry from
using my nameserver to look up domains I'm not authoritative for is
going to cripple DNS. They really should have their own severs that do
that for them, or they should use the ones provided to them by their ISP.
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
In message <Pine.GSO.4.62.0602241629470.21514@qentba.nf23028.arg>, Rob Thomas w
rites:
>

>Limit UDP queries to 512 bytes. This greatly decreases the
>amplification affect, though it doesn't stop it.
>

Unfortunately, the intention of the DNS developers is just the
opposite. Things like DNSSEC require larger packet sizes; in fact,
there's a DNS extension (EDNS0) whose purpose, among others, it to
permit this.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
Hey, Bill.

As many say, you own your network, and are free to run it as you see
fit. :) That said, please be aware that if you leave your name
servers open to recursive query requests from any source, you WILL
unwittingly help to amplify these attacks. It's the same as ICMP
directed broadcast and the like.

I don't like it. You don't like it. The miscreants love it. It's
always a balancing act.

Thanks,
Rob.
--
Rob Thomas
Team Cymru
http://www.cymru.com/
ASSERT(coffee != empty);
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On Sat, Feb 25, 2006 at 08:41:01AM +0000, bmanning@vacation.karoshi.com wrote:
> robt wrote:
[snip]
> > Limit recursion to trusted netblocks and customers. Do not permit
> > your name servers to provide recursion for the world. If you do,
> > you will contribute to one of these attacks.
>
> <recursion is a fundamental DNS design feature,
> restricting it to "walled gardens" cripples its usefullness>

The bad guys abused open SMTP relaying and we couldn't use it anymore.*
They've moved to the next thing that is widely open and will be abusable
for a long time while some folks clamp down quickly, others argue against
it, etc. Until we can factor out the bad guys, the diminishing returns
on playing whack-a-mole will force us all to install more functional
equivalent of signs saying "restrooms are for customers only". And no
I don't like it either.

Cheers,

Joe

* well, except those who wish to be marginalized.

--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On Fri, 24 Feb 2006, Chris Adams wrote:

> One thing to note: we've discovered that on some common DSL routers, the
> internal DNS caching server is on by default and answers requests on the
> outside IP address. IIRC some even do it when configured for NAT.
>
> So, even when you disable outside recursion, things you may not think of
> on the inside of your network may still allow outside DNS recursion.

Efficient Networks DSL routers suffer from this problem if DNS servers are
defined in the DHCP server config on the router. It's more of a DNS proxy
though. It doesn't do any caching.

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
> As many say, you own your network, and are free to run it as you see
> fit. :) That said, please be aware that if you leave your name
> servers open to recursive query requests from any source, you WILL
> unwittingly help to amplify these attacks.

and there is discussion on treating this similarly to how open
smtp relays are treated today.

randy
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
I've taken the liberty of following up on this thread on a different
mailing list (dns-operations@lists.oarci.net), since I'd like to explore
it at a depth and breadth that would seem overly obsessive on a general
purpose ops list like nanog. <http://lists.oarci.net/mailman/listinfo/>
is the entry point if you aren't subscribed and want to be. (There are
about 50 folks on that list, which I'm calling "critical mass" for the
purpose of starting the first real discussion over there.)
--
Paul Vixie
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
vixie@vix.com (Paul Vixie) (hey, that's me!) writes:

> <http://lists.oarci.net/mailman/listinfo/> ... (There are
> about 50 folks on that list, which I'm calling "critical mass" for the
> purpose of starting the first real discussion over there.)

oops. 154 as of this morning, i guess i wasn't paying attention. note
that the list is open, and the subscriber list is open to those who are
subscribed. this isn't a vetted insider-only kind of mailing list like
OARC would normally run, it's a public service side-effect kind of thing.
--
Paul Vixie
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On Sat, 25 Feb 2006, Rob Thomas wrote:

> As many say, you own your network, and are free to run it as you see
> fit. :) That said, please be aware that if you leave your name
> servers open to recursive query requests from any source, you WILL
> unwittingly help to amplify these attacks. It's the same as ICMP
> directed broadcast and the like.

This has been an issue for years. Before the DDoSers started using open
recursive DNS servers as a modern way to "smurf", spammers were abusing
them by registering a domain, setting up DNS, loading the data into open
recursive servers (by sending them queries), and then pointing the domains
at those recursive servers...getting free DNS service and misdirecting
complaints.

The argument that DNS servers have always been open to recursion (so we
shouldn't change it) sounds a lot like the open SMTP relay issue 5-10
years ago. It took years, but all but a few wingnuts seem to have finally
caught on to the idea that open SMTP relays are a bad idea...enough so
that spammers had to move on and adapt to open proxies, and then to botted
systems / trojan proxies.

Besides, don't the DNS specs dictate that a proper DNS resolver will try
again with TCP if the server tells it the UDP reply was truncated?

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On 25-Feb-2006, at 03:41, bmanning@vacation.karoshi.com wrote:

>> Limit UDP queries to 512 bytes. This greatly decreases the
>> amplification affect, though it doesn't stop it.
>
> <limiting UDP to 512 has other, unwanted effects,
> edns0 for one... crippling ENUM, DNSSEC, IPv6, etc...
> is this really what is wanted?>

Expanding on this slightly, since I think this merits more discussion
-- if there was widespread filtering of 53/udp packets to 512 bytes,
I can see two consequences:

1. A temporary decrease in attack traffic: the malware authors will
adapt, and the floods will continue except with smaller packets. For
attacks launched from drones, the amplification arguably isn't as
important to the attacker as it might be for attacks which have
single sources.

2. In future, increased use of things like DNSSEC, dynamic updates
and IPv6 (with attendant AAAA records) are going to make legitimate,
EDNS0, large 53/udp packets more common, and crippling the transport
for EDNS0 is going to cause migraines for helpdesks across the world.

As a temporary mitigation tool today, when the volume of legitimate,
large-packet EDNS0 traffic is near-zero, blocking big 53/udp packets
might *sound* reasonable. However, we all know how permanent
temporary filters can be. Crippling EDNS0 transport in the future
seems like a very high price to pay for what might be a very
temporary, short-term reduction in attack traffic.


Joe
Re: DNS deluge for x.p.ctrc.cc [ In reply to ]
On Sun, 26 Feb 2006, Joe Abley wrote:
> As a temporary mitigation tool today, when the volume of legitimate,
> large-packet EDNS0 traffic is near-zero, blocking big 53/udp packets
> might *sound* reasonable. However, we all know how permanent

how are you certain that the udp/53 1500 byte packet is 'dns'? and not
kazaa/gnutella/bittorrent/vpn-in-udp-53 ? It seems that filtering the
TRAFFIC is short sighted on several fronts :( deciding if you will/won't
be part of the global-recursive-dns-server 'problem' is entirely different
though.

> temporary filters can be. Crippling EDNS0 transport in the future
> seems like a very high price to pay for what might be a very
> temporary, short-term reduction in attack traffic.
>

seems like global tcp/139|tcp/445 filters, or bogon filters... bits put
into configs 'now' and completely forgotten about 'tomorrow' :(

1 2  View All