Internet Langsam - DNS Anfragen - Trojaner

langsamer DSL Upload

Seit ein paar tagen stellen ich fest, dass unser Internet extrem langsam ist.

bei einer speedmessung mit www.wieistmeineip.de/speedtest kommt ich auf Geschwindigkeiten von 3kb/sec bei einer DSL 3000.

Der Anschluss ist ok, beim Download gibt es auch nichts auffälliges.

Zuerst hatte ich ja zugegeben die Telekom in Verdacht.

wir haben einen Domänenserver, der wiederum einen Linux Proxy und Linux DNS hat.

Auf dem Linux DNS habe ich mit netstat -tanup mal geprüft, das da aktuell läuft.

Und da konnte ich ca. 200 Verbrindungen unseren Domänenservers mit dem Linux auf Port 53 feststellen.

Also auf dem Domänes DNS die Protokollierung aktiviert und nun hatte ich das Problem. Eine Windowsmaschine produziert hier laufend DNS Abfragen. Dies scheint so heftig zu sein, dass im kompletten Netzwerk bzgl. des Internets fast nichts mehr geht.

Ich stelle mir daher 2 Fragen:

1.) Ursache und 2.) Absicherung für die Zukunft

1.)Wie kann ich an der Windowsmaschine festellen, welcher Prozess mein Problem ist. (Auf der Maschine ist ein aktueller Virenscanner aktiv. Skybot findet keine Fehler, ebenso Windows Defender)

2.) Kann ich die Anzahl der DNS Abfragen einer IP auf dem Domaenen DNS begrenzen

2a) Kann ich den DNS auf dem Linux so konfigurieren, dass der DNS nicht den kompletten Upstream runiert.

Für alle Hinweise dankbar.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 53142

Url: https://administrator.de/contentid/53142

Ausgedruckt am: 22.11.2024 um 17:11 Uhr

10 Kommentare

Neuester Kommentar

Hi,
also ich kann dir nur was zu 1.) sagen.

Es stellt sich die Frage, ab wann die DNS-Flut los geht:

1.) Computer hochgefahren bis zum Anmeldebildschirm
2.) Computer hochgefahren und angemeldet, aber nichts anderes manuell gestartet
3.) Computer hochgefahren, angemeldet und bestimmte Programme offen.

Am besten auf dem beroffenen Rechner "Wireshark" (früher Ethereal) installieren. Somit siehst du zwar den Traffic vom Netz, aber einen "IP Source" (Quelladresse) kannst du du die Einträge auf deinen Host minimieren.

Ansonsten vielleicht mal im TaskManager nachsehen. Dort würde ich auf die Namen achten. Ob dir ein Dienst auffällt, der wo anders nicht vorhanden ist. Dieses Verfahren kannst du aber nur durchziehen, wenn beide Rechner die gleichen Programme haben.

Nebenher vielleicht auf die CPU-Last achten. Bei bestimmten Prozessen weißt du ja, ob dieser im aktuellen Zustand, so viel Leistung zieht.
Zu guter letzt, würde ich einen anderen Virenscanner installieren.

Grüße
Dani

Hallo h25!
Zuerst sollte man doch mal den Traffic auswerten und schauen was da an Paketen gesendet wird -und wohin; z.B. mit NetworkActiv PIAFCTM v2.2, info und download unter:
http://www.networkactiv.com/PIAFCTM.html
Zu den Prozessen: Process Explorer for Windows v10.21
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Proce ...

Zu Frage 2+2.a.: Zum Thema DNS Anfragen begrenzen, Kapitel 6, Titel:Domain Name Services absichern:
http://www.oreilly.de/catalog/linuxss2ger/chapter/ch06.pdf
z.B.
-Die Anzahl der moeglichen, gleichzeitigen Verbindungen begrenzen
oder
-Bandweite begrenzen
oder
-IP - Adressen fest einstellen

saludos
gnarff

An das Microsoft in der URL für den Process-Explorer werde ich mich wohl nur schwer gewöhnen...

Was auch noch interessant ist, ist das Programm "fport".
Hier wird gezeigt, welches Programm welchen Port belegt;
jeder Trojaner reißt sich normalerweise einen Port unter den Nagel.
Einfach alles ma lesen, ob ein Verzeichnis dabei is, welches suspekt erscheinen könnte.

