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.
Angehängte Dateien:
-
dns_sessions.PNG
20 KB -
dns_sessions2.PNG
42 KB
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
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
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.
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
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.
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.
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
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?
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.
Du hast auf irgendeiner Windows-Möhre einen Trojaner oder so drauf, der irgendwelche DNS-Anfragen durch-scannt.
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. |
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.
Angehängte Dateien:
-
bind.PNG
47 KB
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!
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.
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
Danke für deine Antwort. Hab die Einstellung nun einmal auf yes gesetzt und schaue, ob das Problem weiterhin auftritt.
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
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
Vermutlich betreibst Du einen öffentlichen DNS-Resolver. Lass den BIND ausgeschaltet und trage die externen DNS-Server in die Netzwerk-Konfiguration ein.
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
kommen die Anfragen alle von 2001:503:a83e::2:30? Kannst du diese IP komplett blocken?
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 ???
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.
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?
Hast du überhaupt IPv6 am Internet-Anschluss? Wenn nicht, kannst du Meldungen wie "network unreachable" mit IPv6 Zieladresse ignorieren.
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.
Hast Du vielleicht in irgendwelchen Logfiles oder Regeln ein Reverse-Lookup aktiviert, dass er jede zugreifende IP per rDNS in einen Hostnamen umwandeln muss?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.