PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ssh absicherung die das noch nicht gemacht haben


psychodo
30.04.2008, 10:27
Na denn fang ich mal an heute hier nen bissl zu schreiben ….
Also ihr bekommt am herbeigesehnten Tag X von eurem Hoster die heißersehnten Daten


IP 081.54.7.11
User: root
pass: irgendwas
port für SSH 22


Zugangssoftware

\\Nun gilt es erstmal in den Server reinzumarschieren und den SSH Zugang zu verändern→

also loggt ihr euch mit den erhaltenen Daten entweder in Putty oder auch winSCP ein.

Hier bekommt ihr Putty:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html (http://www.chiark.greenend.org.uk/%7Esgtatham/putty/download.html)
und hier winSCP:
WinSCP :: Einleitung (http://winscp.net/eng/docs/lang:de)


Unter Debian gibt es wie immer viele Wege um sich später die ganzen configs anzuschaun und diese zu bearbeiten.

Ich nutze Joe.



System aktualisieren

Doch zuersteinmal heißt es


#apt-get update
#apt-get upgrade


damit euer Server auf den neusten Stand kommt.

Anschließend könnt ihr Kumpel Joe installieren mit


#apt-get install joe

Ab nun könnt ihr auf eurem Server sämtliche Dateien aufrufen mit dem Befehl


joe /pfad/zur/datei

und speichern könnt ihr mit


strg + k + x.



Neuen User anlegen


OK, soweit so gut nun aber los ab zur SSH config… doch moment,
eine Kleinigkeit brauchen wir noch.
Denn wenn wir später den Root Zugang auf der Console sperren wollen benötigen wir natürlich einen (normalen) Useraccount ohne Root
Rechte mit dem wir die normalen Arbeiten erledigen können.

Einen neuen User legt man wie folgt an→



Syntax:
useradd [-u UID [-g Gruppe] [-d Home] [-s Shell] [-c Bemerkungen] Username



Das könnte also zB so ausschaun→


#useradd -u 123 -g users -d /home/test -s /bin/sh -c 'toller testacc' test


Somit habt ihr den User Test angelegt er hat denn die UserID 123 und sein home Verzeichnis ist /home/test desweiteren ist seine \\shell /bin/sh er kann sich also einloggen und auf der console normal arbeiten….

Ihr könnt übrigens wenn das Heimatverzeichnis noch nicht besteht zusätzlich zu -d auch -m verwenden. Mit -m wird das Verzeichniss \\falls es nicht vorhanden ist erstellt. -d legt nur ein Verzeichnis fest welches schon besteht. Ich müsstet denn folgendes \\schreiben→


#useradd -u 123 -g users -m -d /home/test -s /bin/sh -c 'toller testacc' test




Der User test benötigt nun natürlich noch ein Passwort.

Das legt man so an →



#passwd test


anschließend wird man zwei mal zur Eingabe eines Passwortes aufgefordert.
Wenn das erledigt ist könnt ihr den neuen Account testen indem ihr euch einfach mal in Putty mit den neuen Daten einloggt.

Wenn alles klappt ist das schonmal Spitze.



So …kleiner Zwischenstand.. bisher habt ihr also einen funktionsfähigen Editor und einen neuen User ohne Root Rechte\\… weiter gehts→



SSH Configurieren


Nun gilt es also endlich den ssh Zugang anzupassen.



#joe /etc/ssh/sshd_config


wenn ihr diesen Befehl in der Console schreibt öffent sich die Configurationsdatei für SSH.

sucht folgende Stelle →


PermitRootLogin yes

und ändert es zu


PermitRootLogin no

damit sagt ihr dem Server, dass ihr von nun an dem User Root nicht mehr erlaubt sich auf der Console einzologgen.

Desweitern könnt ihr unter dem PermitRootLogin folgendes schreiben


AllowUsers Test

das Test ersetzt ihr mit eurem User den ihr für die Console benötigt.
Damit hat nur noch dieser User Zugriff auf die Console.

Ihr könnt auch noch zu Anfang der Config nach


# What ports, IPs and protocols we listen for
Port 22

suchen und auch diesen Port ändern ..am besten in einen Bereich hinter 1024.
Solltet ihr diese beiden Änderungen gemacht haben so müsst ihr nun die Änderungen speichern.

Das geht mit →


strg + k + x

So nun habt ihr zwar die Datei angepasst. Jedoch müsst ihr dem Server noch sagen das er die Änderung auch anwenden soll.

Das könnt ihr machen indem ihr folgenden Befehl eingebt


#/etc/init.d/ssh reload

Nach dem Reload ist ein einloggen als Root auf der Console oder im WinSCP nicht mehr möglich.

Ihr müsst euch jetzt mit dem User den ihr angelegt habt einloggen.
Mit diesem User habt ihr natürlich keine Root Rechte.


Solltet ihr mal Root Rechte benötigen so tippt ihr einfach →


#su
in die Console. Der Server wird euch nach dem Rootpasswort fragen.
Nach Eingabe das Rootpasswortes habt ihr Root rechte.

Um diese wieder abzulegen schreibt ihr einfach


#exit

in die Console.

Gruß F4RR3LL/Sven

Zurück zum Index (http://wiki.nixhelp.de/doku.php/start)

Einrichtung SSH mit KEY

Autor: sledge0303
E-Mail: sledge0303@hotmail.de Erstellt am: 30.10.2007

In diesem Howto wird die Erstellung von sog. public Keys für die Authentifizierung zum einloggen in den SSHd Dienst beschrieben. Keys haben sehr viele Vorteile, auch einen Nachteil. Sollte der Key mal verloren gegangen sein, gelöscht usw worden sein, ist ein Login nicht mehr möglich. Der Admin muss dann einen neuen Key erstellen und dem User zur Verfügung stellen.
Der Key, insbesonders der Rootkey, sollte nach Möglichkeit nicht lokal auf einem Produktivrechner abgelegt werden, stattdessen auf einen USB Key gespeichert und erst bei Nutzung des Keys an den PC/Desktoprechner angeschlossen werden. Wen eine unbefugte Person im Besitz des Keys und des Passworts ist, kann diese auf dem Server sein Unwesen treiben. Für die Ausführung dieses Howtos wird vorausgesetzt, dass das Tool 'putty' bereits installiert wurde. Wer es bislang noch nicht getan hat, sollte dieses umgehend installieren.



1. Wir erstellen den Public Key

Anhand einiger Bilder möchte ich die Erstellung des Pubkeys dokumentieren. Keine Angst, es ist nicht schwer http://wiki.nixhelp.de/lib/images/smileys/icon_wink.gif
Zuerst erstellen wir einen User, wir nennen ihn fortlaufend 'testuser'.
adduser testuser
Zuerst öffnen wir 'Puttygen', damit erstellen wir unseren Key.
…zuerst markieren wir SSHD DSA 1024

Klicken anschließend auf Generate und bewegen den Mausanzeiger auf dem Bildschirm bis der Key erstellt wurde.

http://www.netvision-technik.de/forum/attachment.php?attachmentid=596


Anschließend setzen wir für den neu erstellten Key ein Passwort, damit wird der Zugang zum SSH zusätzlich abgesichert. Ich persönlich empfehle eine Kombination aus Zahlen, Buchstaben und mindestens einem Sonderzeichen wie '!?&…'


Bild 2
http://www.netvision-technik.de/forum/attachment.php?attachmentid=597

Danach speichern wir diesen Key in das Homeverzeichnis oder am besten direkt auf den USB Stick. In meinem Beispiel benutzen wir das lokale Homeverzeichnis:

Bild 3
591
Zur weiteren Konfiguration noch nicht Puttygen schliessen, den Inhalt dieses Keys brauchen wir noch


Konfiguration des SSH Servers


Jetzt arbeiten wir weiter auf der Konsole und sichern zuerst die alte Konfigurationsdatei von SSHd.

mv /etc/ssh/sshd_config /etc/ssh/sshd_config.OLD
Jetzt hast du zwei Möglichkeiten, du kannst einmal root das Login erlauben oder wie im 2. Skript Login für root deaktivieren. Ich empfehle keinen Rootlogin, man kann sich bequem auf der Konsole mit su Superuserrechte aneignen.

Rootlogin erlauben:
Mit Rootlogin
cat > /etc/ssh/sshd_config << "EOF"
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
EOF

Rootlogin deaktivieren:
Ohne Rootlogin
cat > /etc/ssh/sshd_config << "EOF"
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
AllowUsers testuser
StrictModes yes
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
EOF

Noch wird SSH nicht neu gestartet.
Wir ermöglichen dem User 'testuser' den SSH Zugang:
mkdir -p /home/testuser/.ssh &&
nano /home/testuser/.ssh/authorized_keys
Wir markieren nun den Inhalt aus Puttygen und fügen ihn als eine Zeile per Copy and Paste in die geöffnete Datei ein:


Bild 4
592

In die geöffnete Datei in /home/testuser/.ssh/authorized_keys einfügen

Bild 5
593


Anschließend wird abgespeichert und der SSHd Dienst neu gestartet:
/etc/init.d/ssh restart
Somit ist nur noch ein Einloggen per Key auf die Konsole möglich.
Möchtest du für weitere User, incl. root einen Key erstellen, muss der Key nach oben genannten Schema in das jeweilige Homeverzeichnis erstellt werden:

mkdir -p /$HOMEVERZEICHNIS/.ssh
nano /$HOMEVERZEICHNIS/.ssh/authorized_keys
Wir starten Putty und tragen den Key mit diesem Schema ein:

Unter SSH/Auth trägst du den Pfad zu deinem Key an, wie beschrieben im lokalen Homeverzeichnis:


Bild 6
594

Unter Session gibst du nun die URL zzgl. Port zu deinem Server ein und speicherst alles ab als 'testeintrag'.


Bild 7
595

Der erste Login mit deinem Key

Cerberus
30.04.2008, 10:31
sehr sehr umfangreich ...
aber würdest du bitte die Bilder ins Forum hochladen ????

gotthummer
30.04.2008, 11:00
Ist ganz gut gemacht die anleitung nur ich glaube da fehlen bild 1 und bild 2

Galahad
01.04.2009, 08:43
Guten Morgen,

an was kann das liegen wenn ich in der sshd_config den Port ändere kann ich mich nicht mehr einloggen.Ich habe den Port eingegeben den ssh neu gestartet,dann über winscp den Port eingegeben und ich komme nicht mehr drauf.

mfg Galahad

SP4C3
01.04.2009, 17:20
Erstmal :"hut ab, hast dir ganz schön arbeit gemacht"

Aber ich habe nicht nur Lob.

Den SSH-Port zu verlegen ist "Security by Obscurity" und keine Wirksame Schutzmethode. Man sperrt nur simple scripts aus. Ein ausführlicher Portscan von 0-65535 dauert 15 minuten, inkl. service detection. Von daher, halte ich nichts davon, den ssh-port zu verlegen. Viel wichtiger ist es, root-login zu verbieten, und nur key-login zuzulassen, was du ja beides hier erklärt hast.

gotthummer
01.04.2009, 17:44
Erstmal :"hut ab, hast dir ganz schön arbeit gemacht"

Aber ich habe nicht nur Lob.

Den SSH-Port zu verlegen ist "Security by Obscurity" und keine Wirksame Schutzmethode. Man sperrt nur simple scripts aus. Ein ausführlicher Portscan von 0-65535 dauert 15 minuten, inkl. service detection. Von daher, halte ich nichts davon, den ssh-port zu verlegen. Viel wichtiger ist es, root-login zu verbieten, und nur key-login zuzulassen, was du ja beides hier erklärt hast.

danke das hab ich schon so vielen leuten versucht zu erklären keiner will es verstehen freut mich das es wenigstens einer so sieht nen port zu verlegen bringt = 0

.:.Uranus.:.
20.03.2010, 14:25
Habe mir mal die ssh key auch drauf gemacht zum probieren
funktioniert auch alles
nur meine frage ist wenn der key verschoben ist also kein stick angeschlossen
wieso kann ich mich trotzdem einloggen ist es richtig so ?
Also z.b. der testuser

mfg

Thunder™
20.03.2010, 16:04
super erklärt und leicht zu verstehen...

weiter so....:coool:

mfg

Zero111
20.03.2010, 16:58
Bei uns ist der ssh mehrfach gesichert:

SSH Port verlegt, mittels Knockd "abgedichtet" und root login wird verboten
zudem sind alle Passwörter (root, trackeruser, mysql etc) zufallsgeneriert und 40stellig

D@rk-€vil™
20.03.2010, 17:08
nur 4o stellig? lollipop ich bin bsessser ^^ 256 hab ick xddddddd

und kleiner tip installiert euch noch labrea xd

lg dark

Zero111
20.03.2010, 17:28
256 ist schon etwas krank.. selbst beim 40stelligen würde ne bruthforce attacke jahre brauchen

D@rk-€vil™
20.03.2010, 17:42
nö krank nicht...nur paranoit ^^

und noch zu info...labrea is nur für profis am besten..weil noobs sollten die finger von lassen ...


lg dark

Zero111
20.03.2010, 18:08
La Brea (spanisch Teergrube)

nen netter kleiner Honeypot :D

D@rk-€vil™
20.03.2010, 18:35
na dann frag ma dr. google was labrea ist....das is sondern ein schönes spiegel system für linux...aber den rest kannste selbst nach lesen...und mit honig hat des ganz und gar nichts mit zutun!

Lg Dark

SP4C3
20.03.2010, 21:28
na dann frag ma dr. google was labrea ist....das is sondern ein schönes spiegel system für linux...aber den rest kannste selbst nach lesen...und mit honig hat des ganz und gar nichts mit zutun!

Lg Dark
Naja.
Via google findet man zu dem Stichwort labrea nur eine "Tarpit" bzw. Sticky Honeypot Software.
Von daher hat Zero schon ganz recht.

phenom
30.10.2011, 18:25
mal ne frage,wie leere ich denn die log dateien ohne root zugriff?kommt immer Permssion Denied.

THX

Zero111
30.10.2011, 18:39
ähm gar nicht :D

phenom
30.10.2011, 18:47
na klasse,wie voll sollen die denn werden?

Thunder™
30.10.2011, 19:08
einfach root frei machen, einloggen - leeren und root wieder dicht machen..

oder über putty selber via root zugriff..^^

bastelfreak
31.10.2011, 15:04
für sowas gibts logrotate oder logging deaktivieren...

Zero111
31.10.2011, 15:56
Darüber hinaus hab ich eine weitere idee zur absicherung

Viele Rootserver werden mit mehr als einer IP ausgeliefert oder man kann sich beim anbieter zusätzliche ip adressen für kleines geld dazumieten

in der regel wird ja nur eine IP verwendet. Die andere ip ist unbenutzt. an dieser ip könnte man SSH einrichten so dass der SSH Deamon nur an dieser IP lauscht

So kann ein etwaiger angreifer die hauptip bis zum umfallen nach offenen ports scannen

Mit einer kleinen config änderung im apache lässt sich sogar phpmyadmin auf der 2. ip verlegen.

DirtyPlaya
31.10.2011, 15:59
da gibts doch auch noch was das man einen root login oder einen ssh login allgemein nur von einer ip aus zulassen kann also z.b ich habe die ip 1.2.3.4 dann kann man das dort eingeben und nur diese ip kann auf den root zugreifen per ssh nur weiß ich nicht wie man des macht wenn sich meine ip wechselt.

gotthummer
31.10.2011, 16:04
Darüber hinaus hab ich eine weitere idee zur absicherung

Viele Rootserver werden mit mehr als einer IP ausgeliefert oder man kann sich beim anbieter zusätzliche ip adressen für kleines geld dazumieten

in der regel wird ja nur eine IP verwendet. Die andere ip ist unbenutzt. an dieser ip könnte man SSH einrichten so dass der SSH Deamon nur an dieser IP lauscht

So kann ein etwaiger angreifer die hauptip bis zum umfallen nach offenen ports scannen

Mit einer kleinen config änderung im apache lässt sich sogar phpmyadmin auf der 2. ip verlegen.
das ist ne gute idee

Zero111
31.10.2011, 16:09
Würde auch gehen wenn man selber eine statische ip hat :D nur verbindungen von dieser ip zulassen

Thunder™
31.10.2011, 17:53
wollt gerade sagen....bei feste ip ok aber bei dynamischen ips..hätte ich ein problem^^

DirtyPlaya
31.10.2011, 18:00
ja das ist ja das problem hehe

Zero111
31.10.2011, 19:25
wollt gerade sagen....bei feste ip ok aber bei dynamischen ips..hätte ich ein problem^^

was denkst warum ich eine feste ip will..
teleschrott gibt aber keine. nur an buisnesskunden

Thunder™
31.10.2011, 19:28
die idee mit der 2 ips finde ich aber verlockend..:D

Zero111
31.10.2011, 19:35
hab ich auch so gemacht.. dafür bezahle ich gern 1.19€ bei OVH für die sog. failover IP

Thunder™
31.10.2011, 19:43
ist ja eigentlich nur Spielerei, wenn der ssh abgesichert ist braucht man sich ja keine großen sorgen machen...

aber testen muss ich es trotzdem mal...danke für den Tipp^^

Lex
31.10.2011, 20:06
Geht sogar noch "sicherer" aber natürlich auch etwas kostspieliger.

Server 1.
Sämtliche Ports dicht, login nur via ssh2 key, ports dicht, usw

Server 2. Webserver etc

Nun richtet man es so ein, das Server 2, den SSH login NUR von der IP von Server 1 aktzeptiert, und Server 1 quasi zum loginserver wird. Damit wäre das Login mit Dynamsichen IP´s behoben, und die IP von Server 1 kennt keiner, da die Page auf Server 2 liegt.

Lg Lex

Zero111
31.10.2011, 20:42
löl :D naja server 2 kann ja nen kleiner vserver für 6€ sein

Lex
31.10.2011, 20:47
Das müssen beides keine Hardware Server sein :)

Lg Lex

Zero111
31.10.2011, 21:09
ich weiß.. aber der 2. server dient ja quasi nur als "proxy" und muss deshalb nicht viel unter der haube haben..

Lex
31.10.2011, 22:08
Der 1. in meinem Beispiel ^^

Lg Lex

Zero111
31.10.2011, 23:32
jacke wie hose :D

Nehoz
01.11.2011, 16:11
na dann frag ma dr. google was labrea ist....das is sondern ein schönes spiegel system für linux...aber den rest kannste selbst nach lesen...und mit honig hat des ganz und gar nichts mit zutun!

Lg Dark

Honigpott oder Teergrube wurde tatsächlich richtig genutzt. Informiere du dich über die Sachen die du schreibst, bevor du eine wörtliche Übersetzung als falsch hinstellst.

Quelle: Wikipedia

Auszug:

LaBrea

Eine bekannte Implementierung davon ist „LaBrea“, welches ein ganzes Netzwerk mit einem einzigen Teergruben-Dienst schützen kann.
Der Teergruben-Computer lauscht auf unbeantwortete ARP (http://de.wikipedia.org/wiki/Address_Resolution_Protocol)-Requests (normalerweise eine unbenutzte Adresse) und beantwortet Anfragen an diese, d. h. er täuscht vor, die gesuchte IP-Adresse zu besitzen. Wenn er daraufhin das initialisierende SYN-Paket des Angreifers (häufig ein Portscanner (http://de.wikipedia.org/wiki/Portscanner)) erhält, sendet er nur noch eine SYN/ACK-Antwort, danach nichts mehr. Für diese Verbindung wird kein Socket geöffnet und keine „echte“ Verbindung eingerichtet. Die Teergrube speichert keine Daten der Verbindung nach dem gesendeten SYN/ACK. Somit braucht die Teergrube keinerlei eigene Ressourcen wie Rechenzeit, Sockets, Speicher oder Netzwerkbandbreite.
Der Computer der Remote-Seite (der „Angreifer“) sendet daraufhin sein ACK-Paket, um den für den Verbindungsaufbau nötigen 3-way-handshake (http://de.wikipedia.org/wiki/Drei-Wege-Handshake) abzuschließen. Schon dieses Paket wird von der Teergrube ignoriert, da aus Sicht des „Angreifers“ bereits eine etablierte Verbindung vorliegt. Er beginnt seine Daten zu senden, die jedoch niemanden erreichen.
Da im TCP (http://de.wikipedia.org/wiki/Transmission_Control_Protocol) eine Bestätigung für jedes Paket vorgesehen ist, wird die Verbindung in der Regel nach einer Zeit durch ein Timeout (http://de.wikipedia.org/wiki/Timeout) unterbrochen. Bis dahin verharrt die sendende Maschine jedoch in einem Zustand, der darauf ausgelegt ist, die Verbindung zu einem potentiellen tatsächlichen Kommunikationspartner nach aller Möglichkeit aufrechtzuerhalten. Diese Kommunikation kostet Zeit und Rechenleistung, je nach Art des Netzwerkstacks (Anzahl der Wiederholungen, back-off, retransmit usw.) oft sogar sehr viel.
Neuere Versionen von LaBrea sind um die Fähigkeit erweitert, später noch auf solche eingehende Pakete mit unsinnigen Antworten zu reagieren. Dafür werden Rohdaten (RAW IP packets (http://de.wikipedia.org/w/index.php?title=RAW_IP_packets&action=edit&redlink=1)) verwendet, damit keine Sockets oder andere Ressourcen des Teergrubenservers verwendet werden. Diese Pakete bringen den sendenden Server dazu, die Verbindung aufrechtzuerhalten und so wiederum noch mehr Zeit und Rechenleistung sinnlos zu verschwenden.
Neben LaBrea gibt es zahlreiche weitere TCP-Teergruben, wie zum Beispiel TCP-Damping.


Gruss Nehoz

Thunder™
01.11.2011, 16:50
schäme dich das du jetzt erst auf die idee kommst einen post zu zitieren der schon ewig her ist^^:p

Nehoz
01.11.2011, 17:16
Woa verdammt , da habe ich beim durchstöbern des Portals nicht auf das Postdatum geachtet. Asche auf mein Haupt ;-).