Lonesome Walker

PS:
gnarff war mit der Dezimierung der Anfragen ja schneller...

Hallo Zusammen,

zunächst vielen Dank für die Infos. Zu Euren Anregungen ein paar Anmerkungen bzw. Nachfragen.

Auf dem betroffenen Rechner lief der McAfee Virenscanner. AVira habe ich nachinstalliert, beide fanden keinen Virus.

Um die Arbeitsfähigkeit des Netzes wieder herzustellen, habe ich die Maschine zunächst mal aus dem Netz genommen.

Ich werde die Maschine heute abend wieder ins Netzwerk hängen um den Fehler weiter einzugrenzen. Über die Ergebnisse werde ich hier berichten, so dass andere die ggf. das selbe Problem haben, darauf aufbauen können.

Wenn ich die Maschine wieder online stelle, wird diese zunächst den MS DNS Server belasten, dieser gibt die Anfragen an den Linux DNS (Suse 8.2 Bind 8.3x) weiter. Der Bind zwingt dann das Internet in die Knie.

Die Anleitung von gnarff über die Absicherung des DNS hilft leider nicht, hier finde ich nur Infos über die Absicherung der DNS nach aussen. Wie ich den Dienst aber gegen einen Attakte eines berechtigten PC´s absichern kann finde ich leider nicht.

Daher nochmals konkret die Nachfrage:

a.) Gibt es eine Möglichkeit den DNS Dienst von Windows 2003 Server so abzusichern, dass dieser z.B. nach x Anfragen pro Minute einer IP die IP block.

b.) gibt es eine Möglichkeit den Linux Bind Daemon abzusichern, dass dieser nicht die komplette Performance herunterzieht.

Zwischenstand

fport:

C:\Support\Fport-2.0>Fport.exe
FPort v2.0 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com

Pid Process Port Proto Path
1032 -> 135 TCP
4 System -> 139 TCP
1124 svchost -> 251 TCP C:\WINDOWS\System32\svchost.exe
4 System -> 427 TCP
4 System -> 445 TCP
2352 -> 1075 TCP
4 System -> 4924 TCP
1124 svchost -> 4926 TCP C:\WINDOWS\System32\svchost.exe
240 avguard -> 18350 TCP C:\Programme\AntiVir PersonalEdition Classi
c\avguard.exe

2352 -> 123 UDP
0 System -> 123 UDP
0 System -> 137 UDP
0 System -> 138 UDP
0 System -> 427 UDP
1032 -> 445 UDP
1124 svchost -> 500 UDP C:\WINDOWS\System32\svchost.exe
4 System -> 1026 UDP
240 avguard -> 1027 UDP C:\Programme\AntiVir PersonalEdition Classi
c\avguard.exe
2352 -> 1028 UDP
4 System -> 1029 UDP
240 avguard -> 1066 UDP C:\Programme\AntiVir PersonalEdition Classi
c\avguard.exe
240 avguard -> 1096 UDP C:\Programme\AntiVir PersonalEdition Classi
c\avguard.exe
4 System -> 1097 UDP
4 System -> 1098 UDP
4 System -> 1099 UDP
1124 svchost -> 1100 UDP C:\WINDOWS\System32\svchost.exe
1124 svchost -> 1101 UDP C:\WINDOWS\System32\svchost.exe
4 System -> 1102 UDP
4 System -> 1103 UDP
0 System -> 1248 UDP
0 System -> 1900 UDP
1032 -> 4500 UDP
0 System -> 4826 UDP
0 System -> 4942 UDP

NetworkActiv liefert mir eine neue Erkenntnis.

Die Maschine macht nicht nur DNS Anfragen, sondern versucht sich als SPAM Schleuder.

Sobald ich Port 25 nach extern offen habe, ist im NetworkActiv die Hölle los.
Die Kiste versucht sofort externe Ip´s auf Port 25 zu erreichen.

Mit Kaspersky.com habe ich die in Fport aufgelisteten Files geprüft. svchost .exe ist sauber.

Alle Tests des Systems zeigen keinen Fehler.

Auffällig noch die Auslastung der Maschine, diese geht bei aktiver Arbeit auf ca. 25% Cpu Last runter, wenn nichts gemacht wird, geht die Last auf 90% hoch, dabei belegen die Prozesse:

