/dev/blog/ID10T

Advertisement

Windows: Datei öffnen - Sicherheitswarnung deaktivieren

• Windows • Comments

Da ich momentan mal wieder einen Rechner neu einrichte, fallen mir auch wieder die vielen kleinen Dinge auf, die bei einem frischen Windows-System stören. Die "großartige" Sicherheitswarnung beim Öffnen einer Datei gehört dabei definitiv auf den ersten Platz. In der Regel habe ich meine Gründe, wenn ich eine Datei doppelt anklicke oder sonstwie zum Ausführen bewege, aber Windows will natürlich ganz sichergehen und fragt nochmals nach. Bei jeder Datei!

So deaktiviert man dieses für Privat-PCs in meinen Augen ziemlich überflüssige Feature:

Advertisement
  1. Den Gruppenrichtlinieneditor öffnen. Bei Windows 7 und Vista kann der Dateiname gpedit.msc einfach in die Eingabefläche im Startmenü einegeben werden und via Enter gestartet werden, bei Windows XP muss man den Umweg über Start -> Ausführen nehmen.
  2. Klickt euch durch: Benutzerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten -> Anlagen-Manager -> Aufnahmeliste für Dateien mit niedrigem Risiko
  3. Aktiviert diese Richtlinie und gebt in den Optionen die Dateitypen an, bei denen ihr die Warnung ausschalten wollt. Normalerweise sollte ein .exe (inklusive Punkt) dort reichen.
  4. Bestätigt alles mit OK.

Ab sofort ist diese Sicherheitswarnung Gechichte und ihr spart beim Installieren eurer Standardsoftware Zeit und Nerven.

Den bedauernswerten Benutzern einer Windows Home Edition, denen der Gruppenrichtlinieneditor fehlt, kann übrigens über einen Registryeintrag geholfen werden. Dazu verweise ich auf DIESEN Tipp auf wintotal.de (blättert runter zu Für XP/Vista/Win7 Home Versionen).

Apache2: PHP-Uploadgröße ändern

• Linux • Comments

Vor einigen Wochen habe ich erklärt, wie man das Uploadlimit in PHPMyAdmin erhöht. Heute will ich eine kleine Ergänzung dazu bringen, weil ich grade auf meinem vServer auf dieses Problem gestoßen bin.

Wollt ihr auf eurem eigenen Server die Uploadgröße anpassen, müsst ihr, genau wie im erwähnten Beitrag beschrieben, die Werte

upload_max_filesize

und

post_max_size

entsprechend euren Wünschen ändern. Allerdings müsst ihr diese in der php.ini eures jeweiligen Webservers machen. Diese findet ihr bei einer Standardinstallation unter /etc/php5 im Ordner mit dem Name eures jeweiligen Webservers. Bei mir mit dem Apache2 war das dann folglich /etc/php5/apache2/.
Wenn ihr mit vi oder nano oder was auch immer eure Änderungen durchgeführt habt (ich benutze meist den internen Editor des Midnight Commanders), startet ihr euren Webserver neu und seid fertig. Beim Apache2 geht das über

/etc/init.d/apache2 restart

Putty und Server via RSA-Key verbinden

• Linux • Comments

Vor Kurzem habe ich berichtet, wie man einen neuen Server oder vServer absichert. Unter anderem habe ich dort empfohlen, einen neuen Nutzer zu erstellen, über den man sich via SSH einwählen kann, um anschließend den Root Login via SSH zu verbieten.
Es geht allerdings noch eine Stufe sicherer, mithilfe von Schlüsselauthentifizierung. Das funktioniert im Endeffekt so, dass ihr einen Schlüssel habt und der Server ein "Schloss", in den dieser Schlüssel passt. Passt er nicht, kommt man nicbtmal bis zum Loginscreen. Das beugt Bruteforceattacken natürlich noch effizienter vor und ist dadurch natürlich auch noch ein Stückchen sicherer. Doch wie macht man dies?

