Port Scans: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „= Port Scans = Der ganz normale Wahnsinn im Alltag eines Servers am Internet. Dies ist eine kurze Zusammenfassug anläßlich eines [[http://lists.funkfeuer.at/p...“)
 
Zeile 3: Zeile 3:
 
Der ganz normale Wahnsinn im Alltag eines Servers am Internet.
 
Der ganz normale Wahnsinn im Alltag eines Servers am Internet.
  
Dies ist eine kurze Zusammenfassug anläßlich eines [[http://lists.funkfeuer.at/pipermail/wien/2009-July/005183.html|Threads auf der Wien-liste]] (Mitte Juli 2009)
+
Dies ist eine kurze Zusammenfassug anläßlich eines Threads auf der: [http://lists.funkfeuer.at/pipermail/wien/2009-July/005183.html Wien-Liste] (Mitte Juli 2009)
  
* Warum "passieren" Port Scans?
+
Der Inhaltist Sinngemäß aud dem Mailverkehr zusammengestellt. Falls jamand sein Kommentar ergänzen, ändern,... will - nur zu!
  
Allerdings ist nicht Leuten einfach nur fad (die mag es auch geben),
+
== Warum "passieren" Port Scans? ==
sondern da suchen Tools automatisch nach Hosts, die man übernehmen kann
+
 
(mit bekannten Exploits. Am Error-Log von HTTP-Servern sieht man auch,
+
... ist Leuten nicht einfach nur fad (die mag es auch geben), sondern da suchen Tools automatisch nach Hosts, die man übernehmen kann (mit bekannten Exploits. Am Error-Log von HTTP-Servern sieht man auch, bei welcher Webapplikation  - oder Serversoftware? - es wohl Exploits gab/gibt). Wenn man so einen gefunden und gecrackt hat, wird er für als Spamschleuder oder Soldat für distributed Denial of Service Attacks u.ä. eingesetzt. Natürlich versucht der "Übernehmer" tunlichst unerkannt zu bleiben, d.h. er nichts kaputt machen oder löschen - sonst merkt einer vielleicht was. Und damit es gibt Leute, die vom Spammen u.ä. leben und das ist für
bei welcher Webapplikation  - oder Serversoftware? - es wohl Exploits
+
gab/gibt.).
+
Wenn man so einen gefunden und gecrackt hat, wird er für als
+
Spamschleuder oder Soldat für distributed Denial of Service Attacks u.ä.
+
eingesetzt. Natürlich versucht der "Übernehmer" tunlichst unerkannt zu
+
bleiben, d.h. er nichts kaputt machen oder löschen - sonst merkt einer
+
vielleicht was.
+
Und damit es gibt Leute, die vom Spammen u.ä. leben und das ist für
+
 
manche damit ein ganz normales Geschäft.
 
manche damit ein ganz normales Geschäft.
  
* Was tun?
+
...im windows bekommt man es kaum mit: Nach der einwahl ins internet dauert es max 1-2 min bis jemand beginnt deine ports abzuklopfen. Das ist alles kein spass ;) Besser du weisst bescheid und unternimmst was.
 +
 
 +
== Was tun? Tips & Ratschläge ==
 +
 
 +
* mach ein gutes gutes Passwort!
 +
Also mehr als 10 Zeichen. Sonderzeichen, Ziffern Klein und Grossbuchstaben.
 +
 
 +
Wenn du in linux das Programm pwgen installierst, dann kannst du dir sichere Passwoerter generieren lassen und dir eins davon dann merken.
 +
 
 +
 
 +
 
 +
* ...ist es mbMn das *mindeste*,
 +
(Gratis-)Updates der Distribution oder des Herstellers (Hallo, Win-* Benützer!) zu installieren.
 +
 
 +
* sshd auf einem anderen Port laufen zu lassen (siehe /etc/ssh/sshd_conf Datei)
 +
Aber irgendwann werden Portscanner eingesetzt werden, um sowas zu finden.
 +
 
 +
...services auf einen IANA unused port umgestellt ...
 +
 
 +
http://www.iana.org/assignments/port-numbers
 +
 
 +
* ... services (insbesondere der X) sollten via firewall dicht sein nach aussen und dann ssh-port forwarding verwenden.
 +
 
 +
http://www.debianadmin.com/howto-use-ssh-local-and-remote-port-forwarding.html
 +
 
 +
* "AllowUsers" im /etc/ssh/sshd_config einsetzen (normalerweise sollten System-Accounts eh nicht einlogbar sein, aber es schadet nichts ....)
 +
 
 +
* "PermitRootLogin no" sollte sowieso drin sein. (/etc/ssh/sshd_config)
 +
 
 +
* nur ssh-keys zu verwenden.
 +
 
 +
Public-Key hinterlegen (.ssh/authorized_keys) und Passwort-Login komplett abschalten... fertig.
 +
 
 +
Beispiel: http://www.g-loaded.eu/2005/11/10/ssh-with-keys/
 +
 
 +
...oft denken man sich dann "ah ssh-keys sind sicher, da brauche ich dann kein passwort mehr drauf". Das hat den nachteil, dass wenn die box gehackt wurde (soll ja auch ueber andere wege gehen), der ssh key verwendet wird, um auf andere rechner zu hupfen (bash history | grep ssh und dann das probieren).
 +
 
 +
Deswegen: wuerde also empfehlen trotz ssh key eine passphrase drauf zu haben ( er fragt eh beim erzeugen des ssh keys).
 +
 
 +
* "sshd: ALL" in /etc/hosts.deny rein und in /etc/hosts.allow die IP-Adressen/Netze erlauben, von denen man überhaupt einloggen darf.
 +
 
 +
* Es gibt Tools wie http://www.fail2ban.org/wiki/index.php/Main_Page.
 +
 
 +
* Anzahl der erlaubten Verbindungsversuche pro Zeiteinheit limitieren.
 +
 
 +
Werden z.B. mehr als 3 Verbindungsversuche in einer Minute registriert, wird der Port für die restliche Minute gesperrt. Damit reißen diese Angriffe erfahrungsgemäß in kürzester Zeit ab.
  
...ist es mbMn das *mindeste*,
+
http://www.dd-wrt.com/wiki/index.php/Preventing_Brute_Force_Attacks
(Gratis-)Updates der Distribution oder des Herstellers (Hallo, Win-*
+
Benützer!) zu installieren.
+
  
Aber irgendwann werden Portscanner eingesetzt
+
* Portknocking
werden, um sowas zu finden.
+
Bei der richtigen Sequenz an TCP/IP Verbindungsanfragen (SYN) auf bestimmten Ports sollte iptable nur diese eine IP und den SSH ort für eine bestimmte Zeitspanne zum Verbinden freigeben.
  
"PermitRootLogin no" sollte sowieso drin sein.
+
http://de.wikipedia.org/wiki/Portknocking
  
"AllowUsers" im /etc/ssh/sshd_config einsetzen (normalerweise sollten
+
* System hardening
System-Accounts eh nicht einlogbar sein, aber es schadet nichts ....)
+
Im debian repo findest du auch tools wie "harden" oder "bastille" sowie tools for firewalling (zb fwbuilder, shorewall) incl guis (if you need them). "logcheck" ist uu auch von interesse für dich.
  
"sshd: ALL" in /etc/hosts.deny rein und in /etc/hosts.allow die
+
* wenig services drauf haben ;-)
  IP-Adressen/Netze erlauben, von denen man überhaupt einloggen darf.
+
  
Es gibt Tools wie http://www.fail2ban.org/wiki/index.php/Main_Page.
+
* Im fall des falles wechsel zu BSD ;)

Version vom 18. Juli 2009, 21:02 Uhr

Port Scans

Der ganz normale Wahnsinn im Alltag eines Servers am Internet.

Dies ist eine kurze Zusammenfassug anläßlich eines Threads auf der: Wien-Liste (Mitte Juli 2009)

Der Inhaltist Sinngemäß aud dem Mailverkehr zusammengestellt. Falls jamand sein Kommentar ergänzen, ändern,... will - nur zu!

Warum "passieren" Port Scans?

... ist Leuten nicht einfach nur fad (die mag es auch geben), sondern da suchen Tools automatisch nach Hosts, die man übernehmen kann (mit bekannten Exploits. Am Error-Log von HTTP-Servern sieht man auch, bei welcher Webapplikation - oder Serversoftware? - es wohl Exploits gab/gibt). Wenn man so einen gefunden und gecrackt hat, wird er für als Spamschleuder oder Soldat für distributed Denial of Service Attacks u.ä. eingesetzt. Natürlich versucht der "Übernehmer" tunlichst unerkannt zu bleiben, d.h. er nichts kaputt machen oder löschen - sonst merkt einer vielleicht was. Und damit es gibt Leute, die vom Spammen u.ä. leben und das ist für manche damit ein ganz normales Geschäft.

...im windows bekommt man es kaum mit: Nach der einwahl ins internet dauert es max 1-2 min bis jemand beginnt deine ports abzuklopfen. Das ist alles kein spass ;) Besser du weisst bescheid und unternimmst was.

Was tun? Tips & Ratschläge

  • mach ein gutes gutes Passwort!

Also mehr als 10 Zeichen. Sonderzeichen, Ziffern Klein und Grossbuchstaben.

Wenn du in linux das Programm pwgen installierst, dann kannst du dir sichere Passwoerter generieren lassen und dir eins davon dann merken.


  • ...ist es mbMn das *mindeste*,

(Gratis-)Updates der Distribution oder des Herstellers (Hallo, Win-* Benützer!) zu installieren.

  • sshd auf einem anderen Port laufen zu lassen (siehe /etc/ssh/sshd_conf Datei)

Aber irgendwann werden Portscanner eingesetzt werden, um sowas zu finden.

...services auf einen IANA unused port umgestellt ...

http://www.iana.org/assignments/port-numbers

  • ... services (insbesondere der X) sollten via firewall dicht sein nach aussen und dann ssh-port forwarding verwenden.

http://www.debianadmin.com/howto-use-ssh-local-and-remote-port-forwarding.html

  • "AllowUsers" im /etc/ssh/sshd_config einsetzen (normalerweise sollten System-Accounts eh nicht einlogbar sein, aber es schadet nichts ....)
  • "PermitRootLogin no" sollte sowieso drin sein. (/etc/ssh/sshd_config)
  • nur ssh-keys zu verwenden.

Public-Key hinterlegen (.ssh/authorized_keys) und Passwort-Login komplett abschalten... fertig.

Beispiel: http://www.g-loaded.eu/2005/11/10/ssh-with-keys/

...oft denken man sich dann "ah ssh-keys sind sicher, da brauche ich dann kein passwort mehr drauf". Das hat den nachteil, dass wenn die box gehackt wurde (soll ja auch ueber andere wege gehen), der ssh key verwendet wird, um auf andere rechner zu hupfen (bash history | grep ssh und dann das probieren).

Deswegen: wuerde also empfehlen trotz ssh key eine passphrase drauf zu haben ( er fragt eh beim erzeugen des ssh keys).

  • "sshd: ALL" in /etc/hosts.deny rein und in /etc/hosts.allow die IP-Adressen/Netze erlauben, von denen man überhaupt einloggen darf.
  • Anzahl der erlaubten Verbindungsversuche pro Zeiteinheit limitieren.

Werden z.B. mehr als 3 Verbindungsversuche in einer Minute registriert, wird der Port für die restliche Minute gesperrt. Damit reißen diese Angriffe erfahrungsgemäß in kürzester Zeit ab.

http://www.dd-wrt.com/wiki/index.php/Preventing_Brute_Force_Attacks

  • Portknocking

Bei der richtigen Sequenz an TCP/IP Verbindungsanfragen (SYN) auf bestimmten Ports sollte iptable nur diese eine IP und den SSH ort für eine bestimmte Zeitspanne zum Verbinden freigeben.

http://de.wikipedia.org/wiki/Portknocking

  • System hardening

Im debian repo findest du auch tools wie "harden" oder "bastille" sowie tools for firewalling (zb fwbuilder, shorewall) incl guis (if you need them). "logcheck" ist uu auch von interesse für dich.

  • wenig services drauf haben ;-)
  • Im fall des falles wechsel zu BSD ;)