SELinux Notizen

  1. sestatus -> Zeigt Statusinformationen von SELinux an
  2. getenforce -> Zeigt nur den aktuellen Zustand von SELinux an. Enforcing bedeutet es laeuft, Permissive bedeutet, das es deaktiviert ist
  3. setenforce -> Aendert den Zustand von SELinux. Uebergibt man den Parameter 0 ist es im Permissive mode. Uebergibt man den Parameter 1 ist es im Enforcing mode. Kann man mit dem Tool getenforce ueberpruefen.
  4. getsebool -a -> Zeigt alle verfuegbaren SELinux Optionen inklusive dessen Status (on | off) an.
  5. getsebool httpd_can_network_connect -> Zeigt nur den Status der SELinux Option http_can_network_connect an
  6. setsebool  httpd_can_network_connect on -> Setzt fuer die SELinux Option die httpd_can_network_connect den Status on
  7. Der Schalter -P bei setsebool sorgt dafuer, dass eine Aenderung auch PERSISTANT ist, also ueber einen reboot hinaus aktiv, Beispiel: setsebool  -P httpd_can_network_connect on
  8. Die Logdatei von SELinux heisst zum Beispiel auf einem CentOS 6.4 audit.log und liegt unter /var/log/audit/audit.log
  9. ls -Z -> zeigt SELinux Security Context einer Datei an
  10. ps axZ -> zeigt SELinux Security Daten eines Prozesses an

 

Hotels und (zu bezahlendes) WLAN

Inzwischen war ich in so einigen Hotels unterwegs und immer wieder trifft man auf WLANs, bei denen man fuer die Benutzung zahlen soll. Nach genauerem Blick haben sich die Hersteller oft mehr auf Corporate Design Fragen konzentriert als auf die Sicherheit. Deswegen hier einige Erfahrungen:

Grundsaetzlich ist es sinnvoll, wenn man einen Server hat auf dem man z.B. einen SSH-Server auf alternativen Ports laufen lassen kann. Ich empfehle explizit neben 22 auch 53, 80, 443, 3128 und 8080. Daneben gibt es einen sehr simplen und einfachen Perl-HTTP-Proxy, ich glaube ich hatte den mal aus irgendeinem Linux Magazin:

#!/usr/bin/perl
use HTTP::Proxy;
my $proxy = HTTP::Proxy->new( port => 3129);
$proxy->start;

der die folgende Abhaengigkeit benoetigt:

sudo aptitude install libhttp-proxy-perl

Zu guter letzt hilft natuerlich immer, wenn man weiss, wie man mit SSH externe Ports lokal bindet. Damit kann man z.B. auf dem externen Server den HTTP-Proxy starten, den Port lokal hertunneln, und dann diesen Proxy z.B. in seinem Firefox eintragen… Ein Eintrag in einer ~/.ssh/config koennte wie folgt aussehen:

Host			hotelhelper
HostName		1.2.3.4
User			user
Port			443
LocalForward		3129 localhost:3129

Dann kanns losgehen:

  • Testen welche Ports nach aussen offen sind. Oft wird nur Port 80 und 443 beschraenkt, der Rest ist offen. Man kann sich dann ohne Probleme ueber andere Ports verbinden.
  •  Gucken ob im Netz nicht irgendwo ein Proxy laeuft ueber den man raustunneln kann. Hier kann einem
     sudo aptitude install nmap corkskrew

    helfen

  • Gucken ob DNS-Anfragen richtig aufgeloest werden. Evtl. werden _nur_ http Pakete gefiltert werden auf den offenen Ports, evtl. geht ja SSH auf Port 53 oder 443 raus…
  • Gucken ob klicks auf Portalseiten nicht weitere Dinge oeffnen. In einem Beispiel konnte ich mit einem Klick auf „Hier klicken um mit VISA zu Zahlen“ und der Weiterleitung auf die Seite eines externen Zahlungsanbieters den Proxy dazu bewegen fuer ein Zeitfenster von 30min SSH auf den bekannten Ports zu oeffnen.