Wpisy otagowane ‘BIND’

query (cache) ‘./NS/IN’ denied

czwartek, 5 Luty 2009

Zaczęło się 6 stycznia (wcześniej tylko moje próby i IANA – patrz. Zamieszanie z DNS). W logach w pełni wygląda to tak:

Jan  6 16:16:17 dns named[2420]: client 63.217.28.226#59110: query (cache) './NS/IN' denied
Jan  6 16:16:23 dns named[2420]: client 63.217.28.226#5401: query (cache) './NS/IN' denied
Jan  6 16:16:29 dns named[2420]: client 63.217.28.226#42293: query (cache) './NS/IN' denied
[...]
Feb  5 11:01:33 dns named[2422]: client 89.149.221.182#33910: query (cache) './NS/IN' denied
Feb  5 11:01:37 dns named[2422]: client 89.149.221.182#5760: query (cache) './NS/IN' denied
Feb  5 11:01:39 dns named[2422]: client 89.149.221.182#39304: query (cache) './NS/IN' denied

Patrząc po ilości (1’174’755 sztuk w tym okresie z ok. 30 źródeł), nie nazwał bym tego atakiem typu DOS, a tym bardziej DDOS. Roboty próbują truć masowo, ale na razie nie blokuję tego w żaden sposób.

O odczuciach innych można poczytać tutaj:

Zamieszanie z DNS

piątek, 8 Sierpień 2008
bsk.com.pl

bsk.com.pl

Zrobiło się ostatnio trochę szumu wokół DNS za sprawą Dana Kaminskiego. Więcej, prócz wpisów w jego blogu, można poczytać tutaj:

IANA udostępniła narzędzie, dzięki któremu możemy sprawdzić czy jesteśmy bezpieczni czy nie. Technicznie ten test wygląda mniej więcej tak (linie nieparzyste pytania, linie parzyste – odpowiedzi):

1: [udp sum ok] 59142 [1au] NS? DOMAIN.TLD. ar: . OPT UDPsize=4096 (40) (DF) (ttl
    52, id 0, len 68)
2: 59142*- q: NS? DOMAIN.TLD. 2/0/3 DOMAIN.TLD. NS[|domain] (ttl 63, id 45373, len
    154)
3: [udp sum ok] 29369+ SOA? iana.org. (26) (DF) (ttl 52, id 0, len 54)
4: [udp sum ok] 29369 ServFail- q: SOA? iana.org. 0/0/0 (26) (ttl 63, id 0, len 54)
5: [udp sum ok] 62488+ SOA? iana.org. (26) (DF) (ttl 52, id 0, len 54)
6: 62488- q: SOA? iana.org. 0/5/3 ns: iana.org. NS[|domain] (ttl 63, id 45375, len
    218)

Konwersacja z moim pierwszym serwerem (linie 3 i 4) kończy się odpowiedzią SERVFAIL, z drugim (linie 5 i 6) – iana.org has no SOA record. Pierwszy to bind 9.3.5, drugi – PowerDNS 2.9.21. Oba mają wyłączone rekursywne zapytania. W przypadku bind:

allow-recursion { 127.0.0.1; };

PowerDNS to:

allow-recursion=127.0.0.1/8

Wobec czego możemy się pocieszyć komunikatem:

Safe.

The servers tested for DOMAIN.TLD are not vulnerable to cache poisoning.

djbdns (w wersji 1.05) nie odpowiada w ogóle na takie ‘zaczepki’ i IANA uznaje, że Appears to not respond to recursive lookups.

BIND’s views

środa, 9 Lipiec 2008

Swego czasu opracowałem metodę zabezpieczenia łącz (w sensie dostępu do sieci / hosta, gdy protokoły takie jak BGP są niedostępne) za pomocą kierowania ruchem i odpowiedniej konfiguracji DNS.

Na widokach w BIND działało to bardzo dobrze. Konfiguracja sprowadza się do podania warunków, dla których dane strefy będą przetwarzane. Mając do dyspozycji match-clients i match-destinations możemy naprawdę wiele zrobić. Skorzystanie z tej funkcjonalności oszczędzi nam uruchamiania drugiego serwera nazw np. dla sieci lokalnej czy dla konkretnego łącza.

Z czasem zacząłem wykorzystywać PowerDNS (z racji świetnie działającej natywnej obsługi baz danych) i właśnie funkcjonalności widoków mi brakuje. Co prawda można mieć jedną bazę z dodatkową kolumną content, ale i tak trzeba uruchomić dwa serwery. Nadzieją mogło by być wykorzystanie adresu IP klienta (odpowiedni warunek w zapytaniu SQL), ale to niemożliwe sądząc po (niejednej) wypowiedzi developerów na liście dyskusyjnej PowerDNS.