Poniżej znajduje się aktualizacja wcześniejszej listy:

1. CloudFlare:
– 1.1.1.1
2. Quad9:
– 9.9.9.9
3. Google:
– 8.8.8.8, 8.8.4.4
4. CleanBrowsing:
– 185.228.168.168, 185.228.168.169
5. OpenDNS:
– 208.67.220.220, 208.67.222.222
6. Norton ConnectSafe:
– 199.85.126.10, 199.85.127.10
7. Comodo Secure DNS:
– 8.26.56.26, 8.20.247.20
8. DNS.Watch:
– 84.200.69.80, 84.200.70.40
9. VeriSign Public DNS:
– 64.4.64.6, 64.6.65.6
10. Yandex DNS:
– 77.88.8.88, 77.88.8.2

Więcej informacji: DNS Resolvers Performance compared, Jak znaleźć najszybszy publiczny serwer DNS w Polsce?

W

poprzednich częściach wspomniałem, o niektórych możliwościach pozyskania informacji za pomocą serwerów DNS oraz śledzenia wydawanych certyfikatów. W tej części zajmiemy się wyciąganiem informacji z innych zewnętrznych serwisów, które również prowadzą monitoring bardzo dużej ilości serwisów.
[ czytaj całość… ]

P

odczas ostatnich testów na SSL Labs zauważyłem nowy wpis, jaki pojawił się na tablicy wyników: DNS CAA: No. O, co chodzi z tym wsparciem dla DNS CAA? CAA jest nowym typem rekordu DNS, który określa, jaki CA (Certificate Authority – określenie organizacji bądź firmy zajmującej się wydawaniem i obsługą elektronicznych certyfikatów) jest uprawniony do wystawienia certyfikatu dla danej domeny. CAA został opisany w RFC 6844 w 2013 roku w celu poprawy siły ekosystemu PKI (Public Key Infrastructure). Niestety przez ostatnie 4 lata pozostawał on tylko w statusie propozycji standardu. Jednak za sprawą ostatniego głosowania CA/Browser Forum ma to się zmienić od 8 września 2017 roku. Po tym czasie standard wydawania certyfikatów zostanie wzbogacony o sprawdzanie rekordów CAA.
[ czytaj całość… ]

W

pierwszej części poznaliśmy podstawowe opcje konfiguracyjne uniemożliwiające wykorzystanie naszego serwera jako open resolver oraz pozyskania plików stref. W tej części zajmiemy się blokowaniem informacji, które mogą dostarczyć atakującemu niezbędnej wiedzy podczas rekonesansu. Serwery BIND (oraz wiele innych) potrafią zwracać “ukryte” informacje, gdy zostanie wysłane do nich specjalne zapytanie DNS. Zazwyczaj nie jest to pożądana ekspozycja dlatego należy ją zablokować.
[ czytaj całość… ]

curl -s http://public-dns.info/nameserver/pl.csv > list; cat list | cut -d "," -f1 | \
xargs -i timeout 1 ping -c1 -w 1 {} | grep time | \
sed -u "s/.* from \([^:]*\).*time=\([^ ]*\).*/\2\t\1/g" | grep -v "1 packets" | sort -n

Więcej informacji: DNS servers in Poland

K

iedy używamy serwisów zapewniających anonimowość i prywatność w internecie, bardzo ważne jest, aby cały ruch sieciowy pochodzący z naszego komputera, był przesyłany poprzez sieć zapewniającą taką właśnie usługę. Jeśli jakikolwiek ruch (przez dowolny protokół) wycieka – czyli – nie używa bezpiecznego połączenia z internetem, to każdy, kto (np. ISP) będzie monitorować aktywność Twojego komputera, jest w stanie wychwycić ten ruch sieciowy.
[ czytaj całość… ]

N

ie ważne, jak bardzo skręcimy dostęp sieciowy do i z naszych serwerów – to zawsze zezwolimy na ruch DNS, aby móc rozwiązywać nazwy domenowe na adresy IP i na odwrót. Osoba, która dokonała skutecznego ataku na nasze maszyny może wykorzystać tą “lukę” w zaporze ogniowej i potajemnie wyprowadzić dane za pomocą połączeń do C&C, które trudno zablokować. Aby bliżej zrozumieć tunelowanie poleceń i danych za pomocą DNS do serwerów Command and Control spójrzmy na narzędzie autorstwa Rona Bowsesa o nazwie dnscat2.
[ czytaj całość… ]

P

rzy okazji wygasania certyfikatu na stronie zacząłem się zastanawiać, czy skorzystać z Let’s Encrypt, czy może z CloudFlare? CF to serwis oferujący “darmową” ochronę webaplikacji, CDN oraz szyfrowanie SSL (jeśli używa się go poprawnie). Zastanawiało mnie ile klientów / domen korzysta z tego serwisu? Oto, co udało mi się ustalić.
[ czytaj całość… ]

R

ekonesans DNS jest główną częścią etapu zbierania informacji w testach penetracyjnych. Można to porównać do wykonywania mapy infrastruktury danego serwisu. Większość organizacji nie monitoruje ruchu DNS, szczególnie nieudanych zapytań i prób pobrania całej strefy – dlatego wyciśnięcie jak największej ilości informacji z tego źródła często nie wpływa na alarmy w systemach bezpieczeństwa i nie wzbudza podejrzeń. W Internecie istnieje wiele dostępnych narzędzi, które mogą skutecznie wykonywać tego typu operacje, ale my skupimy się tylko na kilku i w dodatku tylko na tych napisanych w języku Python, ponieważ bardzo łatwo jest stworzyć dla nich wirtualne środowisko i zainstalować zależności, aby zadziałały od kopnięcia.
[ czytaj całość… ]

P

o napisaniu podstaw bezpieczeństwa DNS zastanawiałem się, jaka jest skala problemu źle skonfigurowanych serwerów, które pozwalają na ściągnięcie całej strefy lub wykonywanie zapytań dowolnemu klientowi. Duch patryjotyzmu namawiał mnie na sprawdzenie TLD .pl, zarządzaną przez NASK. Niestety, jak zawsze polski dwór zakończył nadzieję na czwartej wymianie zdania. Dialog wyglądał tak:

– Czy istnieje możliwość otrzymania od Państwa listy wszystkich dotychczas zarejestrowanych domen .pl?
– NASK nie udostępnia tego typu informacji.
– A orientują się Państwo do jakiego organu można zwrócić się w tej sprawie?
– Te dane posiada tylko NASK.

Nie chciało mi się już próbować, czy aby jednak istnieje taka możliwość poprzez CZDS. Rozważałem już przerzucić się na zagraniczne banany, ale z pomocą przyszedł portal, który stanowi swoiste źródło wiedzy o ruchu w Internecie. Okazuje się, że Alexa bez żadnych zbędnych formalności udostępnia milion najczęściej odwiedzanych stron. To stanowi już jakąś próbkę, którą można poddać testom.
[ czytaj całość… ]