Der meiner Meiner nach einfachste Weg fängt bei Putty an. Bei dem Programm PUTTYGEN um genau zu sein. Dieses bekommt ihr wie alle anderen Putty-Werkzeuge auf der Putty Website.

  1. Klickt nach dem Start von Puttygen auf Generate und bewegt eure Maus den Anweisungen entsprechend möglichst zufällig auf der angezeigten Fläche.
  2. Nachdem der Schlüssel erzeugt wurde, wollen wir ihn noch mit einem Passwort sichern. Dazu gebt ihr euer sicheres Passwort in die beiden Passphrase-Felder ein.
  3. Anschließend sichern wir sowohl Private- als auch Public-Key irgenwohin, wo wir sie wiederfinden.
  4. Jetzt wird es interessant. Verbindet euch auf  eure Linuxkiste und loggt euch als der Benutzer ein, mit dem ihr euch auch mittelds Schlüsselauthentifizierung verbinden wollt. Bleiben wir beim Beispiel meiner letzten Anleitung und nennen ihn sshuser.
  5. Nun brauchen wir einen Ordner .ssh im Benutzerverzeichnis und in diesem eine Datei authorized_keys, in der dann die akzeptierten Schlüssel hinterlegt werden. Ordner und Datei bekommen anschließend noch korrekte Berechtigungen gesetzt.
    mkdir ~/.ssh
    touch ~/.ssh/authorized_keys
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys
  6. Kopiert euch anschließend den Schlüssel, der in der oberen Hälfte des PUTTYGEN-Fensters unterhalb von Public key for pasting into OpenSSH authorized_keys file steht in die Zwischenablage und fügt ihn in den nächsten Befehl ein. Hierbei will ich präventiv auf  meine Erläuterung zu Copy und Paste bei Putty verweisen.
    echo [HIER DEN KOPIERTEN KEY EINFÜGEN] > ~/.ssh/authorized_keys
  7. Jetzt müssen wir  noch Putty einrichten. Unter den Menüpunkten Connection -> SSH -> Auth finden wir den Punkt Private Key file for authentication. Dort geben wir den Pfad zu unserem in Schritt 3 gespeicherten Private (!) Key an. Danach stellen wir aus Bequemlichkeitsgründen noch unter Connection -> Data als auto-login username den Namen unseres SSH-Benutzers ein.
  8. Dann testen wir die Verbindung mit den oben vorgenommenen Änderungen. Nur wenn die Anmeldung problemlos und ohne Fehlermeldung (!) klappt, solltet ihr fortfahren. Sonst besteht die Gefahr, dass ihr euch selber aussperrt.
  9. Hat alles geklappt, editieren wir die sshd_config. Dafür müssen wir dann aber root werden.
    su -
    vi /etc/ssh/sshd_config

    Hier ändern wir einige Einstellung oder fügen diese hinzu, falls es si noch nicht gibt. Wie in jedem Beitrag mit vi weise ich auch hier auf  DIESE kurze Anleitung hin.

    PasswordAuthentication noPasswordAuthentication no #Passwortauthentifizierung abschalten
    PubkeyAuthentication yes # Dafuer Publikkey Authenfizierung aktivieren
  10. Ein Anschließender Neustart des SSH-Dienstes versteht sich quasi von selbst.
    /etc/init.d/ssh restart

Wenn alles geklappt hat, sieht die Authentifizierung bei einem neuen Fenster etwa so aus. Viel Spaß damit!

Android: Fehler 492 beheben

• Android • Comments

Ich hatte eben einen "Fehler 492" bei der Installation einer App aus dem Market.

Natürlich habe ich erst die üblichen Schritte zur Fehlerbehebung mit dem Market versucht, hatte damit aber keinen Erfolg.

Die Lösung habe ich dann mit einer Kombination aus zwei Aktionen erlangt.

  1. Wipen der Cache Partition
    Das Smartphone im Recoverymodus neu starten (entweder über das Menü beim Neustart oder über das Gedrückthalten der "Volume Down"-Taste beim Start des Handys), Wipe Cache Partition (variiert je nach Recovery) wählen und die Sicherheitsabfrage bestätigen.
  2. Wipen des Dalvik Caches
    Wo wir schonmal im Recovery sind, könnenwir auch direkt noch via advanced -> Wipe Dalvik Cache den Dalvik Cache löschen.
  3. Neuinstallation des Markets
    Die Market Version 3.4.4 findet man beispielsweise HIER zum Download. Eine offizielle Version gibt es im Market, diese konnte ich allerdings nicht installieren.

