FireFox Sync Server

Thursday, 30. November 2017

After years of Chromium as my default browser I've moved to give FF a new go after the release of v57 aka Quantum. Mozilla is still more trustworthy than Google and hey, I prefered Netscape over Mosaic once. Part of the shift was trying out FireFox sync. Since I have not much trust in the cloud unless it is my own server this meant installing Firefox Syncserver on my debian server.

I more or less followed the howto from sathya.de/blog/how-tos/setup-your-own-firefox-1-5-sync-server-on-debian-with-apache2-and-mysql/ , there are links to the mozilla docu included on his site. The basic steps are easy to take, with dns.he.net and letsencrypt with dehydrated setup of a new subdomain with a valid SSL-certificate has gone down to a matter of minutes.

Git clone the server, create a db and db-user, config the virtualhost in the web servers configuration, edit the default syncserver.ini, restart the webserver and then tell the clients in about:config which syncserver to use. Pretty basic, but it still has some potential for confusion and took me two runs to get it running.

the supplied syncserver.ini has an entry   public_url = http://localhost:5000/   which appears to suggest that ports should be defined in the server config, client config. But this is not so, in a production environment with https and a web server non ports are given.

I saw 404 errors in the error_log which stemmed from an error with the client config, I had erased the token/ - ppart of the uri. And I experienced a multitude of 500 server errors with traces in the error_log pointing at a line between Public_url = ... and allow_new_users = ...
The first complained the given secret exceeded the maximum length, while it had been created like the comments advise. Later I saw errors from parsing the sqluri. Many visual checks did not find a problem.

What helped me was a set of voodoo measures including: manually retyping the sqluri line  and  inserting a 'dummy = stupid' line supposed to catch any non-visible carried syntactical elements. Other possible sources of problems here include permissions issues and missing execution flag on the wsgi file.

And then, suddenly, it worked.

 

fail2ban fails to start

Thursday, 27. January 2011

Es begann mit der Entdeckung, dass es massive Zugriffe auf Port 110 mit dictionary attacks gab. mail.log ist ja ohnehin ein Schlachtfeld, aber es verwundert mich doch, dass ich es so lange uebersehen konnte.
Offenbar ist auch mehr als ein dictionary im Einsatz. Gegen solche brute force - Attacken sichert mich auf ssh ein denyhosts, etwas aehnliches fuer mail musste her. So kam ich auf fail2ban.

debian lenny, python 2.5.2 und fail2ban v 0.8.3 wollen leider nicht miteinander spielen. Fail2ban v0.8.3 läuft offenbar nicht mit python2.5, sondern nur mit python2.4

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496633 beschreibt so ziemlich, was ich hier auch sah.

Meine Abhilfe folgte diesem Beispiel, also zunächst
apt-get install python2.4
apt-get install fail2ban

dann /usr/bin/fail2ban-server und /usr/bin/fail2ban-client editieren, jeweils in der ersten Zeile python zu python2.4 ändern.

#!/usr/bin/python2.4

Zum Thema der dictionary attacks gegen pop3 gab es einige Beitraege auf howtoforge.com, ich habe mich zunächst bei der Installation an http://www.howtoforge.com/fail2ban_debian_etch orientiert.

Zumeist klappen die howtos von da ja ganz wunderbar, aber dies nicht. Ausser dem Problem oben verlangte es fail2ban ueber die im howto aufgeführte Config hinaus noch nach einer Datei filter.d/pop3d.conf, die ich ihm mit
cp courierlogin.conf pop3d.conf
geben konnte. Und dann war noch in jail.local die entsprechende Zeile auszukommentieren, so dass der jail dort so aussieht:

[pop3d]
enabled = true
port = pop3   
filter = pop3d
logpath = /var/log/mail.log
maxretry = 5

Nervig war, dass ich die Probleme trotz loglevel=4 (debug) in fail2ban.conf nicht in der logdatei zu lesen bekam. Was wirklich ging war die Methode, in einer Shell 
/usr/bin/fail2ban-server -x -f
zu starten und dann in einer zweiten shell 
/usr/bin/fail2ban-client reload

Update:

Wegen einer brute force attack hatte ich den jail fuer SASL aktiviert.
Tausende Zeilen wie
Feb 10 16:55:42 pipit postfix/smtpd[21738]: warning: unknown[95.62.75.67]: SASL LOGIN authentication failed: authentication failure
Feb 10 16:55:49 pipit postfix/smtpd[21738]: warning: unknown[95.62.75.67]: SASL LOGIN authentication failed: authentication failure
Feb 10 16:55:56 pipit postfix/smtpd[21738]: warning: unknown[95.62.75.67]: SASL LOGIN authentication failed: authentication failure

Der SASL-Filter schien aber nicht zu greifen, die Zugriffe hielten an. Dies Problem hatte schon jemand vor mir beschrieben und gelöst. Mit der dort beschriebenen regexp war Ruhe.

 failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: \w

(Seite 1 von 1, insgesamt 2 Einträge)