IT-Service GmbH

agena3.go-itservice.com

08.10.2014 Update Bash wegen ShellShock 2.

am 30.9. gab es wohl eine neue Lücke. Test:

# bash -c "f() { x() { _;}; x() { _;} <<a; }" 2>/dev/null || echo vulnerable

Was bei mir

Segmentation fault
vulnerable

ergab. Da ich keine gepatchtes Paket fand, habe ich es aus den Quellen und Patches des GNU Projektes selber compiliert:

# apt-get install gcc make bison
# cd ~/
# mkdir bash
# cd bash
# wget --no-check-certificate https://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz
# while [ true ]; do i=`expr $i + 1`; wget -N --no-check-certificate https://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-$(printf '%03g' $i); if [ $? -ne 0 ]; then break; fi; done
# tar zxvf bash-3.2.tar.gz
# cd bash-3.2
# for p in `ls ../bash32-[0-9][0-9][0-9]`; do patch -p0 < $p; done
# ./configure && make && make install

Neu anmelden und testen, keine Textausgabe, also ist auch der Exploit CVE-2014-6277 gefixt.

29.09.2014 Update Bash wegen ShellShock

Auf agena3 ist noch das alte Debian Lenny für amd64-Architektur im Einsatz, das nicht mehr mit Sicherheitsupdates versorgt wird. Um das vor der ShellShock Lücke in der Bash zu schützen, muß man diese aus anderer Quelle installieren.

# wget http://ftp.linux.it/pub/People/md/bash/bash_3.2-4.2_amd64.deb
# dpkg -i bash_3.2-4.2_amd64.deb

Anschliessend testen:

# env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