Winlogon.exe ca. 5%
DCPs ca. 20%

Solltest Ihr übrigens NetworkActiv runterladen, macht das in English. Die deutsche Übersetzung ist grauenhaft

Frage an Euch:
Wie kann ich den Prozess lokalisieren, der hier Unfug treibt.

Schon mal mit einem Rootkit-Scanner probiert?

Lonesome Walker

Hallo h25!
-NetworkActiv ist das von mir empfohlene PIAFCTM v2.2
-mach alle Ports, TCP/UDP dicht, die du nicht brauchst.
-benutze PIAFCTM v2.2, mit oder ohne Docu und analysiere endlich die Pakete und wohin sie gehen (IPs)!

zu b.)
5.7 Sichern von BIND

Es gibt verschiedene Dinge, mit denen Sie sich auseinander setzen sollten, um einen Domain-Server-Daemon abzusichern, die ähnlich zu den Überlegungen sind, wie man einen anderen Dienst absichert:

*

Konfigurieren Sie den Daemon selbst, so dass er von außen nicht missbraucht werden kann (siehe auch Bind-Konfiguration um Missbrauch zu verhindern, Abschnitt 5.7.1). Dies schließt das Einschränken von Abfragen durch Clients ein: Zonen-Transfers und rekursive Abfragen.

*

Einschränken des Zugriffs des Daemon auf den Server selbst, so dass dem Schaden für das System im Falle eines Einbruchs Grenzen gesetzt sind. Hierzu gehört auch, den Daemon als nicht-privilegierten Benutzer laufen zu lassen (siehe Ändern des BIND-Benutzers, Abschnitt 5.7.2) und ihn in ein Chroot-Gefängnis einzusperren (siehe Chroot-Gefängnis für Name-Server, Abschnitt 5.7.3).

5.7.1 Bind-Konfiguration um Missbrauch zu verhindern

Sie sollten einige Informationen, die von außen über den DNS-Server abgefragt werden können, zurückhalten, so dass man nicht wertvolle Informationen über Ihre Organisation, die Sie nicht herausgeben wollen, abfragen kann. Dies schließt die folgenden Optionen mit ein: allow-transfer, allow-query, allow-recursion und version. Sie können dies in dem globalen Abschnitt tun (so wird es auf alle Zonen angewandt) oder jeweils pro Zone. Dies ist im Paket bind-doc dokumentiert. Sobald das Paket installiert ist, können Sie hierzu mehr in /usr/share/doc/bind/html/index.html lesen.

Stellen Sie sich vor, Ihr Server ist mit dem Internet und Ihrem internen Netzwerk (Ihre interne IP ist 192.168.1.2) verbunden – ein einfacher Server im heimischen Netzwerk. Sie möchten keinen Dienst im Internet anbieten und lediglich DNS-Abfragen von Ihren internen Rechnern erlauben. Sie können dies einschränken, indem Sie Folgendes in Ihre /etc/bind/named.conf aufnehmen:

 options {
                 allow-query { 192.168.1/24; } ;
                 allow-transfer { none; } ; 
                 allow-recursion { 192.168.1/24; } ;
                 listen-on { 192.168.1.2; } ;
                 forward { only; } ;
                 forwarders { A.B.C.D; } ;
     };

Die Option listen-on bewirkt, dass sich DNS nur auf die Schnittstelle bindet, die die interne Adresse hat. Aber sogar wenn diese Schnittstelle Verbindung zum Internet hat (zum Beispiel weil Sie NAT benutzen), werden Abfragen nur akzeptiert, wenn sie von internen Hosts kommen. Wenn das System mehrere Schnittstellen hat und Sie kein listen-on gesetzt haben, könnten zwar nur interne Nutzer Abfragen starten, aber, da der Port für Angreifer von außen ansprechbar ist, könnten sie versuchen, den DNS zum Absturz zu bringen (oder durch Speicher-Überlauf-Attacken auszunutzen). Sie könnten ihn sogar dazu bringen, lediglich auf 127.0.0.1 zu hören, wenn Sie den DNS-Service nicht für ein anderes System anbieten wollen.

