Nadal pojawia się nowy alert: Serwer zwrócił błąd NXDOMAIN, ograniczający potencjalne naruszenie DNS DVE-2018-0001

Właśnie zainstalowałem nowy serwer Ubuntu 18.04. Ustawiłem nazwę hosta hostnamectl set-hostname ****.openbayou.bizi ustawiłem /etc/hosts:

127.0.0.1 localhost
[ip address] ****.openbayou.biz hostname
# The following lines are desirable for IPv6 capable hosts
[ip6 address] *****.openbayou.biz hostname
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Zainstalowałem również OSSEC, aby monitorować nowe pliki, błędy i zmiany na moim serwerze, a teraz otrzymuję te alerty:

Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018- 
0001, retrying transaction with reduced feature level UDP.`

Teraz się powtarza:

systemd-resolved[3195]: message repeated 4 times: [ Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction 
with reduced feature level UDP.]

Szukałem rozwiązania online i nikt nie zgłasza tego problemu.

Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018- 0001, retrying transaction with reduced feature level UDP.

Ten sam błąd wystąpił na moim komputerze stacjonarnym, nie wiem, czy dotyczy on również serwera.

Wygląda na to, że mój system miał w tym miejscu starą konfigurację, co spowodowało konflikt między dwiema usługami: resolvconfi systemd-resolved.

Dowiązanie symboliczne /etc/resolv.confwskazywało../run/resolvconf/resolv.conf

Zmieniając go na punkt, /run/systemd/resolve/resolv.confktórym zarządza systemd, naprawiłem to dla mnie.

Przeczytaj więcej tutaj .

Mam nadzieję, że to pomogło.

Zapytałem w OSSEC GitHub o ten błąd i zalecili napisanie reguły, aby zignorować błędy NXDOMAIN. Dodać do/var/ossec/rules/local_rules.xml

<rule id="234567" level="0">
 <program_name>systemd-resolved</program_name>
 <match>Server returned error NXDOMAIN</match>
 <description>Usless systemd-resolvd log message</description>
</rule>

To ostrzeżenie jest rejestrowane przez systemd-resolved, ilekroć nazwa nie może być rozwiązana przez system DNS (np. Nslookup www.kjfoiqaefah34876asdf.com). Można to tolerować i nie ma powodu do niepokoju. To nie jest błąd i nic nie trzeba naprawiać.

Przekierowanie /etc/resolv.conf do /run/systemd/resolve/resolv.conf jest nieprawidłowe, ponieważ w ten sposób systemd-rozwiązany jest pomijany, a aplikacja z wadliwym żądaniem DNS mówi bezpośrednio do serwera nazw, a nie do systemd-rozwiązanego stub już. W ten sposób systemd-rozwiązany nie zauważa już zdarzeń NXDOMAIN, a zatem nie może już ich rejestrować.

Zdarzenia NXDOMAIN są powodowane przez pakiety, które próbują uzyskać dostęp do nieistniejących serwerów podczas uruchamiania systemu.

Zauważyłem to samo na serwerze Ubuntu 18.04, który został niedawno zaktualizowany do 18.04.1.

Wygląda na to, że systemd-resolve rejestruje ten komunikat, ilekroć otrzyma odpowiedź NXDOMAIN. W moim przypadku mam działający postfiks. Dostaję więc dużo NXDOMAINS, gdy łączą się losowe serwery, które nie mają ustawionego rekordu PTR.

Możesz to przetestować

systemd-resolve securelogin.example.com

Powinien pojawić się komunikat dziennika.

Mając to na uwadze, wydaje się, że jest to stosunkowo nieszkodliwy błąd i można go zignorować.

Rozumiem po przeczytaniu poprzednich odpowiedzi i innych stron internetowych, takich jak błąd naprawiony przez system Ubuntu 18.04 NXDOMAIN, że jest to bardziej ostrzeżenie niż błąd i nie mogę nic z tym zrobić.

Dlatego zgadzam się z tymi, którzy twierdzą, że nie powinniśmy próbować robić czegoś po naszej stronie, aby te wiadomości nie były już produkowane. Jeśli nam się powiedzie, prawdopodobnie zmieniliśmy normalny sposób, w jaki system rozpoznaje żądania DNS.

Ponieważ jednak mam ich tysiące (jestem też na pulpicie - to nie jest serwer), nie chcę ich w moim pliku syslog. Dlatego po https://www.rsyslog.com/doc/v8-stable/configuration/filters.html i prefiksie pary liczb do plików konfiguracyjnych dodałem plik o nazwie 10-resolv.confz pojedynczą linią :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~w katalogu /etc/rsyslog.d .

Nazwa 10-resolv.confnie jest ważna, ale musi poprzedzać wszystkie inne nazwy plików w katalogu w kolejności alfabetycznej. Polecenie :msg, contains, <message-part> ~mówi, że wszystkie wiadomości zawierające <wiadomość-część> muszą zostać zignorowane: tylda ~w poleceniu mówi o usunięciu wiadomości.

Uwaga dodana: Ponieważ napisałem tę odpowiedź, zainstalowałem kilka pakietów (z innych powodów), a komunikat o błędzie nie jest już wyświetlany zgodnie z poleceniem journalctl -u systemd-resolved -f. Jednym z zainstalowanych pakietów, który może wyjaśniać zniknięcie tego komunikatu, jest libnss-resolver.

Podsumowanie:

Komunikat o błędzie NXDOMAIN oznacza, że ​​domena nie istnieje.

Niektórzy dostawcy usług internetowych rozpoczęli przejęcie DNS lub przekierowanie DNS w celu wyświetlenia komunikatów o błędach NXDOMAIN. Jest to praktyka przekierowywania rozdzielczości nazw systemu nazw domen (DNS) na inne serwery DNS lub serwery sieciowe.

Powszechnie stosowany do wyświetlania reklam lub zbierania statystyk.

Ta praktyka narusza standard RFC dla odpowiedzi DNS (NXDOMAIN).

Wyłudzanie informacji: ataki typu cross-site scripting mogą wystąpić z powodu złośliwego przejęcia.

Cenzura: dostawcy usług DNS blokujący dostęp do wybranych domen.

Pokazane tutaj: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

Byłem w stanie pozbyć się tej wiadomości, a swoją drogą mogłem wreszcie połączyć się z moim serwerem samby, zmieniając nazwę serwera na server.domainzamiast zamiast server.

Wygląda to na związane z EDNS. Różnica między używaniem stub-resolv.confa resolv.confjest options edns0.

Mechanizmy rozszerzenia dla DNS (EDNS) to specyfikacja zwiększania rozmiaru kilku parametrów protokołu Domain Name System (DNS), który miał ograniczenia wielkości, które społeczność inżynierów internetowych uznała za zbyt ograniczoną, aby zwiększyć funkcjonalność protokołu.

https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS

Więcej szczegółów w tym numerze: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969

Wygląda na to, że możesz po prostu wyłączyć tę „opcję”.

Problem

Chociaż mogą występować inne okoliczności, w których wystąpi ten błąd, z całą pewnością mogę powiedzieć, że widziałem go w wyniku:

systemctl status systemd-resolved

... kiedy systemd-resolvednie jest skonfigurowany.

Ponadto maszyna wirtualna Azure Ubuntu 18.04 nie systemd-resolvedskonfigurowała się od razu po wyjęciu z pudełka (na dzień 20191008).

Rozwiązanie:

Konfiguruj systemd-resolved.

Mini systemd-resolvedConfig HowTo:

UWAGA : Poniższe instrukcje zostały przygotowane przy użyciu Ubuntu 18.04

Edytuj hostsdyrektywę /etc/nsswitch.conf, dodając, resolvektóre zestawy rozwiązane systemd jako pierwsze źródło rozwiązania DNS, które będą konsultowane:

hosts:          resolve files dns

Edit /etc/systemd/resolved.conf. Niektóre sugerowane ustawienia:

[Resolve]
DNS=8.8.8.8 8.8.4.4
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
Cache=yes
DNSStubListener=yes

Uruchom ponownie systemd-resolved:

sudo systemctl restart systemd-resolved

Przy następnym sprawdzaniu systemd-resolvedstanu błąd powinien zostać teraz usunięty:

systemctl status systemd-resolved

Rozdzielczość DNS powinna teraz działać w oczekiwany sposób.