Forum: PC Hard- und Software Zu viele DNS-Sessions offen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Holger (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich habe hier ein Problem mit einem Linux-Server.
Laut den Einträgen in der physischen Firewall überschreitet der Server 
die maximale Anzahl an offenen Sessions (1000).

Doch wie kriege ich den Server dazu, diese zu schliessen?


Ich hoffe, jemand hat eine Idee.

Danke.

von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich nutze übrigens eine USG20 von Zyxel

von Jack V. (jackv)


Bewertung
2 lesenswert
nicht lesenswert
Holger schrieb:
> Ich hoffe, jemand hat eine Idee.

Die sinnvollste Idee wäre wohl, festzustellen, welches Programm diese 
Verbindungen öffnet, und dieses dann so zu konfigurieren, dass es das 
nicht mehr tut. Verwendbare Hilfsmittel für den ersten Teil wären z.B.: 
ss, netstat, lsof

von (prx) A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
Bei DNS über UDP gibt es im DNS-Verfahren selbst keine Sessions. 
Anfrage-Antwort-Schluss. Allerdings gibt es in Firewalls eine 
NAT-Tabelle, die aus einem initialen UDP-Paket in ausgehender Richtung 
eine Session macht, damit die Firewall den Rückweg in eingehender 
Richtung für eine gewisse Zeit freihält. Eine solche nur in der Firewall 
entstehende Session wird mangels formellem Abschluss bei UDP erst über 
Timeout beendet.

: Bearbeitet durch User
von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Eine solche Session wird mangels
> formellem Abschluss bei UDP erst über Timeout beendet.

Danke für deine Antwort.
Interessanterweise wurden alle sessions entfernt, sobald ich den Server 
neu gestartet habe. Der Server scheint die also irgendwie am Leben zu 
halten oder nicht?

Jack V. schrieb:
> Verwendbare Hilfsmittel für den ersten Teil wären z.B.:
> ss, netstat, lsof

Danke, werde ich prüfen, sobald wieder entsprechend viele Einträge 
vorhanden sind.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Wo und womit hast du obige Tabellen ausgegeben?

von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wo und womit hast du obige Tabellen ausgegeben?

Obige Tabellen stammen aus dem Webinterface der Firewall (USG20). Es ist 
nur ein Auszug. Da es tatsächlich 1000 Sessions waren. Ich war auch 
etwas überrascht ab den IP-Adressen.

Denn ich hatte als Nameserver nur: 8.8.8.8 sowie 192.168.50.1 
konfiguriert

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Die Anzahl wiederholter Anfragen mit gleichem Namen lässt sich auf dem 
Server durch einen DNS-Cache reduzieren. Das ist kaum mehr als die 
Installation von "bind" mit Default-Einstellungen, plus Umleitung seiner 
DNS-Anfragen an ebendiesen eigenen DNS-Server.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Holger schrieb:
> Denn ich hatte als Nameserver nur: 8.8.8.8 sowie 192.168.50.1
> konfiguriert

Dann such auf dem Server lieber mal nach der Ursache dieser vielen 
Anfragen. Von nix kommt nix.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich ein paar der IP-Adressen in der rechten Tabelle auflöse, lande 
ich in den DNS-Registries von Japan, Österreich und Kanada. Ein lokaler 
DNS-Server, über den nicht-lokale Anfragen laufen, könnte ein ähnliches 
Pattern hervorrufen.

: Bearbeitet durch User
von Plaste-Router (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Holger schrieb:
> Interessanterweise wurden alle sessions entfernt, sobald ich den Server
> neu gestartet habe. Der Server scheint die also irgendwie am Leben zu
> halten oder nicht?

Vielleicht kriegt die Firewall auch nur mit, dass die 192.168.50.20 
offline/unreachable ist, und räumt dann deren Conntrack-Entries auf.

Läuft denn auf der .50.20 ein DNS-Server?
Wenn nein: Schauen, was da die DNS-Anfragen sendet.
Wenn ja: als caching+forwarding konfigurieren.

Ansonsten sind nur 1000 conntrack-Entries recht wenig für eine Firewall, 
da macht doch jeder 08/15 Plaste-Wlan-Router mehr.
Die USG20 basiert auf Linux/Netfilter. Kommt du da nah genug ran, um da 
einfach mehr Conntrack-Entries und weniger UDP-Gültigkeitsdauer zu 
konfigurieren? Und warum steht im USG20-Werbeprospekt was von 20'000 
concurrent connections? Hat du das 1000er-Limit selber eingestellt?

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
Holger schrieb:
> Denn ich hatte als Nameserver nur: 8.8.8.8 sowie 192.168.50.1
> konfiguriert

Wo/auf was konfiguriert?

Meine Vermutungen (muss nicht so sein):

Du betreibst auf der Inside der Firewall einen DNS-Server.
Du hast relativ viele Benutzer, die ständig in der Welt rumsurfen oder 
andere Dinge machen.

Dann:

A) Deine DNS-Konfiguration wird nicht auf alle Hosts verteilt. Entweder 
DHCP-Server kaputt (falsch konfiguriert) oder es gibt Hosts die nicht 
über DHCP konfiguriert sind und nicht von Hand korrekt konfiguriert 
wurden. Die Resolver auf diesen Hosts machen alles selber.

B) Irgendwo Inside läuft ein DNS-Server von dem du keine Ahnung hast. 
Vielleicht auch auf einem Host, der nicht (per DHCP) für deinen Inside 
DNS-Server konfiguriert wurde. Vielleicht irgend ein Müll mit 
systemd-resolved der Amok läuft.

