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…