Der version.bind-Eintrag in der chaos class enthält die Version des derzeit laufenden Bind-Prozesses. Diese Information wird oft von automatischen Scannern und bösartigen Individuen dazu verwendet herauszufinden, ob ein bind für eine bestimmte Attacke verwundbar ist. Indem Sie falsche oder gar keine Informationen im version.bind-Eintrag zur Verfügung stellen, minimieren Sie die Wahrscheinlichkeit, dass jemand Ihren Server aufgrund der publizierten Version attackieren wird. Um Ihre eigene Version anzugeben, benutzen Sie die Version-Direktive in der folgenden Art:

options { ... verschiedene andere Optionen ...
version "Nicht verfuegbar."; };

Das Ändern des version.bind-Eintrags schützt eigentlich nicht gegen Attacken, aber Sie können es als sinnvolle Schutzvorrichtung ansehen.

Eine beispielhafte named.conf-Konfigurationsdatei könnte so aussehen:

 acl internal {
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // intern
             aa.bb.cc.dd;            // eth0 IP
     };
     
     acl friendly {
             ee.ff.gg.hh;            // slave DNS
             aa.bb.cc.dd;            // eth0 IP
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // intern
     };
     
     options {
             directory "/var/cache/bind";  
             allow-query { internal; };
             allow-recursion { internal; };
             allow-transfer { none; };
     };
     // Ab hier bis zur meineseite.bogus Zone 
     // ist alles im Grunde die unveränderte Debian-Standardeinstellung
     logging {
             category lame-servers { null; };
             category cname { null; };   
     };
     
     zone "." {  
             type hint;
             file "/etc/bind/db.root";  
     };
     
     zone "localhost" {  
             type master;
             file "/etc/bind/db.local";  
     };
     
     zone "127.in-addr.arpa" {  
             type master;
             file "/etc/bind/db.127";  
     };
     
     zone "0.in-addr.arpa" {  
             type master;
             file "/etc/bind/db.0";  
     };
     
     zone "255.in-addr.arpa" {  
             type master;
             file "/etc/bind/db.255";  
     };
     
     // Zone, die ich selbst hinzugefügt habe
     zone "meineseite.bogus" {  
             type master;
             file "/etc/bind/named.meineseite";  
             allow-query { any; };
             allow-transfer { friendly; };
     };

Bitte prüfen Sie (erneut) die Debian-Fehler-Datenbank (BTS) bezüglich Bind, insbesondere Bug #94760 (regarding ACLs on zone transfers). Fühlen Sie sich ruhig dazu ermutigt, zu diesem Bugreport beizutragen, wenn Sie glauben, nützliche Informationen hinzufügen zu können.
5.7.2 Ändern des BIND-Benutzers

Bezüglich der Beschränkung von BINDs Privilegien müssen Sie beachten, dass, wenn Sie BIND als nicht-root Benutzer laufen lassen, BIND neue Netzwerk-Schnittstellen nicht automatisch entdecken kann, zum Beispiel wenn Sie eine PCMCIA-Karte in Ihr Notebook stecken. Lesen Sie die Datei README.Debian in Ihrer named-Dokumentation (/usr/share/doc/bind/README.Debian) für mehr Informationen hierzu. Es gab in letzter Zeit viele Sicherheitsprobleme mit BIND, so dass es nützlich ist, den Benutzer zu wechseln, wenn es möglich ist. Wir werden die Schritte, die dazu nötig sind, detailliert aufführen. Wenn Sie dies automatisch machen lassen wollen, können Sie das Skript in Beispielskript, um die Standard-Installation von Bind zu ändern, Anhang E ausprobieren.

Um BIND unter einem anderen Benutzer laufen zu lassen, müssen Sie zunächst einen separaten Benutzer und eine separate Gruppe dafür erstellen (es ist keine gute Idee, für alle Dienste, die Sie nicht als root laufen lassen, den Benutzer nobody und die Gruppe nogroup zu benutzen). In diesem Beispiel wird der Benutzer und die Gruppe named benutzt. Sie können diese anlegen, indem Sie die folgenden Kommandos eingeben:

addgroup named
     adduser --system --home /home/named --no-create-home --ingroup named \
           --disabled-password --disabled-login named

Beachten Sie, dass der Benutzer named sehr eingeschränkt ist. Wenn Sie – aus welchen Gründen auch immer – ein weniger eingeschränktes Setup haben möchten, benutzen Sie:

adduser --system --ingroup named named

