Neues in der Kategorie Netzwerk
Wer auf ein Netzlaufwerk von seinem Windows 7 Rechner aus zugreifen will, kann unter Umständen auf folgende Fehlermeldung stoßen:
Auf \\NETZLAUFWERK kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, diese Netzwerkressource zu verwenden. Wenden sie sich an den Administrator des Servers, um herauszufinden, ob Sie über Berechtigungen verfügen.
Netzwerkfehler (1208)
Dann sollte man zunächst versuchen, ob man direkten Zugriff auf einen der Ordner oder der Unterordner des fremden Netzlaufwerkes erhält. Zum Beispiel unter "Start->Ausführen" folgendes eingeben:
\\COMPUTERNAME-ODER-IPADRESSE\ORDNER
Bei wem diese Methode nicht zum gewünschten Ziel führt, dem sei folgender Artikel empfohlen:
http://www.winsupportforum.de/forum/windows-7-netzwerk/6623-netzwerkverbindung-zu-nas.html#post39618
Dort erfährt man, dass seit Windows Vista von den Billy-Boys eine veränderte Netzwerkauthentifizierung eingebaut wurde, so dass es bei einer Authentifizierung zu Problemen kommen kann.
Ein weitere Link zu einem anderen Forum mit der selben Diskussion findet sich hier:
http://answers.microsoft.com/de-de/windows/forum/windows_7-networking/kein-zugriff-auf-externe-festplatte-im-netzwerk/7f2869c0-4161-4bd1-a011-e1113cc32afc
Auf Heise kann man einen tollen Artikel im Rahmen der Reihe "Tatort Internet" zum Thema DDoS lesen. Dabei wird aus Sicht eines Admins ein Angriff beschrieben und erläutert, welche Gegenmaßnahmen er ergreift bis hin zur Verurteilung des Täters.
Hier der Link zum Artikel:
http://www.heise.de/security/artikel/Tatort-Internet-Nach-uns-die-SYN-Flut-1285780.html
Um einen Linux-Rechner als Router oder Gateway für ein Netzwerk zu nutzen, ist ein Schalter im Kernel oder besser gesagt im proc-Verzeichnis ganz wichtig. Und zwar der Schalter, der das Forwarden von Paketen erlaubt.
Aktiviert wird das Forwarding für iptables mit folgendem Befehl:
echo "1" > /proc/sys/net/ipv4/ip_forward
Die 1 bewirkt, dass unser Server oder Router ab sofort Pakete weiterleiten kann. Sollte dieser Schalter nicht umgelegt werden, so sind alle Maskierungseinstellungen und Port-Weiterleitungen wirkungslos und es kann zu Problemen kommen.
Eine Auflistung welche Schaltereinstellungen es gibt und wie diese zur Sicherheit eines Linux-Betriebssystems beitragen, findet sich hier:
http://www.online-tutorials.net/security/ein-sicheres-linux-system-aufsetzen-teil-20-linux-mit-proc-hrten/tutorials-t-69-219.html
Wer wissen möchte, ob eine E-Mail mit einer so genannten Empfangs- oder Lesebestätigung versehen ist, der kann dies ganz leicht im Header tun. Hier muss nämlich folgender Eintrag stehen:
Disposition-Notification-To: mail@mail.de
Dies ist der Standard-Eintrag den die IETF in RCF 3798 vorgibt. Alternativ exisiteren aber noch folgende beide Formen:
X-Confirm-Reading-To: mail@mail.de
oder
Return-Receipt-To: mail@mail.de
Dies liegt an den verschiedenen E-Mail-Programmen, welche zum Teil eigene Standards verwenden.
Wie das ganze mit der Lesebestätigung funktioniert findet man auf Wikipedia und im zugehörigen RFC der Internet Engineering Task Force:
http://de.wikipedia.org/wiki/Message_Disposition_Notification (deutsch)
http://en.wikipedia.org/wiki/E-mail_tracking (englisch)
http://www.ietf.org/rfc/rfc3798.txt (englisch)
AWStats ist ein einfaches Tool um Weblogs auswerten zu können. Unter Debian kann man es ganz einfach mit dem apt-get-Befehl installieren:
apt-get install awstats
Konfiguration:
Ist das Programm installiert, kann man sich über zwei Wege an die Konfiguration machen. Entweder nutzt man die "awstats_configure.pl" unter "/usr/share/doc/awstats/examples/" oder man erledigt alles kurz von Hand. Der erste Weg ist mit einer Menge Anleitungen unten bei den Links beschrieben. Da dies aber immer auch mit Problemen verbunden ist, wurde der manuelle Weg gewählt (z.B. existiert das beschriebene wwwroot-Verzeichnis aus den Anleitungen nicht, weswegen man dann so Fehler wie Error: Failed to open '/usr/share/doc/awstats/examples/wwwroot/cgi-bin/awstats.model.conf' for read. bekommt).
Zunächst geht man in das Verzeichnis "/etc/awstats" und führt folgenden Befehl aus:
cp awstats.conf awstats.www.meindomain.de.conf
Nun kan man die neue Konfigurationsdatei "awstats.www.meindomain.de.conf" anpassen. Die wichtigsten Parameter die hier anzupassen sind, sind folgende: LogFile, LogFormat und SiteDomain. Bei LogFormat muss man etwas vorsichtig sein. Eigentlich sollte man hier eine "1" angeben, damit alles mit dem Apache konform ist. Allerdings zeigte sich im Test, dass hier die "4" gewählt werden musste. Alle anderen Schalterchen sind in der Dokumentation gut beschrieben und sind zum teil selbsterklärend oder kommentiert.
Da viele Benutzer ein eignes CGI-Verzeichnis bevorzugen und auch keine Lust haben, den Apache auf ein allgemeines Verzeichnis einzurichten, sollte folgender Befehl ausgeführt werden:
cp /usr/lib/cgi-bin/awstats.pl /MEINPFAD/MEIN-CGI-VERZEICHNIS/awstats.pl
Aus Sicherheitsgründen sollte man die awstats.pl per htaccess schützen, da sonst jeder unserer Statistiken aufrufen kann. Wie das funktioniert findet man bei http://www.undertec.de/blog/2008/10/htusers-passwort-per-crypt-ver.html und http://de.selfhtml.org/servercgi/server/htaccess.htm#verzeichnisschutz. Ein Beispiel für eine ".htaccess"-Datei kann so aussehen:
# .htaccess-Datei für Web-Verzeichnis /private
AuthType Basic
AuthName "Geschützter Bereich"
AuthUserFile /PFAD-ZUR-HTUSERS/.htusers<Files awstats.pl>
Require user BENUTZER
</Files>
Nun muss auf der Kommadozeile noch die Daten für AWStats erzeugen, da momentan noch keine vorhanden sind:
perl awstats.pl -config=www.MEINE-DOMAIN.de -update
Danach kann im Browser den ersten Aufruf wagen:
http://www.MEINE-DOMAIN/MEIN-CGI-VERZEICHNIS/awstats.pl
(Nicht zu vergessen Benutzernamen und Passwort eingeben)
Icons einbinden:
Einen kleine Schönheitfehler gibt es noch: Es werden keine Icons in AWStats dargstellt. Dies kann man beheben in dem man in seiner Apache-Konfiguration unter "/etc/apache2/httpd.conf" folgende Zeilen hinzufügt:
Alias /awstatsicons "/usr/share/awstats/icon/"
<Directory "/usr/share/awstats/icon">
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Nun muss man nur noch den Apache neustarten:
/etc/init.d/apache2 restart
Cron zur Aktualisierung nutzen:
Wer jetzt noch "Cron" nutzen will, um seine Statistiken regelmäßig zu aktualisieren, der kann unten bei den Links Hilfe finden. Im Normalfall wird bei der Installation ein automatischer Cron-Job erstellt, der aber noch ein wenig angepasst werden muss.
Fazit:
AWStats ist ein tolles Tool; leider sind bei der Installtion/Konfiguration für Debian noch etliche Lücken. Zum Beispiel funktionieren die Anleitungen bei den Links unten alle nicht mehr exakt. Die manuelle Konfiguration wie oben beschrieben verläuft aber problemlos.
Projektseite von AWStats:
http://awstats.sourceforge.net
Wikipedia-Artikel zu AWStats:
http://de.wikipedia.org/wiki/AWStats
Installationsanleitungen mit awstats_configure.pl:
http://www.debian-administration.org/articles/277
http://www.debianhelp.co.uk/awstats.htm
http://www.debianadmin.com/apache-log-file-analyzer-using-awstats-in-debian.html#
Weitere Anleitungen:
http://www.webmaster-homepage.de/82.0.html
http://www.ponnath-webdesign.de/2006/11/09/hallo-welt/
Eines von vielen Internet-Tools die einem helfen, IP-Adressen geografisch zu lokalisieren ist "ip-adress.com". Auf einer Google-Karte bekommt man den ungefähren Standort der IP-Adresse mitgeteilt und auch noch ein paar andere Informationen. Natürlich klappt das ganze nicht nur mit der eigenen IP-Adresse, sondern auch mit fremden Adressen.
Startseite von ip-adress.com:
http://www.ip-adress.com
Direkter Link zu den ausführlichen Tools:
http://www.ip-adress.com/ip_lokalisieren/
Ganz nett ist auch die Funktion, bei der man sich die geografische Distanz zweier IP-Adressen anzeigen lassen kann. So kann man doch gleich die Route zum nächsten Spammer bestimmen :)
Wer per Skript zum Beispiel Dateien per SCP verschieben möchte, wird vor das schier unlösbare Problem gestellt, dass er beim Anmelden an einem fremden Rechner zwingend sein Passwort angeben muss. Lösen lässt sich dieses Problem, in dem man Schlüsseldateien verwendet. Beachten sollte man hierbei allerdings aber, dass das Hinterlegen von Zugangsschlüsseln zur Automatisierung ein erhebliches Risiko darstellt. Denn wurde ein Rechner infiltriert, so kann das andere System sehr schnell ebenfalls zum Ziel einer Attacke werden.
In aller Kürze geht man zur Schlüsselgenerierung auf dem eigenen Server wie folgt vor. Einfach folgende Zeile zur Erzeugung der Schlüssel in der Kommandozeile eingeben:
ssh-keygen -t dsa
oder wahlweise
ssh-keygen -t rsa
Die Abfragen die nun folgen, sollten leer bleiben, damit man später keine Passphrase eingeben muss. Also alle Abfragen mit "Enter" absegnen. Ob man DSA oder RSA nimmt, hängt davon ab, wieviel Vertrauen man in die jeweilige Verschlüsselung hat.
Durch diese beiden Befehle wurden jetzt Schlüssel für den entsprechenden Nutzer, in Kombination mit der IP-Adresse bzw. des Namens unseres Servers generiert. Der öffentliche Schlüssel heißt dann zum Beispiel "id_dsa.pub" und der private Schlüssel "id_dsa". Beide liegen nun im jeweiligen Benutzerverzeichnis im Ordner ".ssh".
Nun wird der öffentliche Schlüssel "id_dsa.pub" auf den fremden Rechner in das Benutzerverzeichnis in den Ordner ".ssh" kopiert (falls der Ordner nicht existiert einfach mit "mkdir .ssh" anlegen):
scp /home/BENUTZER/.ssh/id_dsa.pub BENUTZER@192.168.0.0:/home/
BENUTZER/.ssh/
Berechtigung der Datei auf dem fremden Rechner ändern:
chmod 700 /home/BENUTZER/.ssh/id_dsa.pub
Und nun muss diese Datei auf dem fremden Rechner noch in die Liste authorisierter Schlüssel kopiert werden:
cat /home/BENUTZER/.ssh/id_dsa.pub >> authorized_keys
Versucht man sich nun per SSH am fremden System anzumelden, so wird man kein Passwort mehr benötigen.
Zwei gute Anleitungen zu dem Thema finden sich auch hier:
http://www.linux-fuer-alle.de/doc_show.php?docid=233&catid=16
http://www.schlittermann.de/doc/ssh.html
Zu den Verschlüsselungsverfahren hier die Wikipedia-Einträge:
http://de.wikipedia.org/wiki/RSA-Kryptosystem
http://de.wikipedia.org/wiki/Digital_Signature_Algorithm
Um einen Webserver ohne Browser zu testen, kann man auf das Kommandozeilen-Tool "telnet" zurückgreifen. Mittels telnet lassen sich die HTTP-Kommandos direkt an den Webserver schicken, der dann die entsprechende Antwort zurückliefert. Da telnet so gut wie unter allen Betriebssystemen zur Verfügung steht, kann diese Art und Weise des Testens extrem hilfreich sein.
Zunächst wird eine Telnet-Verbindung zum Webserver an Port 80 (Standardport für Webserver) aufgebaut:
telnet www.ich-teste-diesen-beispiel-webserver.de 80
Danach bekommt man einen Zeile in der nur der Cursor blinkt. Nun kann man folgende Eingaben machen (Achtung: Unter Umständen sieht man diese Eingaben nicht auf dem Bildschirm):
GET /index.html HTTP/1.1
host: www.ich-teste-diesen-beispiel-webserver.de
Zum Absenden dieser Eingabe muss 2 mal die Enter-Taste gedrückt werden. Jetzt sendet uns der Webserver die angeforderte Information zurück. In diesem Fall die "index.html" im Textformat.
Da man bei der Host-Anweisung auch andere Host-Namen angeben kann, lassen sich auf diese Art und Weise prima virtuelle Webserver testen, die nur eine IP haben, aber über mehrere Domains verfügen.
Zwei kurze Anleitungen zu dem Thema finden sich hier:
http://www.esqsoft.com/examples/troubleshooting-http-using-telnet.htm (englisch)
http://support.euregio.net/blog/2006/09/11/website-via-telnet-testen/ (deutsch)
Hier die Wikipedia-Einträge zu HTTP und Telnet:
http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
http://de.wikipedia.org/wiki/Telnet
Wer den Apache-Webserver nutzt, kann bestimmte Dateien oder Verzeichnisse mittels .htaccess schützen. Dabei fragt der Webserver dann bei Zugriff eines Benutzers den entsprechenden Benutzernamen und das entsprechende Passwort ab.
Diese Daten liegen meistens in der .htusers-Datei die gerne auch aus Sicherheitsgründen außerhalb des Webordners liegt. In dieser Datei findet man dann den Benutzernamen und mit Doppelpunkt getrennt das Passwort:
# BenutzerDatei für Web-Projekt
TESTBENUTZER:IXYK//m5K9wI0
Um mit der Verschlüsselungsmethode "Crypt" das Passwort zu verschlüsseln, kann man den kostenlosen Service auf selfhtml.org nutzen:
http://de.selfhtml.org/servercgi/server/htaccess.htm#verzeichnisschutz
Wer mit dem Cisco oder NCP-Client als VPN und/oder IPSEC-Clients nicht zurecht kommt, der sollte sich mal folgende beiden Alternativen anschauen:
Shrew Soft VPN Client:
Dies ist ein Freeware-Client der in einer Version für Windows und in einer Version für Unix existiert. Ausführliche Anleitungen beschreiben die möglichen Konfigurationseinstellungen.
Link: http://www.shrew.net
TheGreenBow IPSEC VPN Client:
Dieser Client gibt es nur in einer Version für Windows 2000/XP/2003/Vista und ist auch nicht kostenfrei. Der Preis liegt zwischen 70 und 100 Euro, je nachdem ob man eine Update-Funktionalität möchte oder nicht.
Link: http://www.thegreenbow.de
Beide Clients sind unter Windows sehr leicht zu bedienen. Der TheGreenBow-Client sogar noch leichter als der Shrew-Client. Im Test wurde eine Verbindung mit virtuellen IPs zu einem Bintec-Router hergestellt. Mit dem Shrew-Client war keine saubere Verbindung möglich, da irgendwelche Einstellungen nicht gepasst haben. Mit dem TheGreenBow-Client war innerhalb von 10 Minuten eine funktionierende Verbindung hergestellt. Ahnung zu haben von IPSEC und den Einstellungen der Gegenseite ist trotzdem bei beiden Clients ratsam.
Wer, wie in einem früheren Artikel beschrieben, nach wie vor Probleme mit den ASUS-W-Lan-Treiber (AR5007EG) und dem FEC / Bintec IPSEC Client hat, sollte auf den Client von TheGreenBow ausweichen.
Hier der alte Artikel: http://www.undertec.de/blog/2008/09/lanemulationstreiber_von_binte.html
