Frage:
Vorteile von Kill Sessions nach 5 Minuten?
jpmc26
2016-04-28 01:01:23 UTC
view on stackexchange narkive permalink

Ich habe es mit einem Server zu tun, den ich nicht konfigurieren kann. Irgendwo zwischen mir und diesem Server wird nach 5 Minuten jede Verbindung unterbrochen, wenn kein Datenverkehr zwischen den beiden Computern übertragen wird. Dies schließt aktive Verbindungen ein, bei denen ein Befehl auf dem Server ausgeführt wird. Insbesondere habe ich gezeigt, dass diese Trennung mithilfe einer SSH-Verbindung (Ausführen eines Bash-Befehls, der länger als 5 Minuten keine Ausgabe druckt) und einer SQL-Datenbank (Ausführen eines SQL-Befehls, der länger als 5 Minuten dauert) erfolgt. Es wird auch die Verbindung getrennt, wenn ich etwas lese und 5 Minuten lang keine Befehle sende.

Für die SSH-Einstellung hat die für den Server verantwortliche Gruppe empfohlen, die Client-Seite "Keep Alive" zu aktivieren. Sie haben keine Vorschläge für die Datenbankverbindungen gemacht.

Ich bin jedoch völlig verwirrt. Was ist hier der Sicherheitsvorteil? Für SSH kann ich ihre Einstellungen vollständig von der Clientseite aus umgehen, und sie empfehlen sogar, dies zu tun. (Letzteres bedeutet, dass es nicht einmal ein Argument "Sicherheit durch Dunkelheit" geben kann, da es nicht dunkel sein wird, da jeder Benutzer darüber Bescheid wissen muss. Nicht, dass ich denke, dass dies einen Angriff vereiteln würde, selbst wenn er dunkel wäre, insbesondere seitdem Ich habe es selbst herausgefunden, bevor sie es überhaupt empfohlen haben.) Für beide verschlechtert dies nachweislich die Verfügbarkeit. Ich konnte möglicherweise feststellen, dass das Trennen aktiver Sitzungen nach einigen Stunden Inaktivität von Vorteil sein kann (obwohl mir die möglichen Bedrohungen durch lange offene Sitzungen nicht sofort klar sind), aber alle 5 Minuten ? Dies bedeutet, dass ich nicht einmal einen DBA.SE -Post lesen kann, während ich mein SQL ausarbeite, ohne die Verbindung zu trennen. Ist das so lächerlich, wie es sich für mich anhört, oder fehlt mir etwas?

Erläuterungen

Einige Punkte wurden in Kommentaren erwähnt, daher möchte ich a klarstellen wenig.

  • Ich kann das Timeout nach 5 Minuten konsistent reproduzieren. Ich habe Befehle verwendet, die alle paar Sekunden eine Zeitstempelserverseite aufzeichnen, und nach einer Unterbrechung war der letzte aufgezeichnete Zeitstempel immer genau 5 Minuten nach dem ersten Zeitstempel. Die Unterbrechungen waren also nie sporadisch.
  • Kurz nachdem ich diesen Beitrag geschrieben hatte, antworteten die System- / Netzwerkadministratoren, dass dies tatsächlich beabsichtigt ist. Ich zitiere: "Mehr Fallout von dem 5-Minuten-Zeitlimit, das vor ein paar Wochen für die F5 festgelegt wurde?" Ich bin mir nicht sicher, was ein F5 ist. Einige Googler schlagen vor, dass es sich um einen sehr teuren Switch handelt, der jemandem entspricht, der versucht hat, eine Problemumgehung für meine DB-Verbindungen zu finden, und später die Switch-Einstellungen erwähnt.

(Ich glaube nicht, dass diese Informationen ungültig sind irgendwelche Antworten.)