C) Dein Nameserver auf der Inside ist ohne Forwarding auf einen 
DNS-Server Outside der Firewall konfiguriert. Daher muss er alle 
DNS-Requests selber abarbeiten, d.h. iterativ oder rekursiv andere 
Nameserver kontaktieren, statt immer Forwarding zum Outside DNS-Server 
zu benutzen.

D) Oder es ist zwar ein Outside DNS-Server fürs Forwarding konfiguriert, 
aber der kann keine rekursive Namensauflösung. Statt dessen beglückt er 
deinen Inside Server damit, dass er Antworten zurück liefert die dieser 
dann iterativ auflösen muss.

Was tun? Source-Adresse(n) der ganzen DNS-Anfragen heraus finden. 
Entweder stehen die im USG Log oder es ist mal wieder Zeit für 
Wireshark. Der Host (hoffentlich nur einer), der die Adresse hat ist 
dein Sorgenkind. Wenn du sowieso schon Wireshark am Start hast, dann 
auch mal kontrollieren was per DHCP verteilt wird.

Brutalo-Möglichkeit: Port 53 UDP für alle Hosts außer deinem Inside 
DNS-Server von/zum Outside DNS-Server auf der Firewall schließen und 
warten welche User schreien, dass das "Internet kaputt" ist.

