Spamassassin und Confixx – Benutzerdefinierte SPAM Filter Einstellungen greifen nicht

Also, Irgendwie kommen seit ein paar Wochen einige SPAM Mails trotz aktuellem Spamassassin unter Debian Lenny 5.0 64Bit (nur Version 3.2.5, da die neuere Version PERL 5.12 nutzt und das bei Lenny nicht einfach so als apt-get Paket gibt ­čÖü )┬ámit Confixx 3.3.6 durch. Das nervt nicht sonderlich da es wirklich wenige sind, aber das muss ja nicht sein.

Das komische an der Sache ist, dass man die einzelnen Benutzereinstellungen ├Ąndern kann, wie man m├Âchte aber es ├Ąndert sich leider nichts. z.B. habe ich den „required_Score“-Wert erh├Âht oder verringert. Dennoch werden die Mails mit dem Standardwert gepr├╝ft. Jegliche andere Einstellungen fruchten auch nicht, so wird der Betreff nicht aktualisiert usw.

 Workaround:

Ersetzt folgendes in der Datei /etc/procmailrc

:0fw: spamassassin.lock
* < 256000
| spamassassin

durch dieses: 
:0 fw
* < 256000
| /usr/bin/spamc -f

 

Somit schickt ihr die E-Mails endlich durch das client-modul von spamsassassin, womit wohl eure Einstellungen greifen sollten. Warum das nicht standardm├Ą├čig so eingerichtet ist bei einer Confixx Installation mit Spamassassin bleibt mir ein R├Ątsel.

Als kleiner Tipp hier mal eine Konfiguration, die im Moment meinen SPAM ganz gut aussortiert:

#preference value
bayes_auto_learn 1 
ok_languages all 
ok_locales all 
report_safe 1 
required_score 7 
rewrite_header subject *****SPAM***** 
skip_rbl_checks 0 
use_bayes 1 
use_dcc 1 
use_pyzor 1 
use_razor2 1

Ein weiterer Tipp:

… richtet mal einen CRON ein um spamassassin regelm├Ą├čig upzudaten. Daf├╝r muss im Verzeichnis /etc/spamassassin folgende Commandline als SU aufgerufen werden:┬á

sa-update -D –updatedir /tmp/updates

WebServer Sicherheit – ├änderungen im web-Verzeichnis ├╝berwachen

Letztens ging es in der Blogger Gemeinde ja ziemlich zur Sache. WordPress hatte auf verschiedenen Hosted Servern einige Probleme, dass ein Script eingespielt wurde, welches dem Client ein MalWare auslieferte…

Neben den vielen Sicherheitseinstellungen, die man in WordPress doch t├Ątigen sollte, hier noch ein erg├Ąnzendes Script, welches das komplette Web-Verzeichnis nach ge├Ąnderten Dateien in den letzten 30 min pr├╝ft. So kann man recht schnell erkennen und reagieren, falls jemand ungewollt ├╝ber eine Sicherheitsl├╝cke Schadcode in einer Datei ablegt.

< ?php
/**
 * Dieses Skript pr├╝ft in einem bestimmten Pfad 
 * die enthaltenen Dateien auf Änderungen
 * @author 	Twitch  <tg@webolutions.de>
 * @link 		www.webolutions.de	
 * 
 */
 
// Pr├╝fe folgenden Pfad auf Ver├Ąnderungen
// Hier k├Ânnen auch Pfade ausgeschlossen werden
exec('find /var/www/html/web/ -name error_log -prune -o -path 
'/var/www/html/web/shop/logs' -prune -o -type f -cmin -32 
-print | xargs -r ls -larth ', $last_changed);
 
// Wenn etwas gefunden wurde, dann schnell per E-Mail reporten
if ( count ( $last_changed ) > 0 ) {
 
    // E-mail Einstellungen
    $sendto = "E-mail receiver <mail @domain.de>";
    $sendfrom = "Check4Changes [DOMAIN] </mail><mail @domain.de>";
    $sendsubject = "Cron [DOMAIN] Check4Changes";
 
    // E-Mail Inhalt
    $email_output = 'Dateien, die in der letzten halben Stunde geaendert wurden:';
    $email_output .= "n";
    $email_output .= "n";
    $last_changed_files = implode ( "n", $last_changed);
    $email_output .= $last_changed_files;
 
    $send_eol = "rn";
 
    $send_headers = 'From: ' . $sendfrom . $send_eol;
    $send_headers .= 'Reply-To: ' . $sendfrom . $send_eol;
    $send_headers .= 'Return-Path: ' . $sendfrom . $send_eol;
 
    // Senden
    @mail($sendto, $sendsubject, $email_output, $send_headers);
}
?>
</mail>

Per Cron einfach aufrufen und fertig… zwar eine quick-L├Âsung, aber daf├╝r ziemlich hilfreich :-).