Editieren Sie nun /etc/init.d/bind mit Ihrem Lieblingseditor und ändern Sie die Zeile, die mit

start-stop-daemon --start

anfängt zu[44]:

start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

Ändern Sie die Rechte der Dateien, die von Bind verwendet werden, inklusive /etc/bind/rndc.key:

-rw-r----- 1 root named 77 Jan 4 01:02 rndc.key

und wo bind seine PID-Datei erzeugt, z.B. indem Sie /var/run/named anstatt von /var/run verwenden:

    $ mkdir /var/run/named
     $ chown named.named /var/run/named
     $ vi /etc/named.conf
     [ ... ändern Sie die Konfigurationsdatei, um diesen neuen Pfad zu verwenden ...]
     options { ...
             pid-file "/var/run/named/named.pid";  
     };

[ ... ]

Außerdem müssen Sie, um zu verhindern, dass irgendetwas als root läuft, die reload-Zeile auskommentieren:

reload)
/usr/sbin/ndc reload

und in Folgendes ändern:

reload)
$0 stop
sleep 1
$0 start

Beachten Sie: Abhängig von Ihrer Debian-Version, müssen Sie vielleicht auch die restart-Zeile ändern. Dies wurde in der Version 1:8.3.1-2 von Debians BIND-Paket repariert.

Alles, was Sie jetzt noch tun müssen, ist, bind mittels /etc/init.d/bind restart neu zu starten und dann Ihr Syslog auf zwei Einträge wie die folgenden zu prüfen:

Sep 4 15:11:08 nexus named[13439]: group = named
Sep 4 15:11:08 nexus named[13439]: user = named

Voilà! Ihr named läuft nicht mehr als root. Wenn Sie mehr Informationen darüber lesen wollen, warum BIND nicht als nicht-root Benutzer auf Debian-Systemen läuft, sehen Sie bitte in der Fehlerdatenbank zu Bind nach, insbesondere Bug #50013: bind should not run as root und Bug #132582: Default install is potentially insecure, Bug #53550, Bug #52745 und Bug #128129. Fühlen Sie sich ruhig dazu ermuntert, etwas zu den Fehlerbeschreibungen beizutragen, wenn Sie denken, nützliche Informationen hinzufügen zu können.
5.7.3 Chroot-Gefängnis für Name-Server

