Hello Nate,it seems i cant get the link of the advisory.Its about some sort
of amplyfing flood,when an ousider makes spoofed queries to the bind daemon
and another one ,the victim is flooded along with me the attacked..
Thx..
At 02:56 AM 12/30/01 -0800, nate wrote:
<quote who="Petre Daniel">
> Well,i know Karsten's on my back and all,but i have not much time
> to learn,and too many things to do at my firm,so i am asking if
> one of you has any idea how can bind be protected against that DoS
> attack and if someone has some good firewall for a dns server (
> that resolves names for internal clients and also keeps some .ro
> domains) please post it to the list.. both ipchains and iptables
> variants are welcome..
> thank you.
i ran a search for dos in my recent debian-user archives
and did not come up with anything(related), which DOS attack?
i monitor bugtraq and vuln-dev closely and have not seen
any mention of bind for a REAL long time.
i run BIND 8 as all my nameservers. i change the
configuration from what debian has significantly.
everything resides under /etc/bind. everything
is chowned named.named everything is readable by
only user named/group named. named runs in chroot
in /etc/bind and runs as user named group named.
i restrict zone transfers to authorized servers only.
if needed(like on a firewall or gateway), i have
it bind to a specific interface(the internal one,
or the loopback or both depending on your needs).
more recently i have started working with syslog-ng
and remote logging, i configured syslogd on
the debian systems to create a log socket inside
the bind chroot enviornment so i can send the named
logs to the syslog server(because it cannot access
/dev/log otherwise). before that i had bind log
to a file inside the chroot enviornment.
bind has worked good for me for years. if its configured
good it can be quite secure. i reccomend the book
from oreilley(sp?) DNS & Bind, thats where i initially
learned about the chroot and running as non root
uid/gid and access lists. the information is elsewhere
as well but i found that book very interesting and
useful. you can go farther by restricting queries
via access lists as well, but this(in my experience)
will break any nameserver that is primary or
secondary for a domain, as nobody but those in
the access lists will be able to query for the
domain info. useful for the more paranoid
in a caching-only enviornment(or at least
a non-public DNS).
hope this helps!
nate
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Petre L. Daniel,System Administrator
Canad Systems Pitesti Romania,
http://www.cyber.ro, email:[EMAIL PROTECTED]
Tel:+4048220044, +4048206200