Warum wird das Ihrer Meinung nach absichtlich gemacht?
@NickBastin Wegen der Reaktion der Systemadministratoren.Anscheinend ist dies eine kürzlich implementierte Änderung, und ich bin nicht der erste, der sie zur Sprache bringt.
Haben Sie es satt, die "ServerAliveInterval" -Optionen [.ssh / config] (http://linux.die.net/man/5/ssh_config) festzulegen?Dies führt zu periodischen "Ping" -Nachrichten auf der Anwendungsschicht, die den verschlüsselten Kanal durchlaufen, sodass der Proxy sie nicht von den tatsächlichen Daten unterscheiden sollte, die noch langsam fließen.Das sollte das Problem umgehen.
Außerdem ist mir aufgefallen, dass "TCPKeepAlive" [ssh-Option] (http://linux.die.net/man/5/ssh_config) standardmäßig aktiviert ist.Wenn es auf Ihrer Seite nicht ausgeschaltet ist, bedeutet dies, dass das Beenden der Verbindungen tatsächlich beabsichtigt ist, da Firewalls / Maskerades Verbindungen, die TCP-Keepalives senden, nicht beenden.Proxies werden dies jedoch tun, da TCP Keepalive leere Pakete sendet, die auf der Socket-Ebene nicht sichtbar sind.
@JanHudec Mir ist `ServerAliveInterval` bekannt, aber wie gesagt, dies ist nicht mein zu verwaltender Server.Was Sie erwähnen, ist natürlich die Serverseite, die den von mir erwähnten clientseitigen Einstellungen entspricht.Die Datenbank durchläuft meines Wissens jedoch nicht SSH, was darauf hinweist, dass das Beenden der Verbindung allgemeiner ist als SSH.Mir ist wirklich nicht ganz klar, wo genau sie dies durchsetzen, weshalb ich versucht habe, in der Frage nicht zu spezifisch zu sein und mich nur auf die Verbindungsbeendigung selbst zu konzentrieren.
@jpmc26, nein, `ServerAliveInterval` ist eine _client_ Option."ServerAliveInterval" und "TCPKeepAlive" sind sehr unterschiedliche Optionen.Wenn Sie SSH zum Server ausführen können und das Zeitlimit für SSH nicht überschritten werden kann, können Sie die Weiterleitungsfunktion verwenden, um die Datenbankverbindung durch den Server zu tunneln und ihn zu schützen.
@JanHudec: Das Standard-Keepalive-Intervall beträgt unter Linux und MSWindows 2 Stunden.
Es könnte vorhanden sein, um Ressourcen freizugeben, wenn es sich um einen gemeinsam genutzten Server oder einen Server mit viel Datenverkehr handelt.
Unabhängig von der eigentlichen sicherheitsrelevanten Frage, warum ein solches Szenario erstellt wurde: Wenn der Server über tmux oder screen verfügt, können diese Befehle die Wiederaufnahme einer getrennten Sitzung unterstützen. Dies kann ein effektiver Weg sein, um keine Arbeit zu verlieren.
Fünf antworten:
Steve Sether
2016-04-28 02:21:15 UTC
view on stackexchange narkive permalink

Ich bin jedoch völlig verwirrt. Was ist hier der Sicherheitsvorteil?

Nichts. Das wahrscheinlichste Szenario ist, dass dazwischen die Verbindung nach 5 Minuten unterbrochen wird, um Ressourcen zu sparen. Dies kann eine Firewall, ein WAN-Beschleuniger, ein SSL-Beschleuniger usw. sein. Oder es kann sich nur um eine schlechte Standardeinstellung handeln. Wer weiß?

Netzwerkadministratoren haben oft andere Bedenken als alle anderen, die oft mit anderen in Konflikt geraten können. Wir arbeiten in einer Silo-Welt, in der das ganzheitliche Bild nicht berücksichtigt wird.

Gehen Sie nicht davon aus, dass es für jede Einstellung einen besonders guten Grund gibt, sondern lassen Sie Raum für das Potenzial, dass das 5-minütige Timeout eine schnelle Lösung für ein anderes Problem war und Ihr Anwendungsproblem ein Rückschlag war .

Mir ist aufgefallen, dass SSH standardmäßig TCP Keepalive aktiviert.Dies würde verhindern, dass Firewall oder Maskerade die Verbindung trennen.Ein Proxy könnte dies immer noch tun, da TCP-Keepalives nicht angezeigt werden.
Der "Router", den ich von meinem Kabel-Internetprovider erhalten habe, hat nach 15 Minuten jede Verbindung getrennt.Saugt, wenn Sie SSH verwenden müssen.Ich fand heraus, dass dieses Stück billigen Plastiks nicht wirklich mehr als ~ 5000 offene Verbindungen verarbeiten konnte, ohne abzustürzen. Deshalb haben sie dies wahrscheinlich implementiert.
IME, die wahrscheinlichste Ursache ist nicht das Zeitlimit für die Verbindung, sondern eine schlecht konfigurierte Firewall mit einer überfüllten Statustabelle.
@symcbean Auch sehr gut möglich.Aber Sie würden erwarten, dass dies weniger regelmäßig als 5 Minuten ist.
Rory McCune
2016-04-28 01:18:43 UTC
view on stackexchange narkive permalink

Dies klingt nach einem guten Beispiel für einen Sicherheits- "Frachtkult". Eine Sicherheitskontrolle wurde blind implementiert, ohne den betreffenden Kontext zu verstehen oder tatsächlich korrekt zu implementieren.

In der Sicherheit bedeutet dies im Allgemeinen, dass ein Leerlauf-Timeout auftritt, um das Risiko von Situationen zu verringern, in denen ein Client-Computer unbeaufsichtigt bleibt und Ein böswilliger Benutzer gelangt zum Computer und führt nicht autorisierte Befehle auf dem Computer aus. Das Gleichgewicht in diesen Zeitüberschreitungen besteht in der Regel aus Benutzerfreundlichkeit (was längere oder keine Zeitüberschreitung begünstigt) und Sicherheit (was kürzere Zeitüberschreitungen begünstigt).

Manchmal können Sie Sicherheitsgüter mit genau dem, was Sie erwähnt haben, erkennen, nämlich dass die Betreiber des Systems Ihnen tatsächlich dabei helfen, die nominelle Kontrolle zu umgehen (in Ihrem Fall, indem Sie die Verwendung von Keep-Alives empfehlen) / p>

Das Risiko, dass Client-Computer unbeaufsichtigt bleiben, sollte verringert werden, indem sichergestellt wird, dass die automatische Bildschirmsperre konfiguriert ist.Unter Windows kann dies über Gruppenrichtlinien erzwungen werden.
Dies ist natürlich eine gute Idee, bei der Sie alle Client-Computer steuern und Richtlinien für sie durchsetzen können, obwohl ich wieder Umgebungen gesehen habe, in denen die Leute darauf bestehen, dies auf der Anwendungsschicht und der Betriebssystemebene anzuwenden, unabhängig davon ...
Sie übersehen den klaren Vorteil dieses Ansatzes: Wenn Sie sich bei einem System anmelden, Ihren lokalen Bildschirm sperren, eine Tasse Kaffee trinken, werden Sie feststellen, dass Ihre Sitzung abgelaufen ist, sodass Sie sich erneut anmelden könnenDadurch müssen Sie Ihr Kennwort erneut eingeben, wodurch das Muskelgedächtnis aufgebaut wird, sodass die Administratoren die Messlatte höher legen können, um Kennwörter mit 64 Zeichen und 4 Emoticons einzuschließen
Steffen Ullrich
2016-04-28 01:25:39 UTC
view on stackexchange narkive permalink

Ich bin jedoch völlig verwirrt. Was ist hier der Sicherheitsvorteil?

Es ist möglicherweise keine Frage der Sicherheit, hat aber einen anderen Grund. Leider bietet Ihre Frage nur Ihre Ansicht, sodass wir nur spekulieren können, was der wahre Grund sein könnte.

Eine Erklärung könnte sein, dass es einen einfachen Stateful-Paketfilter gibt, bei dem die Zustände nach 120 Sekunden Inaktivität ablaufen. Dies bedeutet, dass alle nach dieser Inaktivität übertragenen Daten blockiert werden, da kein offener Zustand mehr besteht. Der Grund dafür könnte ein Gerät sein, das nur über sehr begrenzte Ressourcen verfügt und daher nicht zu viele Zustände gleichzeitig offen halten kann, beispielsweise eine Firewall, die für 10 Benutzer konzipiert wurde und jetzt von 100 Benutzern verwendet wird.

Natürlich kann es auch sein, dass ein BOFH das System ausführt, was wahrscheinlich eher Ihre Ansicht zu diesem Thema ist :) Aber dies ist schwer zu sagen, ohne mehr Einblick in das tatsächliche System zu haben .

Ich bete, es ist kein Lastproblem.Ich habe dies in der Frage nicht erwähnt (daher verstehe ich, warum Sie die Möglichkeit zur Kenntnis nehmen), aber dies soll eine gesamte "Private Cloud" -Umgebung sein, in der Dutzende von Anwendungen für viele Entwicklungsteams gehostet werden.Und diese Einschränkung gilt auch für die Server, die der * Entwicklung * gewidmet sind.
Guter Punkt zu den Paketfiltern - ohne Zeitüberschreitung kann ein Angreifer einen SYN-Flood-Angriff ausführen.Das Zeitlimit begrenzt, wie lange dies nach dem Stoppen des Angriffs wirksam bleibt.
slebetman
2016-04-29 11:22:54 UTC
view on stackexchange narkive permalink

Wie Sie vielleicht bemerkt haben, hat dies überhaupt nichts mit Sicherheit zu tun. Stattdessen hat das Beenden langlebiger ruhender TCP-Verbindungen mit Fehlern zu tun - es ist eine Problemumgehung für fehlerhafte Software.

Eines der bekannteren Beispiele für Software, bei der TCP-Sitzungen hängen bleiben, ist Internet Explorer ( mindestens bis Version 7). IE hatte die Angewohnheit, TCP-Sitzungen nicht korrekt zu beenden. Während auf dem Client-PC / Laptop / Telefon der Socket als geschlossen betrachtet wird, sieht der Server die Verbindung weiterhin als offen an. Und IE ist nur eines der bekannteren Beispiele. Es gibt viele fehlerhafte Software.

Warum sollte sich ein Server darum kümmern? Weil jeder offene Socket auch ein offener Dateideskriptor ist. Wenn diese Situation nicht behandelt wird, geht dem Server der Dateideskriptor aus. Theoretisch kann dem Server auch die Socket-ID ausgehen, aber diese Anzahl ist viel, viel höher als die Anzahl der offenen Dateideskriptoren, die ein Betriebssystem verarbeiten kann.

Aus diesem Grund enthalten verschiedene Implementierungen des TCP-Stacks a Zeitüberschreitung bei toten Steckdosen. Unter einigen Betriebssystemen können Sie dieses Zeitlimit konfigurieren.

Serge Ballesta
2016-04-29 14:11:40 UTC
view on stackexchange narkive permalink

Bei inaktiven TCP-Sitzungen, die in Routern, Switches und all diesen Low-Level-Netzwerkmaschinen implementiert sind, tritt fast immer eine Zeitüberschreitung auf. Es hat wenig mit Sicherheit im Sinne eines Schutzes vor einem absichtlichen Angriff zu tun, aber versuchen Sie einfach, die Ressourcen nicht zu erschöpfen, weil fehlerhafte Software die Verbindung nicht schließen kann oder andere Hardwarefehler im externen Netzwerk verhindern, dass das schließende Paket sein Ziel erreicht / p>

Aufgrund dieser möglichen vorübergehenden Fehler würde eine Netzwerkausrüstung (die normalerweise nie zurückgesetzt wird, wenn sie nicht unterbrochen wird), die niemals eine inaktive Verbindung auslöst, zu einem Ressourcenmangel führen und selbst einen Deny-of-Service erzeugen ...

Das Schlimmste ist, dass es sich häufig um ressourcenarme (kostengünstige) Systeme handelt. Aus diesem Grund bemühen sich Netzwerkadministratoren, das Risiko zu verringern, dass ihr Teil unter Last abstürzt und daher häufig verwendet wird aggressive Auszeiten. Dies ist der Grund für die Verwendung der Keep-Alive-TCP-Verbindung (wenn das Keep-Alive-Paket erfolgreich ist, befindet sich am anderen Ende etwas) in Kombination mit kurzen Netzwerk-Timeouts.

Das eigentliche Problem hierbei ist jedoch, dass Anwendungsentwickler nur wenig über Low wissen Netzwerknutzung auf Ebene, und dass Netzwerkadministratoren sich nicht für Anwendungen auf hoher Ebene interessieren. Das Leben ist so ...



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...