Hi all,
A quick question, what is the common bandwidth for out-of-band access?
Thanks.
:
:Hi all,
:A quick question, what is the common bandwidth for out-of-band access?
:Thanks.
That would depend on what your OOB uses for an interface (cli/gui), or
what bandwidth you have to spare. Not necessarily in any given order.
Overprovisioning alleviates most concerns, and bw, whether clear-channel
in-house, or otherwise is cheap these days 
Hi all,
A quick question, what is the common bandwidth for out-of-band access?
Thanks.
In the optical world it's often 192 Kb/sec.
Mike
Probably depends if you use in-band management primarily. If your code
pushes etc normally happen only inband, and out of band is reserved for
console/CLI access only in emergencies, then small (9.6 to 64kb) is
probably fine.
Clearwire + POTS as a backup.
--chuck
Michael K. Smith - Adhost expunged (mksmith@adhost.com):
> Hi all,
> A quick question, what is the common bandwidth for out-of-band access?
> Thanks.
>
In the optical world it's often 192 Kb/sec.
I think that was common circa late 90's, I've seen at least two optical providers that use 10Mb/s optical overhead channels on recent technology.
-Steve
Given the recent DNS amplification attacks, I've audit and updated our
authoritative servers. We are using 9.6.0-P1 now. I've been using the cyrmu
templates, but one thing I see is that the dns queries to the . hint file
are still occuring and are not being denied by our servers. For example:
27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view
external-in: query: . IN NS +
27-Jan-2009 15:00:23.118 queries: client 64.57.246.146#33146: view
external-in: query: . IN NS +
the named.conf has:
...
...
...
view "external-in" in {
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
zone "." in {
type hint;
file "db.cache";
};
...
...
since you can't put a "allow-query { none; };" in a hint zone, what can I do
to deny the query to the . zone file?
Matthew Huff.vcf (1.57 KB)
Many times I've used 9600 or 2400 baud over dail-up for OOB of routers. On
the other hand some enterprises use a seperate 1Gbps Vlan for management.
Again it depends on the type of traffic (i.e. snmp(traps), telnet, ssh,
graphical, web, syslog, netflow etc..). For ssh/telnet without the need for
filetransfer a dial-ip modem should work fine.
We used a 3rd party Frame Relay network for out of band access.
AFAIK, that's about the best you can do with the DNS configuration. You've
mitigated the amplification value, so hopefully the perpetrator(s) will drop
you. If you're willing to keep up with the moving targets, the next level
is an inbound packet filter. Add to your inbound ACL:
deny udp host 64.57.246.146 neq 53 any eq 53
Also on this topic:
Coincident with this DNS DOS, I started seeing inbound PTR queries from
various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers).
They receive no response, yet they persist. Anyone have thoughts on their
part in the scheme?
Best wishes,
Nate Itkin
Quoting Matthew Huff <mhuff@ox.com>:
Given the recent DNS amplification attacks, I've audit and updated our
authoritative servers. We are using 9.6.0-P1 now. I've been using the cyrmu
templates, but one thing I see is that the dns queries to the . hint file
are still occuring and are not being denied by our servers. For example:27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view
external-in: query: . IN NS +
27-Jan-2009 15:00:23.118 queries: client 64.57.246.146#33146: view
external-in: query: . IN NS +the named.conf has:
...
view "external-in" in {
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;zone "." in {
type hint;
file "db.cache";
};
...since you can't put a "allow-query { none; };" in a hint zone, what can I do
to deny the query to the . zone file?----
Matthew Huff | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com | Phone: 914-460-4039
aim: matthewbhuff | Fax: 914-460-4139
Hi Matthew,
I'm using the following with 9.5.1:
view "external" {
recursion no;
allow-query-cache { none; };
zone "." IN {
type hint;
file "/var/named/named.ca";
And my logs indicate that the requests for . IN NS are being denied:
Jan 28 08:40:38 web1 named[12337]: client 64.57.246.146#33453: view external: query (cache) './NS/IN' denied
Jan 28 08:40:39 web1 named[12337]: client 67.192.144.0#41794: view external: query (cache) './NS/IN' denied
Cheers,
Jay
chuck goolsbee wrote:
And be careful.. It's easy to have simple local passwords, a dial-in modem
and then get pwned.. Were I used to be, we had encrypted modems for POP
dialin.
Leigh Porter wrote:
And be careful.. It's easy to have simple local passwords, a dial-in modem
and then get pwned.. Were I used to be, we had encrypted modems for POP
dialin.
I have my POTS modem set up to accept PPP too so there's the option of being a little more secure than a plain text terminal, assuming the world didn't completely blow up.
~Seth
I'm not seeing those PTR queries for 10.0.0.0/8, but then my perimeter
ingress/egress filters (BCP 38) toss most of that kind of junk before my
DNS servers ever see it.
I agree that is as far as one can go with BIND, right now. However, that
isn't making the perpetrators cease and desist. I am seeing ongoing query
attempts coming in and refusal packets going back out, and the targets
don't seem to change until I do something to block them. So mitigating
the amplification factor does not seem of interest to these perpetrators.
On the contrary, even REFUSED responses can aggregate with some amplified
responses to enhance the apparent DoS goal. Thus BCP 140 seems to be
less than completely effective because it is less than universally applied
(i.e., older versions of BIND or misconfigured BIND.) I think the same
situation is true with BCP 38: less than universally applied. So do I wait
for universal application of these BCPs, or do I take responsibility for
doing what I can to make my network resources less appealing for abuse?
I choose the latter, and that is why went to the effort of blocking this
abusive traffic before it reaches my authoritative-only DNS servers.
Nevertheless, I also agree with a point made last week that trying to keep up
with the changing targets is a game of whack-a-mole that is and will continue
to be a drain on network management resources -- if the detection and response
continues to be deployed manually. This is why I wrote some Perl for my
authoritative-only servers to automate detection and response at the server
level. Granted it isn't a permanent solution, but at least it is a place
to start. I appended that code below for those who are interested in it.
Notes
1:54pm wingying said:
A quick question, what is the common bandwidth for out-of-band access?
If you administer the metro MPLS for a large city, apparently about "1,100...modems hidden away in locked filing cabinets in public buildings around the city." http://weblog.infoworld.com/venezia/archives/017935.html
:-p Couldn't resist.
../C
"Douglas C. Stephens" <stephens@ameslab.gov> writes:
...
I choose the latter, and that is why went to the effort of blocking this
abusive traffic before it reaches my authoritative-only DNS servers.
this is an odd implementation choice. the 1PPS query stream is still using
your line even with this defense in place. the 1PPS response stream and the
CPU cycles it takes to generate that stream isn't a burden on you (compared
to the 1PPS query stream that you can't stop anyway). so the only reason to
block these appears to be so that you don't participate in the attack, or in
other words to cut down the burden on the victim. with me so far?
the burden on the victim isn't going to drop materially by what you did since
hundreds of thousands of other servers are not going to block it. but if the
victim is a recursive nameserver, then your blocking them will mean that they
cannot access the zones you're authoritative for. so, no positive, but some
negative, for the only person in the whole equation who can be affected by
the blocking you're doing.
i don't get it. with a cost:benefit matrix like that one, why is anybody
blocking this traffic? (i note with some alarm that ten years after i shot
it down, i still get queries to rbl.maps.vix.com, so the possibility that the
blocks some folks might put in place to ...manage?... this attack will have a
long term bad effect on our heirs and assigns. i know your perl script will
expire things 60 seconds after they stop spewing, but i fear that others are
blocking these in hardcode.
(looking for ". IN NS" as the q-tuple pattern is not a solution, since the
bad guys can pretty trivially change the question they ask into one you're
willing to answer.)
(REFUSED is nice because it's small, but the bad guys aren't lacking for bots
to transmit spoofed packets from, they Do Not Need amplification, and all
forms of error rate limiting are also new attack vectors.)
(is there a name-and-shame registry for networks that do/don't implement
BCP38? if not i guess i'll start one and hope that various auditors will use
google and notice me.)
Actually, ". IN NS" is a particularly useful thing for them to do, because it's an almost globally guaranteed response that will get a large response and be in cache. One can get similar effects with "<tld>. IN NS", of course, but the set of things that work well for such an attack are relatively limited.
One thing that's fairly straightforward with the current attack is to block
00600 deny udp from 66.230.160.1 to me 53 iplen 45
(foreach victim host)
(If you tcpdump the traffic, because of the . IN NS, the packets are all the same length - 45 IP bytes.) Very easy to filter at the current time with almost no collateral damage.
I realize this is just a cat-and-mouse game, but forcing the attacker to use larger query packets that have smaller cached replies isn't a bad thing.
". NS" -> 45 byte query, 245 byte response
"COM. NS" -> 48 byte query, 245 byte response
"NET. NS" -> 242 byte response,
"ORG. NS" -> 159 byte response,
This masking is mostly effective for people whose nameservers are set to deny recursive but are still serving from cache. YMMV.
-Dave
Once upon a time, David Andersen <dga@cs.cmu.edu> said:
Actually, ". IN NS" is a particularly useful thing for them to do,
because it's an almost globally guaranteed response that will get a
large response and be in cache.
That's only true on servers that aren't well-configured.
"<tld>. IN NS", of course, but the set of things that work well for
such an attack are relatively limited.
Try "aol.com. MX", "hotmail.com. MX", any domain with a big SPF TXT
record, etc. There's nothing really special about ". NS". If somebody
is serving cached data to the world (even if they aren't recursing for
the world), there are any number of things that are likely in the cache.
And, since most people have SMTP servers, it is often easy to "prime"
somebody's cache, since the SMTP servers often use the same DNS servers.
Pretty soon we need an RBL for DNS-oriented DDoS attacks. =)