Ich würde mir eine IP-Adresse als "irgendwo, wo Sie sind" vorstellen und nicht als das traditionelle "etwas, das Sie wissen", "etwas, das Sie haben" und "etwas, das Sie sind", das Teil der 3-Faktor-Authentifizierung ist.

Obwohl IP-Adressen trivial zu fälschen sind, sind es keine TCP-Verbindungen und SSH ist ein Protokoll, das auf TCP aufbaut. Die IP-Adresse einer TCP-Verbindung ist ein zuverlässiger Indikator dafür, mit wem Sie direkt verbunden sind.

Angenommen, ich beschränke SSH-Verbindungen nur auf meine Büro-IP-Adresse, ein Angreifer geht Um Folgendes tun zu müssen:

1. In oder in der Nähe (wenn er das WLAN knackt) meines Büros
2. Seien Sie auf dem Weg zwischen meinem Büro und meinem Server (sagen wir drinnen) unser ISP).
3. Kontrollieren Sie eine Maschine in meinem Büro.
ol>

Punkt 3. ermöglicht es dem Angreifer, sich überall auf der Welt zu befinden, erhöht jedoch die Schwierigkeit eines Angriffs.

Die Punkte 1. und 2. reduzieren die Anzahl der Personen, die die anderen Faktoren (wie Ihren SSH-Schlüssel oder Ihr Kennwort) erfolgreich verwenden können, erheblich, wenn sie diese erwerben können Ich halte es für lohnenswert.

Die Qualität der IP-Adresse ist hier ein wichtiger Faktor. Ich habe mein Büro als Beispiel oben verwendet. Wenn Sie jedoch eine dynamische IP-Adresse haben, vertrauen Sie dem gesamten Bereich, den Ihr ISP besitzt? Wie wirkt sich das darauf aus, wie einfach es für einen Angreifer ist, eine dieser IP-Adressen zu erhalten? Ändert sich die Vertrauenswürdigkeit einer IP-Adresse, wenn Sie wissen, dass 10 Computer von NAT dahinter versteckt sind? Was ist, wenn es 2.000 Computer und 100 drahtlose Zugangspunkte gibt?

Ich würde eine IP-Adresse nicht als eigenständigen Faktor betrachten.

Bei ordnungsgemäßer Ausführung kann dies eine nützliche Ergänzung Ihres Sicherheitsprotokolls sein. Ich würde jedoch sehr zögern, es zu verwenden, um einen bereits vorhandenen Faktor in Ihrer Authentifizierung zu ersetzen, da IP-Adressen keine geheimen Informationen sind (Sie geben sie an jede Website weiter, die Sie besuchen) und abhängig davon, wie / wo Sie die IP abrufen Adresse von, könnte trivial zu fälschen sein. Wenn Sie jedoch die IP-Adresse einer TCP-Verbindung in Verbindung mit beispielsweise einem gespeicherten sicheren Nur-http-Cookie verwenden, können Sie eine gewisse Sicherheit hinzufügen. Insbesondere würden Sie das Cookie ungültig machen, wenn sich die IP-Adresse ändert (was sich aus harmlosen Gründen ändern kann, z. B. wenn Ihr ISP Ihre IP neu zuweist) sowie aus böswilligen Gründen (der Angreifer hat Ihr Cookie erhalten).

As Ladadadada sagte, IP-Adressen in TCP-Verbindungen seien nicht mehr leicht zu fälschen. TCP erfordert ein Handshake-Verfahren, um eine zufällige 32-Bit-Sequenznummer vom Server abzurufen, bevor Sie Informationen austauschen können. Wenn Sie beim Starten des Handshake-Vorgangs eine völlig falsche zufällige IP-Adresse fälschen, werden die Pakete nicht über das Internet an Ihren Computer weitergeleitet, sodass Sie den Handshake nicht abschließen können. Es sei denn, Sie steuern Zwischenrouter beim ISP oder einen Computer in einem der gleichen lokalen Netzwerke, die die an eine andere Stelle gerouteten Pakete erfassen könnten. In diesem Fall könnten Sie zufällige IP-Adressen fälschen.

