Category: Security

How to disable the www-data user to send emails with postfix

Sometimes an insecure configuration allows spammer to use the www-data user to send emails with you postfix server.
Normally this is the case, when you get a bunch of error email from your mailserver, that some emails from www-data@hostname.tld could not be delivered.

To be sure, that this situation cannot exist, you can add the www-data user to a block list:
In /etc/postfix/main.cf just add


authorized_submit_users = !www-data, static:all

and restart you postfix server.
You will now get a lot of error in you log like this one:


postfix/sendmail[8563]: fatal: User www-data(33) is not allowed to submit mail

After some time, the spammers will hopefully loose interest in you server :-).

solving Security Error while starting Java WebStart (e.g. IPMI Remote)

Most of the IPMI Systems out there still using good old Java based Remote Applications to connect to the remote console.
Sine Java 8 update 111, the MD5 singing algorithm was marked as insecure (aka disabled) by Oracale (see Relase Notes for that Release ” Restrict JARs signed with weak algorithms and keys”).
You will get an “Security Error while using MD5withRSA Signature”:

 

The only solution to fix this error is to have your Hardware Vendor to update the IPMI Firmware with JARs, signed with a more up to date singing algorithm. A work around is to re-enable MD5 for the time being. For that you need to get into your Browser Java Installation.
On my Mac this is in


/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home

You need to edit lib/security/java.security and remove MD5 from jdk.jar.disabledAlgorithms.

Change


jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

to


jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024

Jenkins/Hudson Password Hash Format

Nice to know:

The Build-In Security Realm of Jenkins/Hudson is based on acegisecurity. The Hash is Sha256 based. For a Salt

foo

and a password

bar

, you have to Hash

bar{foo}

, that’s then

77ce9123f864f6749a2b2c99b988089c21d33e39247f7b1276dfad01a112f038

(via hashgenerator.de)

You find the Hashes in <Jenkins-Dir>/users/<username>/config.xml

it is then storred as

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user>
    <fullName>user</fullName>
    <properties>
        <jenkins.security.ApiTokenProperty>
            <apiToken>…</apiToken>
        </jenkins.security.ApiTokenProperty>
        <hudson.model.MyViewsProperty>
            <views>
                <hudson.model.AllView>
                    <owner reference="../../.."/>
                    <name>Alle</name>
                    <filterExecutors>false</filterExecutors>
                    <filterQueue>false</filterQueue>
                    <properties/>
                </hudson.model.AllView>
            </views>
        </hudson.model.MyViewsProperty>
        <hudson.security.HudsonPrivateSecurityRealm_-Details>
            <passwordHash>foo:77ce9123f864f6749a2b2c99b988089c21d33e39247f7b1276dfad01a112f038</passwordHash>
        </hudson.security.HudsonPrivateSecurityRealm_-Details>
        <hudson.tasks.Mailer_-UserProperty>
            <emailAddress>mail@example.com</emailAddress>
        </hudson.tasks.Mailer_-UserProperty>
    </properties>
</user>

 

setup your public SSH key to another UNIX Host

Normally you would prefer to use your public ssh key for login into a remote linux machine.
I created a script to perform the basic steps for inserting your public key into the hosts authorized_keys files.

The script looks like this:

#!/bin/bash

HOST=$1;
echo ">> setup your ssh keys for $HOST"
echo ""
echo ">> creating ssh keys on $HOST if necessary"
echo "(you need to enter your password)"
echo ""
ssh $HOST 'if [ ! -d ~/.ssh  ] ; then ssh-keygen -t rsa; fi'
echo ""
PUBKEY=`cat ~/.ssh/id_dsa.pub`
echo "=========================================================="
echo "your id_dsa.pub:"
echo "$PUBKEY"
echo "=========================================================="
echo ""
echo ">> transfering your public ssh key"
scp ~/.ssh/authorized_keys $HOST:~/.ssh/authorized_keys
ssh $HOST 'chmod 600 ~/.ssh/authorized_keys'
echo ""
echo ">> login with your public key"
echo "(should work without a password)"
ssh $HOST

A typical run might look like this:

imotep:~ philipp$ setupssh philipp@192.168.178.55
>> setup your ssh keys for philipp@192.168.178.55

>> creating ssh keys on philipp@192.168.178.55 if necessary
(you need to enter your password)