Ob die 3.4.4er Version auch bei neueren Marketversionen zur Fehlerbehebung dient, vermag ich nicht zu sagen.

[Update 07.01.2012] Wenn die oben genannten Schritte bei euch keinen Erfolg zeigen, dann versucht einen Komplettwipe (wipe data/factory reset). Das funktioniert auf jeden Fall. Wenn ihr dann vorher auch noch eure Apps mit Titanium Backup sichert, ist euer System schon ein paar Minuten nach dem Factory Reset wieder wie gewohnt eingerichtet. [/Update]

Linux: neuen Server absichern

• Linux • Comments

Wenn man sich "mal eben" einen Server oder vServer gemietet hat, sollte man diesen erstmal "grundsichern". Diese Minimalsicherung besteht aus 3 Punkten. Ich gehe hier von Debian aus, da dieses meiner Erfahrung nach am Häufigsten verwendet wird und auch ich es nutze.

1. Update

Der logischste Punkt. Ein nicht geupdatetes System oder veraltete Dienste sind ein geöffnetes Scheunentor. Dies lässt sich mit

apt-get update && apt-get upgrade && apt-get dist-upgrade

aber auch direkt schmerzlos beheben.

2. Root per SSH verbieten

Der Root Account existiert auf jeder Linux Distribution. Deswegen ist dieser Account Teil einer jeden Bruteforcing Attacke. Wenn ihr dem Root Account den Login via SSH verbietet, muss der Angreifer neben eurem Passwort zusätzlich auch noch den Usernamen erraten.

Legen wir also zuerst unseren neuen User an.

adduser sshuser

Natürlich solltet ihr keinen so einfallslosen Namen nehmen, sondern eben einen, der schwer zu erraten ist.
Im Prozess der Usergenerierung müsst ihr auch direkt das Passwort anlegen, welches natürlich ebenfalls schwer zu erraten sein sollte. Ichhabe vor einiger Zeit schonmal beschrieben, wie man komplexe und doch merkbare Passwörter erstellen kann.

Prüft unbedingt, ob ihr euch mit diesem User auch per SSH einloggen könnt, bevor ihr fortfahrt. Ist dies nämlich nicht der Fall, sperrt ihr euch selbst aus!

Nun geht es ans editieren der sshd_config, die ihr im /etc/ssh-Verzeichnis findet. Ich nutze hierfür den vi, euch steht natürlich die Benutzung eines anderen Editors offen. Eine kurze Einführung in den vi findet ihr beispielsweise HIER.

vi /etc/ssh/sshd_config

Sucht nach dem Eintrag

PermitRootLogin yes

und ändert ihn in

PermitRootLogin no

Zusätzlich könnt ihr bei Bedarf auch noch zwei neue Zeilen einfügen

LoginGraceTime 2m
MaxAuthTries 6

Dadurch wird eine Bruteforcingattacke nach 6 Versuchen verhindert.
Außerdem solltet ihr präventiv den Login mit leerem Passwortverhindern, um den einen Testaccount, den ihr garantiert irgendwann mal vergesst nicht zum Problem werden zu lassen.

PermitEmptyPasswords no

Startet nun noch den SSH-Dienst neu

/etc/init.d/ssh restart

und ein SSH-Login als root ist unmöglich.

Ports schließen

Dies ist eine etwas größere Sache, weswegen ich sie nur generell anschneide. Mit dem Befehl

netstat -tulpen | grep -v 127.0.0.1

findet ihr alle Ports und Dienste raus, die auf eurem Server nach draußen herrschen und damit potentiell angreifbar sind. Deaktiviert hier alle Dienste, die ihr nicht zwingend braucht.

Damit ist der Server rudimentär gesichert. Natürlich gibt es noch weitere darüber hinausgehende Sicherungsmöglichkeiten, die ihr auch nutzen solltet, doch ein frischer Server ist nach diesen Maßnahmen vergleichsweise sicher.

 

Advertisement