• XSS (Cross-Site-Scripting) Lücken sind nicht schlimm bzw können niemanden schaden.

Wenn ich so etwas lese, könnte ich mir die Haare büschelweise ausreißen. Eine solche Behauptung ist einfach schlichtweg FALSCH! Eine XSS Lücke sollte man genauso ernst nehmen wie jede andere Sicherheitslücke. Über eine XSS Lücke können schön Cookies geklaut werden und im extremen Fall wenn es eine persistente XSS Lücke ist kann ein Schadcode direkt auf dem Webserver gespeichert werden.

• Software updaten ist sinnlos!  

FALSCH! Software Updates sind das A und O des Serveradmins. Es gibt fast nichts wichtigeres als Updates zu machen. Wenn man veraltete Software einsetzt ist es eigentlich fast genauso überall das Passwort 123456 zu haben, was mich direkt zu meinem nächsten Punkt bringt

• Überall das gleiche 6 Stellige Passwort zu haben reicht.

Ein 6 stelliges Passwort reicht doch, denn man will es sich natürlich auch merken können. Natürlich wird es auch überall eingesetzt damit man sich nur dieses eine Passwort merken muss. FALSCH! Wieder eine Sache die mir die Haare zu Berge stehen lässt. Passwörter sollten auf jeden Fall länger als 6 Stellen sein. Am besten 12 Stellen oder mehr. Und die Passwörter sollten aus Groß- Kleinschreibung, Zahlen und evtl. Sonderzeichen bestehen. Außerdem sollte man überall ein anderes Passwort benutzten.

• Für meine Webseite interessiert sich kein Angreifer

Ist ein Projekt sehr klein und hat nur wenige Besucher, lohnt sich der Einbruchsversuch für den Angreifer gar nicht. FALSCH! Den auch kleine Projekte können ausgenutzt werden, sei es jetzt durch manipulierte Downloadangebote, durch Phishing-Seiten oder durch das Installieren eines Proxy-Servers.

• Eine einfache http- Authentifizierung reicht um meine sensiblen Daten zu schützen.

FALSCH! Bei den meisten http-Authentifizierungen wird entweder ein einfaches Passwort gewählt, welches sich leicht mittels einer Brute-Force Attacke erraten lässt oder es wird nur die http-Methode Get verboten. Ruft man die Datei in einem geschützten Verzeichnis mit einer anderen http-Methode auf, greift die Authentifizierung nicht mehr und die sensiblen Daten liegen offen. Generell sollte man auf dem Websever keine zu sensiblen Daten liegen lassen.

Das waren jetzt mal nur ein paar Fakten, aber alle wahr und alle Behauptungen habe ich schon mehrfach zu hören bzw. zu lesen bekommen. Wenn dann aber der Server wirklich gehackt wird, ist das Geschrei groß.

Werde hier evtl. bald noch ein paar Fakten ergänzen!

Kleine Anmerkung am Rande, ich werde hier nicht ins kleinste Detail gehen, sondern nur eine grobe Anleitung gebe. Weitere Details und eine ausführliche Anleitung könnt ihr auf der OpenVPN Webseite nachlesen. Als Server wird Debian 6 eingesetzt und als Client-PC Windows7

OpenVPN installieren

#apt-get install openvpn

Vorbereitung um die Keys zu generieren

#mkdir /etc/openvpn/easy-rsa

#cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa

“certificate authority” generieren

#cd /etc/openvpn/easy-rsa
#source ./vars
#./clean-all
#./build-ca

Server Keys generieren

#./build-key-server servername

#./build-dh

#./build-key-pkcs12 client

unter /etc/openvpn/ die server.conf anlegen.

nano /etc/openvpn/server.conf

server.conf

server 10.8.0.0 255.255.255.0

dev tun
port 443
proto udp

ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/servername.crt
key easy-rsa/keys/servername.key
dh easy-rsa/keys/dh1024.pem

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

ping-timer-rem
keepalive 20 180

persist-key
persist-tun

comp-lzo

# user nobody     #unprivilegierten User  unter dem OpenVPN nach dem Start laufen könnte
# group nogroup   #Gruppe

verb 3
mute 50

Dann einfach die “ca.crt”; “client.crt”; “client.key” von /etc/openvpn/easy-rsa/keys auf euren PC ziehen und in den config-Ordner von openvpn packn. Danach die Datei client.ovpn mit eurem Texteditor erstellen.

client.ovpn

client