PS: Das Script hilft aber alles nix, wenn der WebServer direkt gehackt wurde… die Linux Freunde wissen warum ­čÖé

Enjoy FloodBot based on OverKill… not in my house!

Vor kurzem war die Auslastung eines Web-Servers extrem hoch, so auch heute den ganzen Tag. Also machte ich mich auf die Suche nach der Ursache und stolperte ├╝ber eine lustige Sicherheitsl├╝cke im „phpMyAdmin“ wor├╝ber sich ein FloodBot einschlich. Er nutze eine Datei wor├╝ber er sch├Ân den Bot mit passender Berechtigung herunterlud und ausf├╝hrte. Ich war doch ein wenig verwundert und probierte das gleich an einem Testsystem aus.

Jo! Dickes Ding…

Schwupps, war der Bot drauf und startete. Das sah dann per „ps aux“ so aus:

bot1Den genauen Befehl gebe ich hier mal nicht Preis. Wer wei├č wer was damit bei anderen anrichten m├Âchte.

 

Wow!… immer noch erstaunt :-).

Die Datei udp.pl mithilfe der L├╝cke und „sh -c perl“ ├╝ber die config.inc.php von phpMyAdmin einfach gestartet.

Irre!

Die Lücke ist so riesig, dass man über ein paar witzige Handgriffe den Server darüber so gut wie steuern kann (Vorausgesetzt man hat bei der Rechtevergabe geschlampt!). Mit Aufruf: 
http://…/php_my_admin/config/config.inc.php?p=phpinfo(); kann man sich sch├Ân die Komplettinfo zum Server holen oder mit┬áhttp://…/php_my_admin/config/config.inc.php?c=ps%20aux┬áden Inhalt des tmp-Ordners. Dieser war in diesem Fall angef├╝llt mit dem BOT.

bot2

Mehr poste ich nicht, animiert nur zu wilden Gedanken :-). Habs aber gleich auf befreundeten Systemen mal ausgetestet und siehe da, viele haben die L├╝cke nicht geschlossen. Denjenigen habe ich mal schnell ne Mail geschrieben.

 

Schnell mal mit „last -i“ nach komischen Logins gefahndet, dann noch known_hosts und ssh-key’s┬á├╝berpr├╝ft und die /etc/passwd nach lustigen neuen Usern mit UIDs „0“ durchsucht. War aber nix ungew├Âhnliches. Gl├╝ck gehabt. Schnell┬áphpMyAdmin aktualisiert, die tmp-Verzeichnisse geleert, und restliche Komponenten wie php, apache usw. aktualisiert und┬áServer neu gestartet (Windows angewohnheit :-)).
Nun noch mit „apt-get rkhunter install“ nen RootKitHunter installiert und das System durchgecheckt und mit „netstat -nap“ und „netstat -tulpe“ die Ports gecheckt┬á… Und auch alles in Ordnung.
Anschlie├čend den eaccelerator neu kompiliert und schwupps… Livesystem nach 3┬áStunden wieder clean. Downtime… summiert ca. 5 min… klasse Job! Blog schreiben 30 min :-). Sch├Âner Sonntagabend.

Anschlie├čend Serverseitig noch weitere M├Âglichkeiten mit ein paar Tricks unterbunden. Alles soll man nicht verraten :-).

Was ich daraus gelernt habe:

  1. ├ľfters mal ins Error und Accesslog vom Apachen schauen,
  2. apt-get upgrade/update/install sollte ein Freund werden,
  3. … meine Linux-Kenntnisse sind noch gut ­čÖé

Wollen wir mal schauen, ob das alles war. Der Server bleibt die Tage unter Beobachtung.