Guten Abend! Nach ausfuehrlichen Beschaeftigungen mit IPCHAINS und IPTABLES habe ich nachvollziehen koennen, dass bei einer SSH-Verbindung folgendes ablaeuft: 1. Der Client nimmt sich das Protokoll TCP und einen unprivilegierten Port im Bereich von 1024 bis 65535 vor und baut mit dem Zielport 22 eine Verbindung zum SSH-Server auf. 2. Der SSH-Server nimmt vom Client die Verbindung an, sofern er dafuer eingerichtet wurde. 3. Der SSH_Server uebergibt nun dem Client einen neuen Port aus dem privilegierten Bereich von 513 bis 1023, wobei er in die Portauswahl offensichtlich nicht absteigend, sondern willkuerlich greift. 4. Der SSH-Client arbeitet nun mit diesem Port aus dem Bereich 513:1023 und schliesst seinen urspruenglichen Port. 1. bis 4. duerften von mir so richtig dargestellt worden sein. Aber: Wozu das eigentlich? Wer hatte die Idee mit der Portzuweisung von 513 bis 1023? Welcher tiefere Gedanke steckt hinter dem _nachtraeglichen_ Portwechsel? Ich habe in meiner Firewall- und TCP/IP-Lektuere dazu nichts passendes finden koennen. Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht...
* Peter Blancke schrieb am 18.09.01 um 20:24 Uhr:
Guten Abend!
Hallo Peter,
Nach ausfuehrlichen Beschaeftigungen mit IPCHAINS und IPTABLES habe ich nachvollziehen koennen, dass bei einer SSH-Verbindung folgendes ablaeuft:
1. Der Client nimmt sich das Protokoll TCP und einen unprivilegierten Port im Bereich von 1024 bis 65535 vor und baut mit dem Zielport 22 eine Verbindung zum SSH-Server auf.
richtig.
2. Der SSH-Server nimmt vom Client die Verbindung an, sofern er dafuer eingerichtet wurde.
auch ok
3. Der SSH_Server uebergibt nun dem Client einen neuen Port aus dem privilegierten Bereich von 513 bis 1023, wobei er in die Portauswahl offensichtlich nicht absteigend, sondern willkuerlich greift.
AFAIK geschieht die Portauswahl *doch* absteigend, es wird der erste *freie* Port benutzt.
4. Der SSH-Client arbeitet nun mit diesem Port aus dem Bereich 513:1023 und schliesst seinen urspruenglichen Port.
das kann er, muss er aber nicht.
1. bis 4. duerften von mir so richtig dargestellt worden sein.
Aber: Wozu das eigentlich? Wer hatte die Idee mit der Portzuweisung von 513 bis 1023? Welcher tiefere Gedanke steckt hinter dem _nachtraeglichen_ Portwechsel?
Der Portwechsel erlaubt die Authentifizierung ueber .rhosts und hosts.equiv. Gruss -Marc -- | ...and don't forget: Linux rulez! | | | | http://www.links2linux.de <-- Von Linux-Usern fuer Linux-User |
On Tue, 18 Sep 2001, Marc Schiffbauer wrote: Hallo Marc,
* Peter Blancke schrieb am 18.09.01 um 20:24 Uhr:
Nach ausfuehrlichen Beschaeftigungen mit IPCHAINS und IPTABLES habe ich nachvollziehen koennen, dass bei einer SSH-Verbindung folgendes ablaeuft:
1. [...] 2. [...] 3. [...]
4. Der SSH-Client arbeitet nun mit diesem Port aus dem Bereich 513:1023 und schliesst seinen urspruenglichen Port.
das kann er, muss er aber nicht.
Aha. Das habe ich eben auch herausgefunden. Es reicht, wenn man die ssh-Verbindung mit ssh -P <Hostip> aufruft. In der Tat bleibt es auf der eigenen Seite dann bei einem unprivilegierten Port ab 1024 aufwaerts.
Aber: Wozu das eigentlich? Wer hatte die Idee mit der Portzuweisung von 513 bis 1023? Welcher tiefere Gedanke steckt hinter dem _nachtraeglichen_ Portwechsel?
Der Portwechsel erlaubt die Authentifizierung ueber .rhosts und hosts.equiv.
Die Antwort befriedigt mich nicht. Ich kann mit der Option "-P" genauso arbeiten wie ohne. Ich sehe da keinen Unterschied. Nicht, dass ich stoerrisch waere. Aber erstens moechte ich es immer ganz genau wissen und zweitens macht es mir bei der Firewallkonfiguration immer "ein bisschen" mehr Arbeit. Natuerlich nur ein bisschen... Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht...
* Peter Blancke schrieb am 19.09.01 um 07:45 Uhr:
On Tue, 18 Sep 2001, Marc Schiffbauer wrote:
Hallo Marc,
Der Portwechsel erlaubt die Authentifizierung ueber .rhosts und hosts.equiv.
Die Antwort befriedigt mich nicht. Ich kann mit der Option "-P" genauso arbeiten wie ohne. Ich sehe da keinen Unterschied.
Genauso? Bist du sicher, dass du ueber einen unpriv port eine rhosts Verbindung zustande bekommst? man ssh: -P Use a non-privileged port for outgoing connections. This can be used if your firewall does not permit connections from privileged ports. Note that this option turns off RhostsAuthentication and RhostsRSAAuthentication ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ for older servers.
Nicht, dass ich stoerrisch waere. Aber erstens moechte ich es immer ganz genau wissen und zweitens macht es mir bei der Firewallkonfiguration immer "ein bisschen" mehr Arbeit. Natuerlich nur ein bisschen...
ist voellig in Ordnung Gruss -Marc -- | ...and don't forget: Linux rulez! | | | | http://www.links2linux.de <-- Von Linux-Usern fuer Linux-User |
On Wed, 19 Sep 2001, Marc Schiffbauer wrote:
* Peter Blancke schrieb am 19.09.01 um 07:45 Uhr:
On Tue, 18 Sep 2001, Marc Schiffbauer wrote:
Der Portwechsel erlaubt die Authentifizierung ueber .rhosts und hosts.equiv.
Die Antwort befriedigt mich nicht. Ich kann mit der Option "-P" genauso arbeiten wie ohne. Ich sehe da keinen Unterschied.
Genauso? Bist du sicher, dass du ueber einen unpriv port eine rhosts Verbindung zustande bekommst?
Nein, da bin ich mir keinesfalls sicher.
man ssh:
-P Use a non-privileged port for outgoing connections. This can be used if your firewall does not permit connections from privileged ports. Note that this option turns off RhostsAuthentication and RhostsRSAAuthentication ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ for older servers.
Hmmm... Tja, was sind "older servers"? Aber das ist jetzt wirklich egal. Wirklich wichtig ist nur, was mir RhostAuthentication und RhostsRSAAuthentication fuer mich bedeutet. Von den beiden Dingern habe ich naemlich gar keine Ahnung, da werde ich also weiterforschen muessen. Augenblicklich wuerde es mir auch reichen, ssh von den Ports ab 1023 abwaerts wegzukriegen. Das geht mit der "-P"-Option gut. Und ohne Passwort ist da rein gar nichts zu machen. Haeltst Du das fuer ein Sicherheitsrisiko, auf die beiden Authentication-Verfahren zu verzichten? Danke fuer Deine Erklaerungen. Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht...
* Peter Blancke schrieb am 19.09.01 um 19:24 Uhr:
On Wed, 19 Sep 2001, Marc Schiffbauer wrote:
Wirklich wichtig ist nur, was mir RhostAuthentication und RhostsRSAAuthentication fuer mich bedeutet. Von den beiden Dingern habe ich naemlich gar keine Ahnung, da werde ich also weiterforschen muessen.
Augenblicklich wuerde es mir auch reichen, ssh von den Ports ab 1023 abwaerts wegzukriegen. Das geht mit der "-P"-Option gut. Und ohne Passwort ist da rein gar nichts zu machen.
Haeltst Du das fuer ein Sicherheitsrisiko, auf die beiden Authentication-Verfahren zu verzichten?
Wenn du Dich immer mit Passwort auf deiner Machine anmeldest, benutzt du keine rhosts auth. Dann ist das fuer dich egal. Die rhosts auth kommt aus der Zeit der rtools. Ein User traegt einen host und einen user in eine Datei .rhosts in seinem Home Verzeichnis ein und dann darf dieser User (von diesem Host) sich ohne Passwort am Server anmelden (mittels rsh) Da ssh als sicherer Ersatz fuer rsh gedacht ist, gibt es eben auch hier noch die Moeglichkeit dieser rhosts Authentication. Ich finde ohnehin die Moeglichkeit besser, die SSH Schluessel zu tauschen, und sich so ohne Passwort am Server anmelden zu koennen. Das macht ich hier in meinem internen Netz so. Ist eben komforatbler.
Danke fuer Deine Erklaerungen.
keine Ursache. -Marc -- +------------------------------------------------------------------+ | --> http://www.links2linux.de <-- Jetzt mit neuen Features! | | wie z.B. [EasyLink] | +---Registered-Linux-User-#136487------------http://counter.li.org +
On Wed, 19 Sep 2001, Marc Schiffbauer wrote:
* Peter Blancke schrieb am 19.09.01 um 19:24 Uhr:
On Wed, 19 Sep 2001, Marc Schiffbauer wrote:
Wirklich wichtig ist nur, was mir RhostAuthentication und RhostsRSAAuthentication fuer mich bedeutet. Von den beiden Dingern habe ich naemlich gar keine Ahnung, da werde ich also weiterforschen muessen.
Augenblicklich wuerde es mir auch reichen, ssh von den Ports ab 1023 abwaerts wegzukriegen. Das geht mit der "-P"-Option gut. Und ohne Passwort ist da rein gar nichts zu machen.
Haeltst Du das fuer ein Sicherheitsrisiko, auf die beiden Authentication-Verfahren zu verzichten?
Wenn du Dich immer mit Passwort auf deiner Machine anmeldest, benutzt du keine rhosts auth. Dann ist das fuer dich egal. Die rhosts auth kommt aus der Zeit der rtools. Ein User traegt einen host und einen user in eine Datei .rhosts in seinem Home Verzeichnis ein und dann darf dieser User (von diesem Host) sich ohne Passwort am Server anmelden (mittels rsh)
Ja, jetzt habe ich das endlich verstanden.
Da ssh als sicherer Ersatz fuer rsh gedacht ist, gibt es eben auch hier noch die Moeglichkeit dieser rhosts Authentication.
Und da ich seit jeher ssh benutze (mindestens seit 1932 oder war es doch noch nicht so lange?;--), hatte ich mit der anderen Authentication noch nichts zu tun.
Ich finde ohnehin die Moeglichkeit besser, die SSH Schluessel zu tauschen, und sich so ohne Passwort am Server anmelden zu koennen.
So mache ich das auch auf den Web-Servern meiner Kunden, um die regelmaessig zu sichern. Natuerlich ist mir dabei bewusst, dass ich mir meine Maschine nicht klauen lassen darf. Jeder Vorteil hat eben auch seinen Nachteil. Danke nochmals, Marc. Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht...
Hallo Liste, hallo Peter, Peter Blancke wrote:
So mache ich das auch auf den Web-Servern meiner Kunden, um die regelmaessig zu sichern. Natuerlich ist mir dabei bewusst, dass ich mir meine Maschine nicht klauen lassen darf. Jeder Vorteil hat eben auch seinen Nachteil.
Wieso, schläftst deswegen schlecht? Kurze Anleitung zur Erhöhung der Sicherheit für die Backupdaten deiner Webserverkunden (in der Annahme das du ein Verschlüsselungsfan bist (deine bisherigen Mails)): - setze eine verschlüsselt Partition auf - mounte sie (Passwortabfrage) - laß sie solang der Server läuft gemountet - mache die Webserverbackups auf diese Partition klaut jemand deine Maschien, ist sie wohl Zwangsläufig ohne Strom (ist doch kein Notebook oder?) wenn er nun Mounten will muß er dein Passwort knacken oder die Verschüsselung der Partition. cu Gerald
Gerald Goebel schrieb am Thu, 20 Sep 2001 18:16:30 +0200: SSH-Verstaendnis
Hallo Liste, hallo Peter,
Peter Blancke wrote:
So mache ich das auch auf den Web-Servern meiner Kunden, um die regelmaessig zu sichern. Natuerlich ist mir dabei bewusst, dass ich mir meine Maschine nicht klauen lassen darf. Jeder Vorteil hat eben auch seinen Nachteil.
Wieso, schläftst deswegen schlecht? Kurze Anleitung zur Erhöhung der Sicherheit für die Backupdaten deiner Webserverkunden (in der Annahme das du ein Verschlüsselungsfan bist (deine bisherigen Mails)):
- setze eine verschlüsselt Partition auf - mounte sie (Passwortabfrage) - laß sie solang der Server läuft gemountet - mache die Webserverbackups auf diese Partition
klaut jemand deine Maschien, ist sie wohl Zwangsläufig ohne Strom (ist doch kein Notebook oder?) wenn er nun Mounten will muß er dein Passwort knacken oder die Verschüsselung der Partition.
cu Gerald
Quatsch. Wenn ich an den Server rankomme, um ihn zu klauen, kann ich wahrscheinlich auch die - gemountete - Partion einsehen. Wenn schon, denke ich, ist es klüger sowas - leicht verschlüsselt mittels irgendeines, z.B. Kompressionsproggis, irgendwo zu verstecken, wo es keiner sucht. Z.b. als irgendeine krude lib getarnt, unter den Tausenden (naja) anderen libs mit passendem Namen abgelegt, im Kopf des Files ein paar lib-typische Bytes und den ganzen Vorgang in einem compilierten und gestrippten Proggy ausführen lassen, welches auch unter Tausenden ähnlichen versteckt ist, z.B. in /usr/bin oder den kde-bins, jeweils mit passendem Namen, da kann ein Angreifer sich totsuchen, Du mußt nur dafür sorgen, daß nirgends auswertbare ASCII-strings in den Dateien auftauchen, aber das ist ja einfach. Statt z.B. strcpy(passwort,"xxx"); kann man in C doch sehr schön schreiben y=6; passwort[0]=20*y; passwort[1]=...;passwort[3]=´\0´; [ausbaufähig], das kann im compilierten Zustand keiner mehr sehen und alle Deine binarys debuggen ... naja. "Der Weise versteckt ein Sandkorn am Strand" (Konfutse) -- may the tux be with You! Joerg Thuemmler sysadmin@vordruckleitverlag.de Vordruck Leitverlag GmbH Berlin, ZNL Freiberg Halsbruecker Str. 31b, 09599 Freiberg, Germany Tel. +49 (0)3731/303121
Hallo Liste, hallo Joerg, Joerg Thuemmler wrote:
Quatsch. Wenn ich an den Server rankomme, um ihn zu klauen, kann ich wahrscheinlich auch die - gemountete - Partion einsehen.
Da es sich um Backups für Webserver handelt, kann man an einen Teil sogar übers Internet einsehen. Was er auf der Backup-Partition sehen kann sind irgendwelche Backuparchive sei es tar oder was auch immer. Wer die Daten aber gründlich auswerten will, wird sich aber nicht an den PC setzen und es dort machen. Weitere besteht die Möglichkeit, die Partition nur zum Zeitpunkt der Sicherung zu mounten, das setzt aber voraus, daß dann eine authorisierte Person am PC ist um sie zu mounten. Weiter Sicherheitsmechanismen wie Rechtvergabe für User etc. müssen natürlich auch sehr strickt gehandhabt werden. Wenn ein User (vieleicht sogar ROOT ) sich beim Verlassen des Arbeitsplatzes nicht auslogt ist dies sträflicher Leichtsinn. So müssen mehrere Sicherheits- mechanismen überwunden werden. Sicherheit definiert sich nicht in einem Sicherheitsmechanismus, sondern in der Summe aller Sicherheitsmechanismen die angewandt werden.
Wenn schon, denke ich, ist es klüger sowas - leicht verschlüsselt ^^^^^^^^^^^^^^^^^^^^ Ein gefundenes Fressen für Scriptkiddys.
mittels irgendeines, z.B. Kompressionsproggis, irgendwo zu verstecken, wo es keiner sucht. Z.b. als irgendeine krude lib getarnt, unter den Tausenden (naja) anderen libs mit passendem Namen abgelegt, im Kopf des Files ein paar lib-typische Bytes und den ganzen Vorgang in einem compilierten und gestrippten Proggy ausführen lassen, welches auch unter Tausenden ähnlichen versteckt ist, z.B. in /usr/bin oder den kde-bins, jeweils mit passendem
Großer Gott bewhre uns vor einem neuen Führer der Security-by-Obscurity-Sekte
Namen, da kann ein Angreifer sich totsuchen, Du mußt nur dafür sorgen, daß nirgends auswertbare ASCII-strings in den Dateien auftauchen, aber das ist ja einfach. Statt z.B. strcpy(passwort,"xxx"); kann man in C doch sehr schön schreiben y=6; passwort[0]=20*y; passwort[1]=...;passwort[3]=´\0´; [ausbaufähig], das kann im compilierten Zustand keiner mehr sehen und alle Deine binarys debuggen ... naja.
Und wo hast du das Programm? Doch nicht etwa auf dem Rechner, schon mal was von deassemblieren gehört?
"Der Weise versteckt ein Sandkorn am Strand" (Konfutse)
Weise! Weise! Aber beachte mal die Mengenverhältnise. Ein Sandkorn unter z. B. 500 ist aber sehr schnell gefunden, oder willst du jetzt hergehen und 1Mio. Programm ungfähr gleicher Größe und Struktur generieren nur um eins zu verstecken? cu Gerald
participants (4)
-
Gerald Goebel -
Joerg Thuemmler -
Marc Schiffbauer -
Peter Blancke