remote 13.33.33.37 443 #IP Adresse des Servers und Port
proto udp
dev tun

# Pfad zu den Keys anpassen bei bedarf
ca ca.crt
cert client.crt
key client.key
ns-cert-type server

persist-key
persist-tun

comp-lzo
verb 3
mute 50

Außerdem sollte noch die /etc/rc.local um folgendes erweitert werden damit das Masquerading auch nach einem Neustart des Servers noch funktioniert.

#natting for openvpn
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j SNAT --to eure.ip.hier.einfügen

(evtl. muss das Netzwerkinterface bei euch abgeändert werden. Statt eth0 kann es sein das bei euch venet0 hinkommt! Kommt drauf an ob ihr einen vServer oder einen dedicated Server habt.)

Mittels “/etc/init.d/openvpn start” den VPN Server starten und glücklich sein. Wichtig damit der VPN Server auch läuft muss bei eurem Server TUN/TAP aktiviert sein!

Habe es auch leider verpennt einen Screenshot von der XSS zu machen.

Aber so sollte es immer sein, Lücke wird gemeldet und nach dem melden auch direkt vom Betreiber geschlossen!

XSS bei boerse.ard.de

Finde es schade, dass ich keine Antwort auf meine E-Mail erhalten habe, aber was solls, hauptsache die Lücke wurde geschlossen!

Noch schlimmer ist es finde ich, dass die Mails über die Sicherheitslücken anscheint einfach ignoriert werden oder direkt ohne zu lesen in den Papierkorb wandern. Bis jetzt habe ich schon an 6 verschiedene Universitäten Mails geschrieben weil dort XSS  Lücken und/oder SQL-Injections möglich sind. Aber ich habe noch keine Antwort erhalten noch wurden die Lücken geschlossen. Man bemerke dass die Mails nun schon knapp 6 Wochen her sind.

Habe mittlerweile bei weiteren Uni-Webseiten Lücken gefunden und werde die nun im Laufen der Woche melden, vielleicht gibt es dort Leute die einsichtig sind und Ihre Lücken schließen. Außerdem werde ich noch einen Versuch starten mit den anderen 6 Universitäten Kontakt aufzunehmen damit diese Ihre Lücken auch schließen können.

Der Dienst premiumize.me sorgt da für Abhilfe. Im Prinzip kann man sich dort den Zugriff auf mehrere OCH Premiumaccounts kaufen. Aber man kann mit premiumize.me auch auf andere Dienste zugreifen die in Deutschland eigentlich gesperrt sind. Oder auch gesperrte Youtubevideos schauen!

Von Vorteil ist es auch noch das der gesamte Traffic (z.B. beim downloaden von einem OCH) erst über die Server von premiumize.me geht und man somit auch in einer gewissen Weise anonym ist! Die Geschwindigkeit beim downloaden ist auch ganz ok, zumindes habe ich mit meiner 16k Leitung immer Fullspeed gehabt!

Hier mal eine Liste der bis jetzt Unterstützen Dienst

Ich finde den Service echt gut und ist für mich auf jeden Fall sehr nützlich! Werde mir jetzt erstmal nach dem Ablauf von dem Probeaccount einen oder 2 Monate kaufen.

Leider ist es im Moment nur eingeladenen User erlaubt sich anzumelden, aber wer schnell genug ist kann sich gerne über meinen Invite Link hier anmelden: https://secure.premiumize.me/inv/570674586/

Oder einfach mal bei https://cp.ovpn.to/ schauen. Dort gibt es auch Invites!

EDIT://Habe mal die Übersicht der unterstützten Dienste aktualisiert!

htop- Serverauslastung

Nett nicht wahr? Da hatte jemand wohl was gegen mich O.o Mein ganzes nginx accesslog ist vollgespammt von verschiedenen IP’s die mich da zugespammt hatten. Die meisten habe ich nun via iptables geblockt und hoffe das jetzt mal nix mehr kommt!

In diesem Sinne, einen wunderschönen Guten Morgen

 #Verzeichniss sperren
location /wp-admin/ {
auth_basic "Resticted";
auth_basic_user_file /etc/nginx/htpasswd;
}

In der Datei htpasswd muss der Username und Passwort in der folgenden Form stehen
username:cryptetPW
Das Passwort lässt sich hier verschlüsseln: Klick Hier

Achtung: DeepLinks sind weiterhin ohne Passworteingabe erreichbar!

Wer das Battlefield3 Config Utility ausprobieren will kann es hier downloaden