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

Magento Extension via SSH installieren

Es gibt Serverkonfigurationen, die es irgendwie nicht zulassen, dass sich Magento Connect öffnen lĂ€sst. Irgendein „include_once“ PHP Error, den ich noch nicht ausfindig machen konnte, trotz eigener PHP include_path – Erweiterungen.

Nunja, aber da schreib ich mal wann anders drĂŒber. Hier und heute will ich in ein paar kurzen Schritten erklĂ€ren, wie man diverse Magento Erweiterungen trotz nicht funktionierendem Magento Connect im Adminbereich via SSH installiert.

  1. Loggt euch via SSH auf euren Server ein.
  2. Wechselt in das Magento Root-Verzeichnis.
  3. Gebt euch fĂŒr die Installation und Einrichtung unbedingt root-Rechte am Server. Zum Beispiel kurz mit dem Befehl „su“ :-).
  4. Tippt in die Konsole folgenden Befehl ein: „./pear mage-setup“
    Wenn alles glatt lÀuft solltet ihr folgende Ausgabe sehen:
    Running initial setup…
    config-set succeeded

    config-set succeeded
    Adding Channel „connect.magentocommerce.com/core“ succeeded
    Discovery of channel „connect.magentocommerce.com/core“ succeeded
    Adding Channel „connect.magentocommerce.com/community“ succeeded
    Discovery of channel „connect.magentocommerce.com/community“ succeeded
  5. Anschließend könnt ihr jedes beliebige Modul installieren. Zum Beispiel fĂŒr einen deutschen Online-Shop das wichtigste freie Plugin von symmetrics. NĂ€mlich „Market Ready Germany
  6. Tippt folgendes in die Konsole ein: „./pear install -f magento-community/market_ready_germany“
  7. Wenn die Installation erfolgreich war, gibt es die Ausgabe in der Konsole auch an.
  8. Wechselt ihr dann in den Adminbereich des Magento Shops sind die Erweiterungen vorhanden.

… so, das wars auch schon.

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.

reset des MySQL – Passwortes

Vor kurzem musste ich unbedingt das Passwort zurĂŒcksetzen.

Hier eine kleine hilfreiche Anleitung

1. Schritt: Beendet den laufenden MySQL-Server ĂŒber das Init-Skript:

# /etc/init.d/mysql stop

PrĂŒft mittels ps ax ob alle Instanzen des MySQL Servers beendet wurden und beendet diese wenn nötig ĂŒber ein kill -9

2. Schritt: Startet den MySQL-Server mit deaktivierter Passwort-ÜberprĂŒfung und ohne NetzwerkunterstĂŒtzung:

# mysqld –user=mysql –pid-file=/var/lib/mysql/mysqld.pid –socket=/var/lib/mysql/mysql.sock –datadir=/var/lib/mysql –skip-grant-tables –skip-networking

Dieser Schritt fĂŒhrt dazu das die von euch verwendete Konsole gesperrt wird und so lange der MySQL Dienst lĂ€uft nicht verwendet werden kann. Bitte loggt euch also ĂŒber eine zweite Konsole erneut auf eurem Server ein.

3. Schritt: Setzen des neuen MySQL root Passworts:

# mysql
> use mysql
> update user set password = password (’neues Passwort‘) where user = ‚root‘;
> flush privilieges;
> exit

4. Schritt: Neustart des MySQL im normalen Modus:

Beendet den aktuellen MySQL Dienst entweder ĂŒber ein kill oder ĂŒber die Tastenkombination STRG + c innerhalb des MySQL Fensters.

PrĂŒft mittels ps ax ob alle Instanzen des MySQL Servers beendet wurden und beenden Sie diese wenn nötig ĂŒber ein kill -9

Startet den MySQL Dienst wieder normal.
# /etc/init.d/mysql restart

fertig…

Login mit SSH-Key und ohne Passwort

Ich wollte mir mal wieder die Arbeit erleichtern und die blöde Passwortabfrage abstellen, wenn ich Daten von Server A nach Server B schiebe. Vor allem sehr sinnvoll, wenn per CRON ein Job lÀuft, der Daten zwischen den Servern hin und her transportieren soll :-).
(Die Server sind in einem Netzwerk und nicht mit dem Internet verbunden…)

Zuerst erstellt man ein SchlĂŒsselpaar:
(Falls noch nicht vorhanden… Folgender Befehl ĂŒberschreibt das vorhandene SchlĂŒsselpaar!)

  • ssh-keygen -b 2048 -t rsa

Dann muss man den SchlĂŒssel auf den anderen Rechner ĂŒbertragen:

  • ruser:~ > ssh ruser@anderer.server.de „umask 077; mkdir -p .ssh; cat >> .ssh/authorized_keys“ <.ssh/id_rsa.pub

Der lokale öffentliche SchlĂŒssel wird somit in die Datei ~/.ssh/authorized_keys geschrieben. Gleichzeitig wird in die lokale Datei ~/.ssh/known_hosts der öffentliche SchlĂŒssel des Remotesystems geschrieben.

Falls es nicht funktioniert und er weiterhin ein Passwort haben möchte, einfach mal im Config-File des Servers ĂŒberprĂŒfen ob PubkeyAuthentification aktiviert ist!

und weiter gehts…