Um die größtmögliche BIND-Sicherheit zu erreichen, müssen Sie nun ein Chroot-Gefängnis (siehe Allgemeine chroot- und suid-Paranoia, Abschnitt 5.10) um Ihren Daemon herum bauen. Es gibt einen einfachen Weg, dies zu erreichen: Die Option -t (siehe die Handbuchseite named(8) oder Seite 100 von Bind's 9 Dokumentation (PDF)). Dies wird Bind selbst in ein bestimmtes Verzeichnis chrooten lassen, ohne dass Sie ein eigenes Chroot-Gefängnis aufsetzen und sich Sorgen um dynamische Bibliotheken machen müssen. Die einzigen Dateien, die in diesem Chroot-Gefängnis benötigt werden, sind:

 dev/null
     etc/bind/       - sollte die named.conf und alle Server-Zonen enthalten
     sbin/named-xfer - wenn Sie Namen transferieren
     var/run/named/  - sollte die PID und den Cache des Name-Servers (falls es
                       ihn gibt) enthalten. Dieses Verzeichnis muss für
                       den named-User schreibbar sein.
     var/log/named   - Wenn Sie in eine Datei protokollieren, muss dies
                       für den named-User schreibbar sein.
     dev/log         - syslogd sollte hierauf hören, wenn named so
                       konfiguriert ist, dass er darüber protokolliert.

Damit Ihr Bind-Daemon vernünftig läuft, braucht er bestimmte Zugriffsrechte auf die named-Dateien. Dies ist eine einfache Angelegenheit, da die Konfigurationsdateien immer in /etc/named/ liegen. Beachten Sie, dass er lediglich Lesezugriff benötigt, es sei denn, es handelt sich um einen sekundären oder zwischenspeichernden (Cache) Name-Server. Wenn dies der Fall ist, müssen Sie ihm Lese- und Schreibzugriff auf die notwendigen Zonen gewähren (damit Zonen-Transfers vom primären Server funktionieren).

Mehr Informationen über das Chrooten von Bind finden Sie unter Chroot-BIND-HOWTO (betrifft Bind 9) und Chroot-BIND8-HOWTO (betrifft Bind 8). Diese Dokumente sollten auch nach der Installation des Paketes doc-linux-text (Text-Version) oder doc-linux-html (HTML-Version) verfügbar sein. Ein anderes nützliches Dokument ist http://web.archive.org/web/20011024064030/http://www.psionic.com/papers ....

Wenn Sie für Bind ein komplettes Chroot-Gefängnis aufsetzen (d.h. Sie benutzen nicht nur -t), stellen Sie sicher, dass Sie die folgenden Dateien darin haben:[45]

 dev/log -  syslogd sollte hierauf hören
     dev/null
     etc/bind/named.conf 
     etc/localtime
     etc/group - mit einer einzigen Zeile: "named:x:GID:"  
     etc/ld.so.cache - mit ldconfig erstellt   
     lib/ld-2.1.3.so
     lib/libc-2.1.3.so
     lib/ld-linux.so.2 - symbolischer Link auf ld-2.1.3.so
     lib/libc.so.6 - symbolischer Link auf libc-2.1.3.so
     sbin/ldconfig - kann gelöscht werden, nachdem Chroot aufgesetzt wurde
     sbin/named-xfer - wenn Sie Namen transferieren
     var/run/

Sorgen Sie auch dafür, dass syslogd auf $CHROOT/dev/log achtet, so dass der Name-Server seine syslog-Einträge in das lokale System-Protokoll schreiben lassen kann.

Wenn Sie Probleme mit dynamischen Bibliotheken vermeiden wollen, können Sie Bind statisch kompilieren. Sie können hierzu apt-get mit der source Option benutzen. Es kann sogar die Pakete herunterladen, die Sie zum Kompilieren benötigen. Sie müssten etwas ähnliches wie das Folgende tun:

 $ apt-get source bind
     # apt-get build-dep bind
     $ cd bind-8.2.5-2
     (editieren Sie src/port/linux/Makefile, so dass CFLAGS die Option
     '-static' beinhaltet)  
     $ dpkg-buildpackage -rfakeroot -uc -us
     $ cd ..
     # dpkg -i bind-8.2.5-2*deb

Nach der Installation werden Sie die Dateien in das Chroot-Gefängnis verschieben müssen.[46] Sie können die init.d-Skripte in /etc/init.d lassen, so dass das System automatisch den Name-Server starten wird, aber editieren Sie sie, indem Sie bei den start-stop-daemon Aufrufen in diesen Skripten --chroot /location_of_chroot hinzufügen.

Für weitere Informationen wie man Chroot-Gefängnisse aufsetzt, siehe Allgemeine chroot- und suid-Paranoia, Abschnitt 5.10.

FIXME: Füge Informationen aus folgenden Quellen ein: http://people.debian.org/~pzn/howto/chroot-bind.sh.txt, http://www.cryptio.net/~ferlatte/config/ (Debian-spezifisch), http://web.archive.org/web/20021216104548/http://www.psionic.com/papers ... und http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm.

zu a.)
hast Du das so eingerichtet?
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/libra ...
und
http://www.windowsitpro.de/themen/messaging-groupware/article.html?thes ...

Bandweitenbegrenzung:

@lsw:
Wir haben vor 2 Monaten mal die gebraeuchlichste Rootkitscanner gestestet und sind zu dem Ergebnis gekommen: Alles Mist!
Nicht mal 10 % Trefferquote, selbst bei den aeltesten Rootkits.
Von Hand suchen und entfernen ist angesagt oder, wenn man das gute Stueck nicht mit 100% iger Sicherheit bestimmen kann - alles neu aufsetzen...Mahlzeit!

Ja, h25, hast Du das Problem nun in den Griff bekommen oder nicht!
Ich schreib nicht eher weiter, bis dass ich von Dir eine vernuenftige Rueckmeldung bekommen habe...
saludos
gnarff

Hallo gnarff,

mit Deiner letzten Mail hast Du mach quasi Mundtot geschreiben!

Problem zwischenzeitlich dahingehend gelöst, dass ich die Maschine eine neue Platte eingebaut habe und Windows neu installiert habe.

Die "alte Platte" ist noch für Testzwecke jederzeit nutzbar.

