in diesem Blogpost möchte ich euch erzählen, wie man auf per Vhost-Basis den Apache-Webserver mit verschiedenen Benutzerrechten ausstattet. Das ist dahingehend wichtig, da man verschiedene Webseiten voneinander trennen möchte. Sollte eine Webseite gehackt werden, so kann der Angreifer nicht sofort alle anderen Webseiten mitnehmen.

Wir werden zur Lösung dieses Problems das Modul „mpm-itk“ nutzen. Dieses lässt sich leicht installieren:

sudo apt-get install apache2-mpm-itk

Es könnte sein, dass dabei „mpm-prefork“ deinstalliert wird, aber das stört nicht weiter.

Als nächstes kann man in seinen VHost-Konfigurationsdateien folgenden Eintrag hinzufügen:

  <IfModule mpm_itk_module>
    AssignUserId USER GROUP
  </IfModule>

Wobei „USER“ der zu nutzende Benutzer und „GROUP“ die zu nutzende Gruppe ist. Gibt man diese Direktive nicht an, so werden die Standardrechte von Apache genutzt. Das kann je nach Konfiguration www-data oder root sein.

Die Ordnerstruktur kann zum Beispiel so aussehen:

/var/www/ - 775 (root:root)
-----> vhost1 - 700 (user1:user1)
--------> index.php - 777 (user1:user1)
-----> vhost2 - 700 (user2:user2)
--------> index.php - 777 (user2:user2)

Nun ist jede/r Webseite/VHost in sein eigenes Verzeichnis mit seinem eigenen Benutzer eingesperrt und Übergriffe auf andere Seiten sind nicht möglich.

~ Sebastian

in diesem Blogpost soll es um die Einrichtung von „unattended upgrades“ gehen. Aufgabe der unbeaufsichtigten Upgrades wird sein, Sicherheitsupdates auf meinen Servern automatisch und ohne Nachfrage jede Stunde zu installieren (falls verfügbar).

Die folgenden Schritte orientieren sich an der Debian-Distribution und apt. Für andere Distributionen bzw. Paketmanager wird es wahrscheinlich ähnliche Lösungen geben.

Installation und Konfiguration

Die Installation des Paketes geht relativ schnell über den Paketmanager:

sudo apt-get install unattended-upgrades

Als nächstes müssen noch zwei kleine Konfigurationsdateien angelegt werden.

20auto-upgrades

Für die kleinere der beiden Konfigurationsdateien (/etc/apt/apt.conf.d/20auto-upgrades) hat man zwei Möglichkeiten:

Option 1:

Man erstellt manuell die Datei „/etc/apt/apt.conf.d/20auto-upgrades“ mit folgendem Inhalt:

APT::Periodic::RandomSleep "900";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Die Optionen können später noch genauer nachgelesen werden, eine kurze Erklärung soll es hier aber schon geben:

• APT::Periodic::RandomSleep „900“ – Warte zwischen 0 und 900 Sekunden (15 Minuten) bevor die Updates heruntergeladen werden. Das soll die Mirror-Server entlasten.
• APT::Periodic::Update-Package-Lists „1“; – Update die Paketlisten
• APT::Periodic::Unattended-Upgrade „1“; – Führe unbeaufsichtigte Upgrades durch

Option 2:

Man führt den folgenden Befehl aus:

sudo dpkg-reconfigure unattended-upgrades

Aus den Angaben wird dann die o.g. Datei erzeugt.

50unattended-upgrades

Mit dieser etwas längeren Konfigurationsdatei kann man noch etwas Feintuning betreiben. Die Datei findet man unter „/etc/apt/apt.conf.d/50unattended-upgrades“. Der Inhalt sollte so ähnlich aussehen:

// Automatically upgrade packages from these origin patterns
Unattended-Upgrade::Origins-Pattern {
 // Archive or Suite based matching:
 // Note that this will silently match a different release after
 // migration to the specified archive (e.g. testing becomes the
 // new stable).
// "o=Debian,a=stable";
// "o=Debian,a=stable-updates";
// "o=Debian,a=proposed-updates";
 "origin=Debian,archive=stable,label=Debian-Security";
 "origin=Debian,archive=oldstable,label=Debian-Security";
};