Wenn jedoch Wenn Sie eine Web-App entwerfen und die IP-Adresse aufzeichnen, müssen Sie vorsichtig sein. Angenommen, Sie haben eine Web-App mit zwei Webservern (z. B. einem für dynamischen Inhalt und einem für statischen) hinter einem Load Balancer oder einem anderen Proxy. Sie können durch Ausprobieren feststellen, dass die IP-Adresse des Clients nur im HTTP-Header X-Forwarded-For vorhanden ist. Dieses Feld ist jedoch leicht zu ändern. Beispiel: telnet www.whatismyip.org 80 und geben Sie Folgendes mit / ohne X-Forwarded-For für die Zeile ein (denken Sie daran, nach der letzten Zeile zweimal die Eingabetaste zu drücken, um dies anzuzeigen das Ende Ihrer HTTP-Anfrage).

  GET / HTTP / 1.1
Host: www.whatismyip.orgX-Forwarded-For: 1.2.3.4  

und Sie werden sehen, dass diese Web-App denkt, Ihre IP-Adresse hat sich in 1.2.3.4 geändert Code>. Testen Sie also gründlich. Insgesamt denke ich, dass dies mehr Arbeit ist als es wert ist, zumal es Benutzer frustrieren kann, deren IP-Adressen sich ziemlich häufig ändern.