Was habe ich gemacht:

1.) Mein DNS Server auf dem Linux Bind 8.3x war bereits gem. deiner Anleitung konfiguriert.

Deine Einstellungen regeln ja nur, wer den DNS nutzen darf. Da die Maschine ja im lokalen Netzwerk steht hilft diese Begrenzung nicht weiter.

PC ------ Windows2003 Server mit DNS -----Linux Bind----- Internet

Der PC flutet den Windows2003 Server, dieser hat als Weiterleitung den Linux und dieser geht in die Knie, bzw. die Linie mit der geringsten Bandbreite = Internet.

2.) Rootkit scanner laufen lassen, keine Ergebnisse

3.) PIAFCTM zeigt mir DNS Anfragen zum Windowsserver

4.) Auf dem Windows 2003 Server die rekursion gem dem Link von Dir deaktiviert. Dan läuft aber auch die Weiterleitung nicht mehr, und der DNS funktioniert nur noch intern

Da die Firewall Port 25 nach extern für die PCs des LANs geblockt hat geht da nichts. Ich sehe nach dem Neustart den Versuch auf Port 25 zu beliebigen IP´s zu kommen, das bescheidene Ding stellt aber dieser Versuche nach ca. 30 Sec ein, und führt dann DNS anfragen durch.

Ich habe testweise den Port 25 nach extern mal geöffnet, dann wird diese Maschine sofort zu Spamkiste.

Die Maschine von dem Übel zu befreien ist, nachdem ich die neue Platte eingebaut habe rein akademisch, und daher auch nicht mehr zeitkritisch.

Was mich aber viel mehr interessiert, ist das Thema wie stelle ich in meinem Netzwerk sicher, dass sollte dies mal wieder passieren, nicht zu einem kolabierenden Netzwerk führt.

Nachdem ich mich über das Ding zuerst geärgert habe, kann ich nun relativ einfach durch Plattentausch mein Netzwerk auf Anfälligkeit testen.

Wenn Du hier noch Ideen und Tipps hast, wie ich die DNS Dienste sicherer konfiguriere bin ich sehr dankbar.

Hallo h25!
wollte Dich nicht zum schweigen bringen...

[quote="h25"]Der PC flutet den Windows2003 Server[/quote]
-ja, das ist genau der Punkt, WELCHER; wer ist denn "Der PC"?

[quote="h25"]Was mich aber viel mehr interessiert, ist das Thema wie stelle ich in meinem Netzwerk sicher, dass sollte dies mal wieder passieren, nicht zu einem kolabierenden Netzwerk führt.

1. Eigene Posstelle mit physisch vorhandenem Mailserver einrichten.
2. Einschränken der DNS-Server-Abfragen auf ausgewählte Adressen:
https://thesource.ofallevil.com/technet/prodtechnol/windowsserver2003/de ...

3. Vernuenftige Umsetzung eines Sicherheitsmodells wie z.B nach Bell-La Padula oder nach dem Clark Wilson Modell.
Fuehre Dir doch mal zum besseren Verstaendnis das "Orange Book" zu Gemuete:
http://csrc.nist.gov/publications/history/dod85.pdf

3. Private Mail-Accounts verbieten

4. Mitarbeitern den Zugriff auf das Internet verbieten oder stark einschraenken.

5. Alle unnoetigen Dienste die noch von BIND benutzt werden -abschalten

6. Ein brauchbares Netzwerkmonitoring implementieren mit eigenem Logserver

Moeglichkeiten und Grundlagen eines Bandwith-Managments:
-Realisierung eines QoS in IP-Netzen durch:
Auf der theoretischen Ebene kann QoS durch Priorisierung oder Parametrisierung des Datenverkehrs, Datenratenreservierung, Datenratenlimitierung und Paketoptimierung realisiert werden. Technisch gesehen existieren dafür zwei Mechanismen:

Entweder man meldet anstehende Datenflüsse bei allen aktiven Netzwerkkomponenten (Router etc.) an und reserviert die benötigte Datenrate (Integrated Services, IntServ (en:Integrated services)),
oder man markiert alle Datenpakete und die aktiven Netzwerkkomponenten behandeln/bevorzugen die Pakete entsprechend ihrer Markierungen (Differentiated Services, DiffServ (en:Differentiated services)).