The authenticity of host '192.168.178.55 (192.168.178.55)' can't be established.
RSA key fingerprint is ...
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.178.55' (RSA) to the list of known hosts.
philipp@192.168.178.55's password:
Enter file in which to save the key (/home/philipp/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Generating public/private rsa key pair.
Created directory '/home/philipp/.ssh'.
Your identification has been saved in /home/philipp/.ssh/id_rsa.
Your public key has been saved in /home/philipp/.ssh/id_rsa.pub.
The key fingerprint is:
... philipp@debian
The key's randomart image is:
+--[ RSA 2048]----+
|...              |
+-----------------+

==========================================================
your id_dsa.pub:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx......xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
==========================================================

>> transfering your public ssh key
philipp@192.168.178.55's password:
authorized_keys                                                                         100%  610     0.6KB/s   00:00    

>> login with your public key
(should work without a password)
Linux debian 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Jan 23 17:31:16 2011 from imotep.fritz.box
philipp@debian:~$

tatsächlich….

…. fast schon wieder n Jahr rum 😉 Also irgendwie komme ich gar nicht mehr dazu hier was zu posten.Hat sich schon eine ganze Menge ereignet in letzter Zeit :-)Achja… heute dann mal in Deutsch wieder, irgendwie ist das Englische grade entfallen.Zuallererst:Ich habe endlich ein Macbook und es ist soooo schön! Zwar in weiß (und langsam zeigt sich, dass es Flecken anzieht),  aber es ist deutlich schneller als mein kleiner G4 Mac Mini.Da ich munter am einrichten des Systems bin, hier schon mal ein paar Hinweise: 1. Um in der iTunes Bibliothek die Links (die kleinen Pfeile) hinter den Interpreten/Alben so umzuwandeln, dass sie nicht in den iTunes Store führen, sondern in die eigene Bibliothek, muss man im Terminal folgenden Befehl ausführen:   

defaults write com.apple.iTunes invertStoreLinks -bool YES    

Möchte man das alte Verhalten wiederhaben (Option(=alt)-KLICK auf den Pfeil Button führt zur Bibiothek), so schreibt man:  

defaults write com.apple.iTunes invertStoreLinks -bool NO

 Gefunden im macwelt.de Forum [1]  Weiterhin gibt es eine erste Beta vom Mail Plugin:

 PGP for Apple’s Mail    

Diese Beta läuft nun auch wieder unter Macos 10.5 Leopard. Meinen gpg key findet ihr übrigens direkt unter meinem Foto. Man erhält diese Beta, indem man sich in die Mailingliste einträgt. Es läuft noch nicht alles perfekt, aber zumindest kann man gpg wieder schützen.Ich werde in der nächsten Zeit übrigens Beiträge zu folgenden Themen posten: 

  1. gpg – was ist das und wofür braucht man das
  2. ssh  – was ist das und wofür braucht man das
  3. ssh mit key files – der sichere Komfort

 Es ist zumindest ein kleiner Beitrag, ein wenig Information zu verbreiten, nachdem zumindest die Politik in Deutschland kein Interesse daran hat, den Schutz der persönlichen Daten weiterhin aufrecht zu erhalten. 

Die Sache mit den Emails (vorsicht, hoher Geek Faktor!)

Da einem Kollegen von mir Namentlich Bartosz, regelmäßig teilweise wirklich unglaubliche Dinge passieren, habe ich mal angefragt, und werde jetzt hin und wieder daraus etwas schildern…. tada…. *Tusch oder so*

Bartosz Welt:

Neulich beim abendlichen Chat mit einem Bekannten:

< 23:21:19 xxxxxxxxx: die uni bei uns hat jetzt nen neuen spamfilter - exchange spam irgendwas, extern gehostet bei microsoft. halte ich nicht sehr viel von, daß auch nur eine meiner mails durch microsofts hände geht... also habe ich dem support ne mail geschrieben, daß ich bitte auf den spamfilter verzichten will. leider scheint meine nachricht bei denen im spam gelandet zu sein. klasse. gut gemacht, microsoft. >

Just ein paar Tage bekam ich von dem Administrator der Universität Coventry – wie wahrscheinlich viele Studenten der Uni Coventry folgende Email:

< There is currently a problem with email in that incoming emails to the University are being bounced back to senders. The problem has been traced to the external iCritical anti-spam service and they are currently investigating. We expect a further update from them in half an hour or so. Most external email systems will continue trying to deliver for some time and so when iCritical fix the problem, these pending emails should then be delivered. That process may take some time however (as there will be a backlog). We are currently hopeful of seeing any such delay cleared by Monday. Outgoing mail will not be affected by this fault. >

Es ist schon erstaunlich…. da nutzen die einen extra Anbieter für Ihre Spambewältigung…