BEARBEITEN: Nachdem ich dies geschrieben habe, wurde mir klar, dass ich die Titelfrage beantwortet habe (' Kann die IP-Adresse eine Komponente der 2-Faktor-Authentifizierung sein? "), aber nicht der spezifische Teil, der sich auf die SSH-Verwaltung bezieht. Ich würde sagen, der durch die SSH-Passphrase geschützte Schlüssel ist im Wesentlichen eine Zwei-Faktor-Authentifizierung: etwas, das Sie haben (der SSH-Schlüssel), und etwas Sie wissen (der Schlüssel der Passphrase).

Technisch gesehen ja, aber das Hinzufügen eines zweiten Faktors, der für die Fälschung trivial ist, erhöht Ihre Sicherheit nicht wesentlich.

Angenommen, Ihnen wurde aufgrund einer Art Risikobewertung die Verwendung von 2-Faktor empfohlen Wenn Sie eine stärkere Authentifizierung benötigen, sollten Sie nach besseren Steuerelementen suchen.

(Führen Sie die IP-Whitelist auch durch - sie ist nicht sehr stark, dauert aber nur ein oder zwei Minuten. Warum also nicht?)

Das Wichtigste ist: Denken Sie daran, dass "2-Faktor" keine magische Phrase ist, die Sie sicher macht. Sie müssen das Risiko verstehen und entsprechend strenge Kontrollen implementieren.

Normalerweise bezieht sich die 2-Faktor-Authentifizierung auf etwas, das Sie "kennen" und das Sie "haben". Das "Wissen" ist ein Passwort und "Haben" sind SSH-Schlüssel. Diese können so verwendet werden, wie Sie sie jetzt verwenden, oder auf einer Art Smartcard oder Dongle (auf die sshd dann über die GSSAPI zugreift; siehe man sshd_config ).

Ich denke, die Person, die Sie zur Verwendung der 2-Faktor-Authentifizierung aufgefordert hat, möchte, dass Sie Schlüssel und Kennwörter verwenden (wenn jemand Ihren Schlüssel stiehlt, spielt dies keine Rolle, da er das Kennwort auch nicht kennt).

Eine IP-Adresse ist nicht wirklich etwas, das Sie "besitzen", da sie, wie Sie gesagt haben, gefälscht werden kann. Gleiches gilt für MAC-Adressen. Sie können den SSH-Zugriff auf bestimmte IP-Adressen / -Bereiche jedoch trotzdem sperren, um die Belästigung des SSH-Servers zu erschweren. Wenn Sie beispielsweise sshd auf dem Standardport im Internet ausführen, versuchen viele Leute, Passwörter usw. brutal zu erzwingen. Die Beschränkung auf IP-Adressen sollte dabei helfen, da mehr Persistenz und Konfiguration erforderlich sind, um die IP zu fälschen. Fügen Sie in /etc/hosts.deny

 sshd,sshdfwd-X11:ALL 

und eine Zeile ähnlich der folgenden ein Dies in / etc /hosts.allow

  sshd, sshdfwd-X11: 192.168.0.0/255.255.255.240sshd,sshdfwd-X11: 127.0.0.1  

(die obige IP-Adresse / Subnetzmaske definiert einen Adressbereich; dies ist nur ein Beispiel).

Überprüfen Sie diese Art von Änderungen immer genau, da Sie dies nicht tun Sie möchten sich versehentlich von Ihrem Server ausschließen. Lassen Sie während des Testens immer eine Sitzung angemeldet (da diese Änderungen nur neue Anmeldungen betreffen).

Ist die Semantik hier relevant? Dass Ihnen "empfohlen wurde, die 2-Faktor-Authentifizierung zu verwenden", deutet darauf hin, dass jemand dies von Ihnen erwartet. Ist es also nicht sinnvoller, von der Person mit der Erwartung herauszufinden, was als akzeptabel angesehen wird?

Nein. Sie sollten sich nicht auf die IP-Adresse verlassen, um viel Sicherheit zu bieten. Wenn jemand eine Verbindung über ein offenes drahtloses Netzwerk herstellt (z. B. von seinem Smartphone oder von seinem Laptop in einem öffentlichen Café), ist es trivial, einen Man-in-the-Middle-Angriff durchzuführen oder seine IP-Adresse zu fälschen. Für diese Benutzer bietet die IP-Adresse keine zusätzliche Sicherheit.

Wenn Sie daher aufgefordert wurden, die 2-Faktor-Authentifizierung zu verwenden, sollten Sie die IP-Adresse des Clients nicht als zweiten Faktor behandeln. Für einige Ihrer Benutzer ist dies im Grunde genommen nutzlos.

Ich würde sagen, dass es in Ordnung ist, SSH-Verbindungen zu filtern, um nur solche aus einem begrenzten IP-Adressbereich zuzulassen. Dies könnte etwas zunehmen. Zählen Sie es jedoch nicht als zweiten Faktor! Wenn Sie eine Zwei-Faktor-Authentifizierung benötigen, verwenden Sie zwei reale Faktoren. Versuchen Sie nicht, mit einem falschen zweiten Faktor "einen schnellen zu ziehen".

Lassen Sie mich eine kleine Geschichte über ein anderes Industriesegment erzählen, das ein schnelles Segment mit 2-Faktor-Authentifizierung erstellt hat. Vor einigen Jahren haben die US-Bankenaufsichtsbehörden eine Verordnung verabschiedet, nach der alle US-Banken die Zwei-Faktor-Authentifizierung für das Online-Banking verwenden müssen. Eine plausible Anforderung, insbesondere wenn Sie sich Sorgen über Phishing-Angriffe machen, um die Bankkennwörter von Personen zu stehlen. Aber dann gingen die Banken und wurden "klug" (und das meine ich nicht gut) darüber, wie sie die Anforderung umsetzten. Sie entschieden, dass Ihr Online-Banking-Passwort der erste Faktor ist (bisher in Ordnung) und ein dauerhaftes Cookie auf Ihrem Computer der zweite Faktor ist (gut, plausibel). Aber wie haben sie den dauerhaften Cookie auf Ihren Computer bekommen? Wenn Sie den Cookie nicht haben, stellen sie Ihnen Ihre Herausforderungsfrage, und wenn Sie die richtige Antwort geben können, geben sie Ihnen den Cookie. Am Ende sind ihre beiden Faktoren also: (1) ein Passwort und (2) ein anderes Passwort (die Antwort auf Ihre Herausforderungsfrage). Dies macht den Zweck der Zwei-Faktor-Authentifizierung zunichte. Zum Beispiel kann ein Phisher einfach nach beiden Passwörtern fragen. In der Tat haben einige Studien herausgefunden, dass diese Form der Zwei-Passwort-Authentifizierung nicht sicherer gegen Phishing ist als die Ein-Passwort-Authentifizierung. Sei also nicht wie die Banken. Behandeln Sie die 2-Faktor-Authentifizierung nicht als etwas, das Sie spielen können, da Sie dann die Sicherheitsvorteile negieren.

In gewissem Sinne ja. Aber es geht eher um Semantik als um Sicherheit.

In gewissem Sinne kann eine IP-Adresse als "etwas, das Sie sind" oder "etwas, das Sie haben" betrachtet werden. Das heißt, wenn der Zugriff nur auf einen begrenzten Satz von IP-Adressen beschränkt ist, muss ein Angreifer eine dieser IP-Adressen "sein" oder "haben", um einen Angriff auszuführen - wie dies geschehen würde, hängt vom Szenario ab und Technologie, aber es wird sicherlich Ihre Angriffsfläche drastisch verringern.

Die Semantik ist Teil des Arguments, ob dies als zweiter Faktor zählt oder ob es nur ein ist wirklich gute zusätzliche Sicherheit. Technisch gesehen sind Sie weder Ihre IP-Adresse noch Ihre. Abhängig von der Netzwerkstruktur kann jemand anderes die Kontrolle darüber übernehmen. Das Gleiche gilt jedoch für jede andere Authentifizierungstechnologie - alles hängt von der Implementierung ab.

Das einzige Mal, wenn es wirklich darauf ankommt, ob als zweiter Faktor zählt oder nicht, ist im Rahmen einer Art Prozessprüfung oder eines größeren Rahmens, in welchem ​​Fall qualifizierende Faktoren aufgeführt werden sollten. Ansonsten streiten sich nur Nerds.

Ich würde sagen, dass das Erfordernis eines Passworts und das Auferlegen einer IP-Beschränkung eine sehr vernünftige Sicherheit darstellt, solange die entsprechenden Richtlinien strikt eingehalten werden. Es ist sicherlich besser als nur das Passwort allein.

Sie sollten die IP-Adresse nicht als Authentifizierungsfaktor verwenden. Es ist einfach, eine IP-Adresse zu fälschen, anstatt andere Mittel wie biometrische zu knacken. Ein Skript-Kiddie kann dies problemlos tun.

Wie können Sie mit unbeabsichtigten IP-Adressänderungen wie bei der Verwendung von VPN umgehen? Es gibt viele Lösungen für die Verwendung der SSH-Zwei-Faktor-Authentifizierung. Sie können sie einfach googeln.

IP wäre einfach viel zu leicht zu fälschen oder sogar anhand eines Subnetzes zu erraten. Nur so viele Möglichkeiten. Ich würde es nicht für nützlich halten. Es gibt viele andere 2-Faktor-Systeme, die einfach und funktionsfähig sind. Schauen Sie sich LinOTP und OpenOTP an.

Eine weitere Option besteht darin, den Zugriff nur auf Computer zu beschränken, die eine Smartcard verwenden oder für die bereits eine andere Form des 2-Faktors aktiviert ist.

Eine praktische Antwort, die Sie vielleicht glauben oder nicht glauben.

Ich habe einmal für ein Unternehmen gearbeitet, das eine kleinere Site für MasterCard erstellt hat. Wohlgemerkt, es war nichts sehr sicherheitsrelevantes, keine CC-Nummern, keine Transaktionen. Ein kleiner Wettbewerb mit kleinen Preisen. Dies bedeutet jedoch, dass die Site über einen Anmeldemechanismus und einige persönliche Informationen (Login, E-Mail, möglicherweise sogar Postanschrift) verfügt. Die MC-Verfahren forderten eine Form von 2FA für die Verwaltung der Produktionsserver und die IP-basierte Filterung, die auf 1 IP-Adresse (Gateway vom Gebäude) beschränkt war. Auf der anderen Seite war die Seite so niedrig, dass sie sich nicht die Mühe gemacht haben, tatsächlich zu überprüfen, was wir gesagt haben. Sie haben unser Wort dafür genommen. Aber das Einfügen des IP-Filters als 2FA war ihre Idee, sie haben explizit danach gefragt, wir haben nicht wirklich gedacht, dass das Einschließen Teil von 2FA ist.