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.
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.
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.
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.
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.
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.
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.
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.
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
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:
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.
dns_sessions.PNG
(20 KB)
dns_sessions2.PNG
(42 KB)