von Bastler (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Du hast auf irgendeiner Windows-Möhre einen Trojaner oder so drauf, der 
irgendwelche DNS-Anfragen durch-scannt.

von Mario M. (thelonging)


Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> lande
> ich in den DNS-Registries von Japan, Österreich und Kanada

Das Forwarding der DNS-Anfragen funktioniert nicht, der Server löst die 
Anfragen selber rekursiv auf und überschwemmt die Firewall mit 
DNS-Anfragen.
1
192.41.162.30      l.gtld-servers.net.
2
213.248.216.1      dns1.nic.uk.
3
194.85.252.62      b.dns.ripn.net.
4
194.146.106.74     coza1.dnsnode.net. / ns4.dns.business.
5
212.4.64.139       lo2-dns-anycast-zg.datazug.net.
6
192.52.178.30      k.gtld-servers.net.
7
192.35.51.30       f.gtld-servers.net.
8
156.154.102.3      nsc.nic.uk.
9
199.249.120.1      b2.org.afilias-nst.org.
10
192.54.112.30      h.gtld-servers.net.
11
194.190.124.17     d.dns.ripn.net.
12
194.0.10.100       ns9.univie.ac.at.
13
162.88.54.1        ns91.nic.tr.
14
194.0.11.113       dns-c.rotld.ro.
15
156.154.100.3      nsa.nic.uk.
16
194.0.28.53        ns1.dns.nl.
17
203.119.1.1        a.dns.jp.
18
199.254.31.1       A0.INFO.AFILIAS-NST.INFO.
19
77.67.63.105       l.de.net.
20
200.189.41.10      b.dns.br.
21
194.0.17.1         e.nic.ch.
22
162.159.25.38      d.au.

von Sven L. (sven_rvbg)


Bewertung
-1 lesenswert
nicht lesenswert
Das Sessionlimit lässt sich bei der USG auch anpassen oder ggf. 
deaktivieren. In der Vergangenheit gab es da auch glaube ich einen Bug 
in der Funktion.

von Holger (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank nochmals für eure Antworten.

Nach dem Neustart, sind die Sessions weg gewesen. Inzwischen jedoch 
wieder hier.

Auf dem Linux-Rechner mal ss -u -a ausgeführt und siehe da:
1
ESTAB             0                  0                                      192.168.50.20:59093                                    212.4.64.139:domain
2
ESTAB             0                  0                                          127.0.0.1:46811                                      127.0.0.53:domain
3
ESTAB             0                  0                                          127.0.0.1:42727                                      127.0.0.53:domain
4
ESTAB             0                  0                                      192.168.50.20:38641                                         8.8.8.8:domain
5
ESTAB             0                  0                                      192.168.50.20:34547                                    192.33.14.30:domain
6
ESTAB             0                  0                                      192.168.50.20:38645                                         8.8.8.8:domain
7
ESTAB             0                  0                                          127.0.0.1:50937                                       127.0.0.1:domain
8
ESTAB             0                  0                                      192.168.50.20:55036                                    192.12.94.30:domain
9
ESTAB             0                  0                                          127.0.0.1:55038                                      127.0.0.53:domain
10
ESTAB             0                  0                                      192.168.50.20:38655                                    192.168.50.1:domain
11
ESTAB             0                  0                                                             8.8.8.8:domain
12
....

Sehr viele Sessions.
Diese ändern sich ständig. Daher denke ich mal, dass hier wirklich eine 
Rekursion stattfindet.

Die frage ist, wie kann ich diese unterbrechen?

Ich habe 127.0.0.53 als nameserver eingetragen.
Bei diesem habe ich konfiguriert wie im angehängten Bild ersichtlich.
(natürlich gibt es auch noch andere Einstellungen, jedoch denke ich, ist 
das forwarding das wichtigste?)

Danke!

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Wie wärs mit der Einstellung zu "Lookup directly if ..."?

von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wie wärs mit der Einstellung zu "Lookup directly if ..."?

Das klingt für mich aber so, als würden dann die internen Einträge 
genutzt werden. Diese möchte ich jedoch nicht verwenden.

Ich möchte eigentlich Bind garnicht verwenden, da ich jedoch webmin mit 
virtualmin verwende, ist bind nunmal dabei.

Ich möchte eigentlich nur, dass alle Anfragen an Bind an die forwareds 
geleitet werden.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Holger schrieb:
>> Wie wärs mit der Einstellung zu "Lookup directly if ..."?
>
> Das klingt für mich aber so, als würden dann die internen Einträge
> genutzt werden.

Es könnte aber auch bedeuten, dass er den Job dann selbst ohne Forwarder 
macht, also Root-Server anklappern etc. Ausprobieren statt Kaffeesatz.

Was passiert beispielsweise, wenn bei obiger Einstellung als Forwarder 
Müll drinsteht? Wenns dann immer noch funktioniert, vielleicht 
langsamer, dann macht er die Lookups mindestens ab diesem Fall selber 
und du siehst sie sofort in der Firewall.

: Bearbeitet durch User
von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Antwort.

Hab die Einstellung nun einmal auf yes gesetzt und schaue, ob das 
Problem weiterhin auftritt.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Wenn es das ist, was ich vorhin spekulierte, dann wird "yes" nichts 
ändern, weil das in bestimmten Fällen schon bisher der Fall war. Probier 
lieber das, was ich 09:01 schrieb, das merkst du sofort, nicht erst nach 
Stunden oder Tagen.

Stellst du das auf "no", muss er die Forwarder verwenden. Kommt er da 
nicht durch, funktioniert die Namensauflösung allenfalls noch aus dem 
Cache, aber keine neuen Anfragen.

: Bearbeitet durch User
von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Antwort.

Ich bin nun nochmals etwas tiefer eingestiegen und hab mal den Syslog 
geöffnet. Scheint mir ein anderes Problem zu bestehen.

Schaut mal die Logs:
1
Jun  9 19:41:22 dtbsrv1 named[25518]: network unreachable resolving '9anike.com/AAAA/IN': 2001:503:a83e::2:30#53
2
Jun  9 19:41:22 dtbsrv1 named[25518]: network unreachable resolving 'asymmetrictrader.com/A/IN': 2001:503:a83e::2:30#53
3
Jun  9 19:41:22 dtbsrv1 named[25518]: network unreachable resolving 'traineau-chiens-canada.com/A/IN': 2001:503:a83e::2:30#53
4
Jun  9 19:41:22 dtbsrv1 named[25518]: network unreachable resolving 'buysellamerica.com/AAAA/IN': 2001:503:a83e::2:30#53
5
Jun  9 19:41:22 dtbsrv1 named[25518]: network unreachable resolving 'borislelay.com/AAAA/IN': 2001:503:a83e::2:30#53
6
Jun  9 19:41:22 dtbsrv1 named[25518]: network unreachable resolving 'hbbwjiancai.com/A/IN': 2001:503:a83e::2:30#53
7
Jun  9 19:41:22 dtbsrv1 named[25518]: network unreachable resolving 'heydarlinboutique.com/A/IN': 2001:503:a83e
8
...

Tausende solcher einträge. Es werden stetig neue hinzugefügt.
Wenn ich Bind beende, hören auch diese Antragen auf.
Nun frage ich mich: ruft Bind diese Adressen selbst ab, oder läuft etwas 
auf der Kiste, welche diese Anfragen durchführt?

Hat jemand eine Idee, wie ich hier weitere Forschung betreiben könnte?
Bzw. herausfinden kann, welchen Ursprung diese Anfragen sind?

Danke

von Mario M. (thelonging)


Bewertung
0 lesenswert
nicht lesenswert
Vermutlich betreibst Du einen öffentlichen DNS-Resolver. Lass den BIND 
ausgeschaltet und trage die externen DNS-Server in die 
Netzwerk-Konfiguration ein.

von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mario M. schrieb:
> Vermutlich betreibst Du einen öffentlichen DNS-Resolver. Lass den
> BIND
> ausgeschaltet und trage die externen DNS-Server in die
> Netzwerk-Konfiguration ein.

Leider geht die Flut auch weiter nach dem deaktivieren von Bind

von Thomas O. (kosmos)


Bewertung
0 lesenswert
nicht lesenswert
kommen die Anfragen alle von 2001:503:a83e::2:30? Kannst du diese IP 
komplett blocken?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Holger schrieb:
> Wenn ich Bind beende, hören auch diese Antragen auf.

Holger schrieb:
> Leider geht die Flut auch weiter nach dem deaktivieren von Bind

???

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:
> kommen die Anfragen alle von 2001:503:a83e::2:30? Kannst du diese IP
> komplett blocken?

Falsche Richtung. Das ist a.gtld-servers.net und damit das Ziel der 
Anfrage.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Holger schrieb:
>> Wenn ich Bind beende, hören auch diese Antragen auf.
>
> Holger schrieb:
>> Leider geht die Flut auch weiter nach dem deaktivieren von Bind
>
> ???

Dachte ich zuerst auch. Aber die Anfragen erscheinen nur nicht mehr im 
syslog. Die Firewall erkennt jedoch weiterhin tausende DNS anfragen und 
meldet: session exceeded.

Nethogs liefert folgendes:
1
   ? root     192.168.50.20:42002-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
2
      ? root     192.168.50.20:41996-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
3
      ? root     192.168.50.20:41990-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
4
      ? root     192.168.50.20:41986-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
5
      ? root     192.168.50.20:41982-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
6
      ? root     192.168.50.20:41932-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
7
      ? root     192.168.50.20:41930-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
8
      ? root     192.168.50.20:41922-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
9
      ? root     192.168.50.20:41920-8.8.8.8:53                                                                                            0.000       0.000 KB/sec
10
      ? root     192.168.50.20:49060-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
11
      ? root     192.168.50.20:49058-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
12
      ? root     192.168.50.20:49056-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
13
      ? root     192.168.50.20:49054-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
14
      ? root     192.168.50.20:49052-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
15
      ? root     192.168.50.20:49050-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
16
      ? root     192.168.50.20:49048-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
17
      ? root     192.168.50.20:49046-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
18
      ? root     192.168.50.20:49044-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
19
      ? root     192.168.50.20:49042-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
20
      ? root     192.168.50.20:49040-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
21
      ? root     192.168.50.20:49038-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
22
      ? root     192.168.50.20:49036-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
23
      ? root     192.168.50.20:49034-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
24
      ? root     192.168.50.20:49032-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
25
      ? root     192.168.50.20:49030-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
26
      ? root     192.168.50.20:49028-178.32.204.230:7000                                                                                   0.014 0.012 KB/sec
27
      ? root     192.168.50.20:49026-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
28
      ? root     192.168.50.20:49024-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
29
      ? root     192.168.50.20:49022-178.32.204.230:7000                                                                                   0.014       0.012 KB/sec
30
      ? root     192.168.50.20:49020-178.32.204.230:7000

Ich würde gerne herausfinden, was auf dem Server diese Anfragen 
durchführt.
Kennt jemand ein Tool dazu?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Hast du überhaupt IPv6 am Internet-Anschluss? Wenn nicht, kannst du 
Meldungen wie "network unreachable" mit IPv6 Zieladresse ignorieren.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Hast du überhaupt IPv6 am Internet-Anschluss? Wenn nicht, kannst
> du
> Meldungen wie "network unreachable" mit IPv6 Zieladresse ignorieren.

Nein, ich habe IPv6 deaktiviert.
Die Firewall für IPv6 ist zwar aktiv. blockiert jedoch allen Traffic.
Abgesehen davon habe ich kein IPv6 beim Internet.

Die Frage ist halt, was auf dem Server verursacht all diese DNS 
anfragen.

von Mario M. (thelonging)


Bewertung
0 lesenswert
nicht lesenswert
Hast Du vielleicht in irgendwelchen Logfiles oder Regeln ein 
Reverse-Lookup aktiviert, dass er jede zugreifende IP per rDNS in einen 
Hostnamen umwandeln muss?

von Sven L. (sven_rvbg)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ich würde gerne herausfinden, was auf dem Server diese Anfragen
> durchführt.
> Kennt jemand ein Tool dazu?

netstat ?

Ich würde mal den DNS-Serverdienst beenden und schauen, ob die Anfragen 
immernoch kommen, weil irgend ein Programm es direkt versucht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.