// List of packages to not update
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run 
// dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
// Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION* if a 
// the file /var/run/reboot-required is found after the upgrade 
//Unattended-Upgrade::Automatic-Reboot "false";


// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

Ich gehe davon aus, das die Kommentare für sich selbst sprechen. Per Default werden auch nur Security-Updates installiert, wobei im Zweifel auf ein Reboot verzichtet wird.

Eine Anmerkung noch zu der Email-Option:

Unattended-Upgrade::Mail "root";

Möchte man diese nutzen, so muss das „mail“ Kommando verfügbar sein. Am Besten installiert man sich dazu einfach das Paket „bsd-mailx“.

Fazit

Unattended-Upgrades ist ein ganz nettes Tool, mit dem man zeitnah kritische Sicherheitsupdates einspielen kann. Das Tool informiert den Administration nach erledigter Arbeit über die ausgeführten Schritte, sodass trotzdem die volle Kontrolle erhalten bleibt.

~ Sebastian

Whonix-Konzept (Quelle: www.whonix.org)

Durch diesen Trick kann die Workstation nicht mehr so einfach die echte IP-Adresse verraten, die echte IP ist nicht auf der Workstation gespeichert.

Wenn man schon VirtualBox nutzt sollte die Installation von Whonix recht schnell gemacht sein. Einfach die Systemabbilder von der Whonix-Webseite herunterladen und installieren. Auf der Webseite von Whonix sind diese Schritte auch noch ausführlich dokumentiert.

Fazit: Sieht gut aus. Einfach mal ausprobieren.

Ansonsten: Whonix sucht auch noch Mitwirkende.

mal wieder ein ganz kurzer Blogeintrag über ein kleines Tool, welches ich eben entdeckt habe. Es geht um das Programm „pwgen“. Dieses erlaubt es einem (komplexe) Passwörter auf der Kommandozeile zu erzeugen.

Die Installation

Die Installation aus dem Arch-Community-Repo ist mit pacman sehr einfach zu realisieren:

pacman -S pwgen

Bei anderen Paketverwaltungen bzw. Distributionen müsste ein ähnliches Paket vorhanden sein.

Die Nutzung

Die Nutzung ist relativ trivial. Man kann verschiedene Flags setzen, um die stärke der Passwörter zu beeinflussen. Am meisten bewährt sich wahrscheinlich „-s“ und „-y“, was für „secure passwords“ steht. Nach der optionalen Liste dieser Einschränkungen wird noch empfohlen eine Passwortlänge (>=12) anzugeben.

Ein beispielhafter Aufruf kann so aussehen:

> pwgen -s 20
4c3EuF7iC2dhGBlcV5h6 UaSV1U1XEjmNMd4CcCp7 583apzGng5BcLVbvGgeW
hWPz3f5NdT1wH6SSYELm kZRt5nQUixhINAPaYuDV 3Aw0xoebYuRDLhHkI4Ch
B5LVQNmTadxoGMMUMn62 0poJjmQQOw5iv5OVCQ59 Nka2UchwGKdCLMbDle6v
yHAD93Mvv7COtmcrxqLd pOaezkLk5v39yMJOeO1h kOsj60dOj8xWeadCuW34
bUbV3bwxfz9QYCQIlHJI BFfvPRC3bntMcKeoFlsY W0DhlN7KBwl41PhdoWL9
jhQ6cKSeEhmKQBYU2Sd6 5JFoh4yptLQKR4CvJjTG pmGW2OlANqznYbda471c
gVkVWXhf6tiTcRttE3vb VAOyPVb8luLvY5Go9T3R RqxOCjQrLuGxzwHyK1xs
ylqoHd3xeKSoQZOZBv7D JswJdsFlS8HlCTN51hk0 11ADsGGnl72Mx0ti1SUF
OL2qkyYiFqUBLyF4ux4h GPcLy35WXqsdrvk6HX3t X3McSi3Ojq9of3kuIWHG
T6tXLZJvTIyCd15LL9AT hvtfwi1CSon9AoXsP2uK smqegqdMizcF0hpwx2gH
FEpLyoWLeU4HsLUH2fJA lvcvEhH1nSEy1E87qarl bLbKOcEIgPaszcjHcx5j
98VLjhDaBBr0bacdsKJs gAh4JA1Jy3bLzmqLDuo2 oFVSaD5xGMm5Z7uv5N0n
fsuxStxFT9cBxSezKJfF otIb5plSfr55cPWdO4KH VldQmt5bPP3moSPyJmj2
sXIutEeKZhkq8hYCxJoc oo3HgoPguFjr8xwwk5XI THWhLkVDTB7skdfHvcD3
w9gqcv1FqMGHZPmRxLfd uze2fPNf4cxVftJVm7a9 I8CRzxzZkbd0EaSk6A8W
MwnobIQySSshQ0hhyntH PF9gf29hpT8txGVHyzRj y0DfqjNqtvkZalOly8Vc
VXpvlJ4nsDN0GtJN0nUU zf0Rj0FW6yyblgN9Cbl1 poH9Lpu1CEi78SFX2Q9A
zzw0Lv0bPNtVh4FMfGvG 1kqCmEneBcOnYAXHT08L wo7XOW8zrsE3v2kCsPJM
JKRtHGli7NwgS0tMKgzV bBPyZ0kjBOLXg916hu9f b9qQQv4kmNeBXYRGgor2
p47WbOJgMp2tK8lMdwpm lqvrIy5ILULAufONSX6J mC12LHTCWQ70AChVRRBa