Die erste und zweite ShellShock Lücke ist geschlossen, falls das Resultat folgendes ist:

    bash: warning: x: ignoring function definition attempt
    bash: error importing function definition for `BASH_FUNC_x'
    test

2. Test:

# cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo

Der neuere Incident CVE-2014-7169 ist geschlossen, falls das Resultat folgendes ist:

    date
    cat: /tmp/echo: No such file or directory

Installation agena

bisher hatte ich eigene Hardware beim Internetprovider stehen. Da es inzwischen kaum mehr kostet, einen Root-Server mit dedizierter Hardware zu mieten, habe ich das inzwischen gemacht. Niemand muß jetzt bei Hardwareproblemen mehr nach Nürnberg rasen.

	+ postfix
	+ postfix-tls
	+ postfix-mysql
	+ postgrey

Konfigurieren des Systems

Cronjob für /root/daily5h anlegen...
ssh-Keys von Workstation an .ssh/authorized-keys hängen, bzw diese erst erzeugen.

sshd

damit Zugang auf agena auch von Netzen aus möglich ist, bei denen eine (Firmen)Firewall den Internetzugang via ssh auf Port 22 verhindert, lauscht der sshd auf Agena auch auf Port 563, das ist der Port für "secure News". Dazu muß in der /etc/ssh/sshd_config nur eine weitere Port Zeile eingetragen werden. Port 443 (https) wäre noch besser, der ist fast überall frei, allerdings läuft der Apache auf agena auch auf Port 443, so daß diese Option nicht möglich ist:

Port 22
Port 563

Postfix Problem mit Windows 7

Nachdem ein Kunde eine Workstation auf Windows 7 umstellte, konnte er keine Mails mehr senden: Windows 7 schickt beim Rechnernamen keinen Fully Qualified Domain Namen sondern nur den Rechnernamen, was der Postfix ablehnt. Also muss dies in der Postfixkonfiguration zumindest für den betroffenen Rechner akzeptiert werden. Dies geht am einfachsten mit einer der Ablehnung vorgestellten Regel, welche den übermittelten Rechnernamen mit einem regulären Ausdruck prüft und gegebenenfalls akzeptiert.
Dazu wird folgende Zeile in die /etc/postfix/main.cf eingefügt:

check_helo_access regexp:/etc/postfix/helo_access

Und zwar vor den Zeilen reject_invalid_helo_hostname, reject_non_fqdn_sender und reject_unauth_destination je nach Regelblock, so daß diese am Ende so aussieht:

smtpd_helo_restrictions      = permit_mynetworks,
                               permit_sasl_authenticated,
                               check_helo_access regexp:/etc/postfix/helo_access,
                               reject_invalid_helo_hostname,
                               reject_non_fqdn_helo_hostname

smtpd_sender_restrictions    = check_sender_access regexp:/etc/postfix/sender_access,
                               check_helo_access regexp:/etc/postfix/helo_access,
                               reject_non_fqdn_sender,
                               reject_unknown_sender_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated

smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated,
                               check_helo_access regexp:/etc/postfix/helo_access,
                               reject_unauth_destination,
                               reject_unlisted_recipient,
                               check_policy_service inet:127.0.0.1:12525,
                               check_policy_service inet:127.0.0.1:60000,
                               permit

Die Datei helo_access enthält drei Spalten: den regulären Ausdruck, die Anweisung was im Trefferfall zu tun ist und einen Kommentar. Beispielsweise so

/RECHNEROK/     OK       Rechnername RECHNEROK ist erlaubt
/RECHNERNOK/    REJECT   Testrechner RECHNERNOK ist nicht erlaubt

Versucht der Rechner RECHNEROK eine Mail zu schicken, funktioniert der Versand, der Rechner RECHNERNOK wird abgelehnt.

Postfix Problem mit Windows 7, die 2.

Der Versuch des Windows PCs, sich via SASL-Authentisierung anzumelden, wurde von Postfix mit der Fehlermelding sasl ntlm authentication aborted quittiert. Wieder keine Mail versendet. Tip aus dem Internet:

# echo -e "mech_list: plain login" >> /etc/postfix/sasl/smtpd.conf
# /etc/init.d/postfix restart

schon gehts. Wahrscheinlich kann man stattdessen auch vor der Zeile permit_sasl_authenticated im Block smtpd_sender_restrictions eine Regel einfügen, aber ich hatte es wie immer eilig. Wer es weiß, bitte Mail!

Postfix Problem ohne Windows

Von zwei auf dem Server gehosteten Seiten aus wurde über eine Lücke im dort verwendeten Joomla aus SPAM- Mails versendet, mit der Absenderadresse: webmaster@DOMAIN.de (DOMAIN sei der Name der Domain). Also, kein Problem in die /etc/postfix/main.cf bei smtpd_sender_restrictions = check_sender_access regexp:/etc/postfix/sender_access
In der Datei /etc/postfix/sender_access

/webmaster@DOMAIN/ REJECT

eingetragen. Trotzdem geht das spammen weiter! Mit dem folgenden Kommando kann man das Resultat der Püfung innerhalb der /etc/postfix/sender_access testen:

# postmap -q webmaster@DOMAIN.de regexp:/etc/postfix/sender_access

liefert REJECT,

# postmap -q webmaster@ANDEREDOMAIN.de regexp:/etc/postfix/sender_access

liefert eine leere Zeile. Daraufhin habe ich weiter im Internet rumgesucht und endlich die Erkärung gefunden, daß das die SPAM-Mail durch einen lokalen User auf dem Server versendet wird, für den deshalb Regeln in den smtpd_sender_restrictions nicht gelten. Aber es gibt es einen anderen Eintrag, der den eMail Versand von lokalen Benutzern erlauben oder verbieten kann (user erlaubt, !user verbietet)

authorized_submit_users = !vu2012,!vu2010

# /etc/init.d/postfix restart

ausführen. Jetzt könen die beiden betreffenden User keine Mails mehr über den lokalen Mailserver senden! Vorher sah der Eintrag in der /var/log/mail.log so aus:

Jan 11 13:21:15 agena3 postfix/pickup[11022]: 798691E60CE7: uid=2012 from=<webmaster@DOMAIN.de>
Jan 11 13:21:15 agena3 postfix/cleanup[11156]: 798691E60CE7: message-id=<20130108122155.798691E60CE7@agena3.go-itservice.com>
Jan 11 13:21:15 agena3 postfix/qmgr[10932]: 798691E60CE7: from=<webmaster@DOMAIN.de>, size=5298, nrcpt=1 (queue active)

Anschliessend so:

Jan 11 16:54:05 agena3 postfix/sendmail[24063]: fatal: User vu2012(2012) is not allowed to submit mail

Problem behoben...

Postfix für TLS

Zertifikat und Key erzeugen, dann Rechte setzen, damit nicht jeder die Dateien lesen kann

# cd /etc/postfix
# openssl req -new -outform PEM -out agena3.go-itservice.com.cert -newkey rsa:2048 -nodes -keyout  agena3.go-itservice.com.key -keyform PEM -days 9999 -x509
# chmod 600 /etc/postfix/agena3.go-itservice.com.*
# chown 600 postfix:postfix /etc/postfix/agena3.go-itservice.com.*

in /etc/postfix/main.cf

smtpd_tls_security_level    = may
smtpd_tls_cert_file    = /etc/postfix/agena3.go-itservice.com.cert
smtpd_tls_key_file    = /etc/postfix/agena3.go-itservice.com.key

Postfix neu starten:

# /etc/init.d/postfix restart

Der Test lokal auf der Kommandozeile mit openssl sollte CONNECTED liefern:

# openssl s_client -host localhost -port 25 -starttls smtp

CONNECTED(00000003)
depth=0 /C=DE/ST=Baden_Wuerttemberg/L=Ulm/O=go! IT-Service/CN=agena3.go-itservice.com/emailAddress=go.go-itservice.com
verify error:num=18:self signed certificate
...

Kontrolle Netzwerkaktivität

iptraf starten, ev Filter einrichten.

Mozilla als Mailclient

Folgende Einstellungen sind bei Mozilla nötig. Sinngemäß gilt dies für alle POP3/IMAP Clients.
Zu Beginn verwendet man am besten eine unverschlüsselte Verbindung, falls das funktioniert, ändert man die Einstellungen auf "Verschlüsselte Verbindung". Diese Verschlüsselung verhindert allerdings nur das Abhöhren der Verbindung zwischen dem Client-PC und agena z.B. über Eingriffe beim Internetprovider, nicht aber das Abhören der Mail, wenn sie von agena aus an den Zielrechner gesendet wird!
Um eine Mail "sicher" zu versenden, ist deren komplette Verschlüsselung vor Versand und beim Empfänger nötig. Dies kann z.B. durch Verwendung von Icedove,enigmail und OpenPGP geschehen.
Einstellungen Mail & Newsgroupsaccount

Servertyp: 		POP
Servername:		agena3.go-itservice.com  
Port:			110 [default]
Benutzername		USERNAME@DOMAIN		(=Mailadresse, z.b. go@go-itservice.com)
sichere Verb. ben.:	nein/nie
sichere Authent.:	nein

Falls statt POP3 ein IMAP Zugang verwendet werden soll, dies beim Anlegen des Mailaccounts angeben und statt dem Port für POP3 (110) einfach den Port 143 angeben. Dieser sollte aber bei IMAP voreingestellt sein.
Einstellungen Server für ausgehende Nachrichten

Server: 		agena.go-itservice.com 
Port:			25 [default]
Name&Passwort:		JA			(sonst kommt "Greylist" Meldung und die Mail wird nicht gesendet)
Benutzername:		USERNAME@DOMAIN		(=Mailadresse, z.b. go@go-itservice.com)
sichere Verbindung:	nein

Jetzt testhalber eine Mail an die eigene Adresse senden und über POP3 (oder IMAP) abholen. Falls das funktionierte, fogende Änderungen für eine verschlüsselte Kommunikation. Sichere Authentisierung muß auf "nein" bleiben.
Einstellungen Mail & Newsgroupsaccount

sichere Verbindung ben:	SSL		
Port:			995 [default]
ODER
sichere Verbindung ben:	TLS		
Port:			110 [default]

Einstellungen Server für ausgehende Nachrichten

sichere Verbindung ben:	TLS