Da ich obiges Gespräch noch deutlich im Hinterkopf hatte, habe ich das einfach mal meinem Kontakt mitgeteilt und verhielt folgende doch recht spassige Antwort:

< Von: Bartosz xxxxxxxxxxxxx
Datum: 20. Januar 2007 23:30:04 GMT+00:00
An: Philipp Haussleiter
Betreff: Re: Fwd: Email problem – Update
Jetzt rate mal was die fürn n spamfilter haben? 😀

Zumindest einen, dessen Webseite mehr nach Enterprise und Web 2.0 aussieht als die von unserem off-site SPAM-Filter:

https://spam.frontbridge.com/

Sicher, mir kann das an sich auch schnurz piepe sein, was die Uni einsetzt – ich habe für meine Uni-Mail-Adresse sofort eine Weiterleitung auf bartosz@xyz gesetzt, für den Fall daß irgendein Depp da ne Mail hinschickt, benutze aber auch an der Uni immer nur meine Privatadresse.

Lustigerweise ist eine Weiterleitung an eine nicht-Uni-Adresse übrigens verboten. Angeblich verursacht das sonst hohe Kosten wegen der großen zu übertragenden Datenmengen. Aber wenn alle ununterbrochen YouTube-Videos schauen und sich per MSN Messenger (ja, auf den stehen die hier alle total) und Webcam unterhalten, dann ist alles in Butter… Ich leite meine @tcd.ie-Adresse daher an meine, ebensowenig gewollte oder bewußt genutzte, @cs.tcd.ie-Adresse weiter. Von *dieser* Adresse aus dann ist eine Weiterleitung dann plötzlich erlaubt, egal ob nach Timbuktu oder Tatarstan. Das liegt daran, daß die Informatik ihr eigenes Netz betriebt und ihre eigenen Regeln aufstellt. Albern ist es aber allemal.

Und dieser ganze Unfug führt zu albernen Situationen wie dieser: Ich habe letztens eine Mail an Paul geschickt. Der sitzt am Schreibtisch neben mir, vielleicht einen Meter entfernt. Meine Mail ging erst per SSH-Tunnel, der per OpenVPN durch den SOCKS-Proxy der Uni getunnelt wird (um die blöde Regelung zu umgehen, daß nur bestimmte Dienste und Ports erlaubt sind) zum OpenWrt-Router bei meinen Eltern in Dortmund. Von dort aus ging es weiter zum Mailserver von all-inkl.de. Dieser hat die Nachricht dann an Pauls Mailserver an der Carnegie Mellon University geschickt. Paul hat die Mail empfangen und mit mutt gelesen – eingeloggt auf einem CMU-Server per SSH, über SOCKS getunnelt.

Hätte er an meine @tcd.ie Adresse zurückgeschrieben, wäre die Reise noch abenteuerlicher geworden: Von Pauls Schreibtisch aus über SSH und SOCKS mit mutt geschrieben, wäre die Nachricht nach einem kurzen Aufenthalt in den USA nach Irland zurückgekommen. Der tcd.ie-Mailserver hätte sie an den cs.tcd.ie-Server geleitet. Dieser wiederum hätte die Nachricht an bartosz@xyz und damit zu all-inkl.de in Deutschland geschickt. Von hier hätte ich sie abgerufen, mit Thunderbird über den SSH-Tunnel im OpenVPN-Tunnel zum OpenWrt-Router durch den SOCKS-Proxy. Ich mag gar nicht zählen, wie oft diese Nachricht das TCD-Netzwerk betreten und verlassen hätte – und all das nur, um deren Bandbreite zu schonen. Das sind schon ein paar ganz tolle Helden, die das hier alles geplant haben.

Und die Krönung des ganzen ist dann noch der externe Spam-Filter. Die Nachricht hätte eine weitere Runde über den großen Teich gedreht, weil sie der tcd.ie-Mailserver zur Kontrolle an frontbridge.com geschickt und von dort wieder zurückbekommen hätte.

Ja, so ist das, wenn Administratoren sich aufspielen und technisch versierte Nutzer sich widersetzen. Wahrscheinlich sollten wir, wie 99% des Univolkes, den erbärmlichen Webmailer einsetzen und niemals hinterfragen, ob dies der Weisheit letzter Schluß sein kann…

Gruß,
– Bartosz

PS: Meine Rechtschreibprüfung kennt “Timbuktu” nicht… sowas.

Ich muss mir unbedingt mal die Zeit nehmen um die Emails auf der großen Weltkarte einzuzeichnen >