Schon hat man eine ganze Hand voll sicherer, 20-stelliger Passwörter.

Wenn man etwas paranoid ist (so wie ich), dann sollte man noch den Parameter „-y“ für „special characters“ setzen. Dann sieht die Ausgabe folgendermaßen aus:

> pwgen -s -y -N 10  20 
&c5Fw8Pfvw@c1D@,>nG+ <gTyA2YU.8P;5(t6WORF OB#Q&UnInv77@9Mq:k}d B5>D\1=%4_-k+R-I2E&@ K/&y@r2.[@2j^i_t73AX nr:<5l,YHWDPKq#Oud%K
vXy]y1&UQuB^9mk-83P& c\{|)rV*3Q+?D4Hgrws^ +,V=(?"9A,|(-46K4%h=
7jUEdUT.+NH~Ox?^S-xZ 

Zugegeben ist die Struktur beim Einfügen etwas verloren gegangen. Der Parameter „-N“ steht für die Anzahl der zu generierenden Passwörter.

Vielleicht kann ja der eine oder andere sich damit ein paar sichere Passwörter erzeugen.

~ Sebastian

SQL Injection per GET Parameter

Relativ einfach und oft können SQL Injection Angriffe über die GET Parameter durchgeführt werden. Dabei reicht SQLMap bereits die URL und es probiert selbständig alle Parameter aus. Man kann die zu testenden Parameter auch manuell begrenzen. (Parameter -p )

sqlmap.py -u "http://hackit.gehaxelt.in/sqli/level1.php?id=1" -p id

SQL Injection per POST Parameter

Da es laut dem HTTP Standard nicht nur GET, sondern auch POST-Requests gibt, können diese ebenso gegen SQL Injection anfällig sein. Hierfür muss man SQLMap sagen, welche POST Parameter im angreifbaren Script verarbeitet werden. Diese Option trifft man über die Parameter „–method“, „–data“ & „-p“:

sqlmap.py -u "http://hackit.gehaxelt.in/sqli/level5.php" --method=POST --data="id" -p id

SQL Injection in REST-style URLs

Man kann eine URL per .htaccess oder per entsprechendem Framework in den REST-Style bringen, sodass die URL so ähnlich aussehen kann:

http://[HOST]/partner/id/100/name/helloworld

Hier hat SQLMap ein paar Schwierigkeiten zu erkennen, wo es die SQL Injection ansetzen soll. Deswegen können bzw. müssen wir manuell nachhelfen in dem wir ein Asterix ( * ) an die gewünschten Stelle(n) packen.

sqlmap.py -u "http://[HOST]/partner/id/100*/name/helloworld*"

Danach kann SQLMap auch die Webanwendungen hinter diesen URLs auf SQL Injection untersuchen.

~ Sebastian