... jedes beabsichtigte umgehen einer unternehmensfirewall durch einen tunnel oder so kann ein kuendigungsgrund sein. also lasst euch net erwischen ;)) mfg olli
Was, das glaub ich nicht. mit ssh hat man ja schließlich nicht mehr Rechte, als wie wenn man in der Firma vor dem Rechner sitzt.
Wenn die Firma das aus irgendwelchen Gründen nicht will, dann sollte sie das dadurch zum Ausdruck bringen, daß sie kein sshd installiert, oder sshd entsprechend konfiguriert.
Was glaubst Du wozu eine Firewall und ein Tunnel da sind? Damit man z. B. trotz Firewall immer noch mit dem Büro in XYZ über einen *Tunnen* kommunizieren kann... nennt sich auch VPN
Kündigungsgrund... das ich nicht lache. Das müsstest Du schon begründen.
Weil die Firewall DIE zentrale Instanz ist, auf welcher gefiltert wird, welche Unternehmensdaten die Firma verlassen duerfen oder nicht !!!!! Mit so eine Mechanismus "verlaengerst" Du das Unternehmensnetz nach aussen hin, und damit ist es fuer das Unternehmen nicht mehr kontrollierbar was dort geschieht. Mit so einem Tunnel umgeht man aber alle Sicherheitsrichtlinien des Unternehmens. Wo kaeme man denn hin, wenn jeder User sich eigene Tunnel nach draussen aufbaut!!!
Ich denke schon, das solche gewagten Aktivitaeten u.U. schon disziplinare Massnahmen des Unternehmens gegen solche BASTLER nach sich ziehen koennen! Wenn ein remoter Zugang zum Unternehemn benoetigt wird, sollte dieser Zentral eingerichtet werden, und den jeweiligen Bedurfnissen der Nutzer angepasst werden.
hallo . also rein rechtlich gesehen zieht das gar nix nach sich. wenn die firma so etwas nicht wünscht muss sie das in den arbeitsvertrag reinschreiben oder dich belehren. ist das nicht der fall kannst du jeden dienst benutzen den freigegeben ist. ausserdem ist es möglich der firewall zu sagen wer ssh machen darf und wer nicht, sodas die sicherheit der firma absolut nicht gefährdet ist.
Meine Posting sollte auf KEINEN Fall eine Kritik an dem Artikel sein. Danke pro-Linux das es euch gibt, Ihr seit einfach Spitze !!!!
Mein Beitrag spiegelt nur generelle Gedanken zum "eigenmaechtigen" Tunneln von Verbindungen wieder. Das gabs auch schon bei uns im Unternehemen. Hier sollte warscheinlich ein privater Mailserver unterm Schreibtisch per http ins Internet getunnelt werden !!!
Richtig ist: Eine Firewall soll kontrollieren, welcher Verkehr vom Firmennetz nach außen und andersherum fließen soll und durch diese Kontrolle die Sicheheit erhöhen.
Wenn es nun möglich ist, dass ein Benutzer mittels eines Programmes (ssh) das Unternehmensnetzwerk nach außen "verlängert", so kann dies genausogut mit einem anderen Programm mit oder ohne Wissen des Benutzers passieren, man denke an Würmer, Hacker, weißderteufelwas...
Also: Wenn eine Firewall ein Unternehmensnetzwerk vor Tunneln schützen soll, dies aber mit ssh möglich ist, hat die Firewall versagt.
>Die Argumentation ist schlichtweg falsch! Danke fuer die Blumen Schau dir den Thread an, was ist bitte falsch an meiner Argumentation. Der einzige welcher hier von einem ssh-Tunnel spricht ist haertie.
Ich habe nie behauptet, das eine Firewall richtig konfiguriert ist, wenn sie von ueberall aus dem Firmannetz es ermoeglicht, einen ssh-tunnel aufzubauen! Bei diesem Thread ging es lediglich darum, welche rechtlichen Konsequenzen entstehen koennten, wenn sich jemand einen Tunnel nach aussen aufbaut, ohne dafuer eine Genehmigung von der Firma zu besitzen.
>Wenn es nun möglich ist, dass ein Benutzer mittels eines Programmes (ssh) das Unternehmensnetzwerk nach außen "verlängert", so kann >dies genausogut mit einem anderen Programm mit oder ohne Wissen des Benutzers passieren, man denke an Würmer, Hacker, >weißderteufelwas...
Richtig! Das geht aber auch mit einer Firewall/Proxy, welcher keine ssh durchlaesst. Es ist "relativ simple" einen Proxyfaehigen" http Tunnel zu schreiben. Da nutzt die best konfigurierteste Firewall nichts mehr. Das ist ja auch da Problem von Outlook und VB-Scripten.
> Der einzige welcher hier von einem ssh-Tunnel spricht ist haertie.
Ich dachte, du hättest auf slow geantwortet, welcher da schrieb: > Damit man z. B. trotz Firewall immer noch mit dem Büro in XYZ über > einen *Tunnen* kommunizieren kann... nennt sich auch VPN
Ich finde die Argumentation, dass rechtliche Folgen entstehen können, wenn ein Benutzer einen Weg, der sowieso schon vorhanden ist, geht, nach wie vor falsch. Anders sieht es natürlich aus, wenn explizit vereinbart wurde, dass der Weg verboten ist. Leider argumentieren da viele Firmen anders bzw. es fehlt das technische Verständnis, zu erkennen, das der Weg schon immer da war.
> Richtig! Das geht aber auch mit einer Firewall/Proxy, welcher keine ssh durchlaesst. > Es ist "relativ simple" einen Proxyfaehigen" http Tunnel zu schreiben.
Das meinte ich unter anderem.
Ein anderes Beispiel wäre folgendes Szenario:
Ein Anwender möchte ab und zu Sachen nicht über die Firmendrucker drucken. Er schickt sie deshalb per mail zu sich nach Hause.
Ist das rechtlich abgesichert? - Sicherlich ja.
Alternativ könnte er einen ssh (ofer http,..)-tunnel verwenden, um die Daten von Firma -> nach Hause zu schaffen. Ich sehe da faktisch keinen Unterschied (sofern wirklich nur die Daten übertragen werden)
Nun könnte man ja sagen, über der tunnel könnte man auch sensible Daten übertragen, weshalb so ein Tunnel rechtliche Folgen haben könnte.
Was ist nun aber der Unterschied, ob die Daten über einen tunnel oder per email übertragen werden? Es gibt offenbar keinen.
Im Fall der unerlaubten Übertragung hat der Mitarbeiter sicherlich rechtliche Konsequenzen zu befürchten (so die Weitergabe sensibler Daten im Arbeitsvertrag untersagt wurde), im anderen Fall meiner Meinung nach nicht.
Fazit: Ein Computer ist nur dann sicher vor der Übertragung sensibler Daten wenn er nicht mit der Welt verbunden ist.
Bei VW, Bosch oder anderen großen Unternehmen machst du das auch nur bis du erwischt wirst.
Du brauchst sogar eine Erlaubnis, um deine Diplomarbeit, die du für eine solche Firma machst, auf einem Datenträger mit nach hause zu nehmen. Da sind die von solchen "Tunnel"-Aktion garantiert begeistert. Bevor ich so etwas machen würde, würde ich mir erst einmal eine Erlaubnis vom Chef holen. Fragen kostet schließlich nichts
Wenn die Firewall Policies einer Unternehmensfirewall SSH nicht zulassen, so hat das sicher den Grund, dass das Unternehmen SSH Verbindungen zum lokalen Netz nicht zulassen will/kann/moechte oder darf. Dann sollte auch kein Tunneling solcher Verbindungen erfolgen. Andernfalls waere ja eine entsprechende Policy in der Firewall vorhanden, die SSH Verbindungen (zu bestimmten Rechnern und/oder von bestimmten Clients) erlaubt.
Also waere so ein Tunneling ohne ausdrueckliche Erlaubnis des zustaendigen Admins oder Security officers (auf Neudeutsch CSO) schon ein Kuendigungsgrund, da vertrauliche Unternehmensdaten fuer den Zugriff von aussen bereitgestellt werden.
Sicherlich wird dies aber von Unternehmen zu Unternehmen differenziert betrachtet und auch behandelt. Grossunternehmen verstehen in der Regel hier keinen Spass.
Bestimmt nicht dazu, dass Herr F. Bar seinen virenverseuchten Privatrechner unter Umgehung der zentralen Sicherheitsvorkehrungen ins Firmen LAN haengt.
VPNs werden normalerweise von der Firma bereitgestellt, und nicht von Laien durch Doppelklick auf irgendeine Exe inkl. Rumprobieren, bis es funktioniert, installiert.
also, erst einmal, ssh ist verschlüsselt. d.h. die mutmaßliche firewall (sie muss eigendlich ein contend-filter haben...) kann nichts mit den daten anfangen. keiner weiss, was du durch den tunnel schickst. dann kommt das problem: in einem firmennetz, denke ich mal, man darf als "einfacher" anwender sowieso keine "server"-dienste anbieten. und wenn die admins so dumm sind, und ssh auf den lokalen rechnern installieren, haben sie entweder sehr gute gründe (in dem fall, wird die firewall halt dementsprechend packet technisch konfiguriert, sodass der anwender (oder potentieller cracker) keinen tunnel öffenen kann), oder sie haben keine ahnung. wenn du den tunnel öffnen kannst, dann weiß keiner, was da durch gegangen ist, und dass ist - denke ich mal - für einen chef nicht gerade beruhigend. also ist das mit der theorie und praxis auch etwas anderes. theoretisch, ist es kein problem, es ist ein sicherheitsloch, pracktisch ist es dein rauswurf. (untreue der firma gegenüber, mutmaßlicher datenraub, usw.) im endeffeckt ist es dann egal, warum du entlassen wurdest, du bist halt nicht mehr da...
um es mal mittels Beispiel auf den Punkt zu bringen: - Firma hat Socks-Server oder lässt aussgehende TCP-Verbindungen AUS dem Firmennetz nach DRAUSSEN zu. - Mitarbeiter connected sich per ssh über Socks "nach Hause" (vielleicht am besten auch noch per cronjob nachts von seiner Linux-"Spielkiste" initiiert) - Er richtet SSH-Port-Forwarding ein und hat dabei z.B. versehentlich auch noch "Gateway-Ports auf YES stehen. - Er forwardet Ports wie 21,22,25,80 oder was auch immer, um z.B. von zu Hause Zugriff auf entspr. Applikationen/Dienste IN der Firma zu haben. - Nunja - da sein Rechner am Internet hängt und regelmaessig die üblichen "Portscans" abbekommt(oder möglicherweise gar "owned" ist) - ratet mal auf welcher Maschine der Buffer-Overflow-Exploit wirkt, wenn der Hacker die Ports 21,22,25 oder 80 auf dem "zu Hause PC" offen vorfindet und sich daran zu schaffen macht??? naaaaa? Da iss nix mit Firewall oder Stateful Inspection... Die Firewall bekommt nicht weiter mit, dass da "innerhalb" der SSH Session eine TCP-Session getunnelt wird. (die wohlgemerkt aus der GEGENRICHTUNG aufgebaut wurde!)
Sorry - aber ich kann die Haltung verstehen: wäre ich IT-Verantwortlicher einer Firma, würde ich da eine ganz klare Policy aufstellen. Das fällt in dieselbe Kategorie wie: Illegaler Betrieb eines Modems am Arbeitsplatz und bewusste/unbewusste "Umgehung" der Firewall.....
Da hilft weniger Verbot oder Drohung sondern vielmehr Aufklärung. Wer SSH benutzt und selbständig administrieren kann, sollte auch in der Lage sein, ein Scenario wie dieses zu verstehen und als "dangerous" einzustufen.
ich habe das auch mal gemacht. Ich bin mir jetzt nicht sicher, aber aus meiner Erinnerung ist es so, dass das nur geht, wenn auf Rechner B in sshd_config
Wenn ich auf Rechner A bin und einen Rechner B hinter einer Firewall erreichen will, warum reicht dann ssh user@remote_pc nicht aus? Damit lande ich doch auf dem gewünschten PC, oder nicht? Oder anders gefragt: Was kann ich mit so einem Tip realisieren?
Von Peter Woelfel am Mo, 21. Oktober 2002 um 09:20 #
Naja, Du kannst z.B. auf diese weise auf einen Mailserver zugreifen. Wenn Du direkt auf dem Server bist, und kein Mutt oder sonstwas installiert ist, guckst Du erst mal in die Roehre. Und mbox-Files mit "less" zu lesen macht auch nicht wirklich spass. Also koenntest Du einfach POP3 oder IMAP per ssh "forwarden" und dann mit einem E-Mail-Client von ausserhalb zugreifen. Das geht z.B. mit dem UW-Imapd sehr gut, mit Cyrus hab ich es nicht probiert.
Das Problem besteht darin, daß der remote_pc, auf den ich mich einloggen will, hinter einer Firewall steht, die diese ssh-Anfrage von "außen" abblockt. Das wird durch den obigen Tip dadurch umgangen, daß von "innen" eine ssh-Verbindung nach "außen" geschaffen wird (das ist meist erlaubt), über die man sich dann von einem dritten Rechner auf dem Zielrechner der ssh-Verbindung einloggen kann.
Oftmals ist es einfach ganz schlicht die Tatsache, dass hinter der "Firewall" ein Netzwerk mit privaten Addressraum steht. "Firewall" kann hier schon ein einfacher Router sein, der Address-Translation (NAT) macht. Wenn der naemlich nicht den SSH-Port auf einen Rechner weiterleitet, auf den man sich einloggen kann, dann kann man halt kein SSH ins intenrne Netz machen. Also muss man von dem privaten Netz hinter der Firewall zunaechst eine Verbindung nach aussen herstellen und dann hat man durch diese Verbindung die Moeglichkeit, einen Tunnel herzustellen.
Ich gehe mal davon aus, dass es dann ein Kunedigungsgrund ist, wenn es entweder ausdruecklich untersagt wurde oder eigentlich von der Konzeption der Sicherheitspolitik her klar ist, dass soetwas nicht gestattet ist.
Wenn Du/Ihr selber der Admin seid, waere das auf jeden Fall ein Punkt, den man beim Aufbau einer Sicherheitspolitik beachten sollte. ciao Pierre
ich kann dem autor zum gelungenen tip nur gratulieren.
allen postern, die sich darueber sorgen machen, kann ich nur computer-aus empfehlen...
wenn ich lust habe, schreibe ich mal n script, um als pill hates email ueber offene relaying mailhosts an irgendwen zu schicken und sende das hierhin zum veroeffentlichen. schaetze, das geschrei ist da noch groesser...
nur vergessen die leute, dass wir in einem freien staat leben, in der informationen, solange sie nicht verboten sind, frei verteilt werden duerfen.
ob die anwendung erlaubt/toleriert/oder_was_auch_immer gewertet wird, obliegt der verantwortung des taetigen und das ist gut so.
wo kaemen wir denn hin, wenn alle nur windoze nutzten???
Wenn wir schon mal beim Tunneln sind, habe ich mal eine Frage an die anwesenden Experten.
PC B: -Webserver 80 -Eigener Server 1080
Wenn ich (PC A) jedoch hinter einem (Firmen)Firewall bin und mit einem Applet vom Webbrowser aus auf den Server im Internet zugreifen will, geht das nur über einen HTTP - Tunnel.
Wie muss ich jetzt den Server(PC B) einrichten, dass der Webserver und mein eigener Server auf Port 80 erreichbar sind?
Hmmm, soweit ich das verstehe, muss fuer die Realisierung dieses Tricks in mindestens eine Richtung der entsprechende High-Port (z. B. 50022) offen sein. Bei einer fernuenftig administrierten Sateful-Firewall ist aber eine Verbindung ueber High-Ports nicht moeglich, wiel diese in der Regel gesperrt sind.
Damit ist die Diskussion der Rechtlichen Aspekte natuerlich akademisch. Grundsaetzlich bin ich hier aber der Meinung, dass die Gefahr einer Entlasung oder Abmahnung vom Arbeitsvertrag und von Betriebsvereinbarungen abhängt.
Von M. Tschursch am Di, 22. Oktober 2002 um 14:01 #
Eine Umgehung der Sicherheitsmechanismen ( Firewall ) ohne Absprache mit den Verantwortlichen der Firma IST ein Kündigungsgrund. Punkt.
Die Firma hat schon durch die bloße Präsenz einer Firewall - Installation Ihre Sicherheitseinstellung zum Ausdruck gebracht. Für eine fehlerhafte Installation ist nicht die Firmenleitung sondern eher der zuständige Administrator/Dienstleister haftbar. Das befreit euch als Angestellte/Arbeitnehmer aber noch lange nicht von der Sorgfaltspflicht.
Natürlich sollte eine entsprechende Richtlinie zur Benutzung von (internen) Server und Arbeitsstationen existieren nur im Arbeitsvertrag haben solche Regelungen weiss Gott nichts zu suchen ( sonst steht da demnächst auch noch drin, dass ich mich aufm Klo hinzusetzen habe ). Auch hier gilt, die Firma muss deutlich zum Ausdruck bringen daß bestimmte Verbindungen/Konfigurationen usw. nicht erwünscht sind ... und eine Firewall ist Ausdruck genug.
M. Tschursch Consultan IT-Sicherheit Teleport Sachsen-Anhalt GmbH tschursch@tsa.de
P.S.: Warum schreit hier immer jeder nach Vorschriften und Regelungen ? Reicht denn nicht genug gesunder Menschenverstand aus um Zusammenleben zu können, neeeiiin ... am besten ihr bekommt noch gesagt (nat. schriftlich und notariel beglaubigt), wie man wo und wie lange Luft holen darf....
Von M. Tschursch am Di, 22. Oktober 2002 um 14:08 #
@thomas:
Nein, nicht ganz.
1. Was hat das mit stateful inspection zu tun ? 2. Wir der HighPort am äusseren Rechner aufgemacht ... das sieht die FW schon gar nimmer
Wie willst du ssh-session's nach draußen verbieten, FALLS die Firma draussen Rechner zu administrieren hat ?
Erstmal lesen, dann schreiben ...
Natuerlich ist der Artikel Hinweis gut und gemacht hab ich das auch schon oft genug, allerdings wie auch oben beschrieben entweder mit Erlaubniss oder bei NAT-Installationen ( d.h. nix Firewall ) .
Ich wollte nur mit euren Irrglauben aufräumen, der nach dem 1. Kommentar aufkam, denn der Mensch hat wirklich recht ... so sehr das eurer und meiner Robin Hood - Seele auf den Kranz geht.
> 1. Was hat das mit stateful inspection zu tun ? Bei einem einfachen Paketfilter sind die Highports in der Regel per Default offen, weil ein Paketfilter nicht weiss auf welchem Highport der Server die Clientanfrage beantwortet. Aber damit erzähle ich wohl nichts neues.
> 2. Wir der HighPort am äusseren Rechner aufgemacht ... das sieht die FW schon gar nimmer OK, vielleich habe ich hier ein Verständnisproblem (aussen, innen, vor der FW, hinter der FW, Rechner A, Rechner B). Ist der Highport wirklich offen? D.h. zum Beispiel per Portscan aus dem selben IP-Segment sichbar? Oder "lebt" er nur innerhalb der Session über Port 22? Wenn ja, dann hat das wirklich nichts mit Stateful Inspection zu tun.
Von M. Tschursch am Di, 22. Oktober 2002 um 17:33 #
Ob die Highports offen sind oder nicht hat mit Stateful Inspection so viel zu tun, wie Regen mit der Haarlänge von Schafen :)
Das kann man genauso mit einem einfachen Packetfilter verbieten ( Das == Highports ). Ob das nun sinnvoll ist oder nicht ist 'ne andere Frage
und btw.: - wer heute "Firewalls" ohne Stateful Inspection einsetzt - wer heutzutage nicht nach der Regel "Es alles verboten, ausser es ist erlaubt" Firewalls und Firmennetzwerke aufbaut der gehört eh (virtuell) erschossen. :D
Somit erübrigt sich auch die Feststellung das highports per default offen sind ... das sind sie nämlich nur, wenn ein Verbindungsaufbau von INNEN erfolgt. Alle Versuche von AUSSEN Verbindungen aufzubauen ( egal ob highports oder nicht ) sollten von einer __echten__ Firewall geblockt werden.
><und btw.: >- wer heute "Firewalls" ohne Stateful Inspection einsetzt >- wer heutzutage nicht nach der Regel "Es alles verboten, ausser es ist erlaubt" Firewalls >und Firmennetzwerke aufbaut der gehört eh (virtuell) erschossen. :D
Da stimme absolut zu.
Ich meinte uebrigens _nicht_, dass man Firewalls mit oder ohne Stateful Inspection daran unterscheiden kann , ob highports offen sind oder nicht.
Aber zurueck zur IP-Theorie: Wenn ich einen einfachen Paketfilter als "Firewall" einsetze, dann weiss dieses Teil nichts von Sessions. Das bedeutet, die Antwort des Servers auf eine Clientanfrage, zb. auf Port 80, erfolgt auf einen beliebigen Highport. Da ich (und der Paketfilter )diesen Port nicht kenne, muss ich doch wohl moeglichst alle Highports offen lassen, oder? Eine Ausname wuerden hier natuerlich Ports von Diensten bilden, die bekanntermassen Highports belegen, wie z.B. Webmin Eine Stateful Firwall erkennt dagegen doch zu welcher Anfrage (des Client) die Antwort des Servers gehoert, und laesst diese Antwort zu, obwohl die Highports für _Anfragen_ dicht sind. Sind wir und da einig?
Tja, und ob der Port 50022 in dem Beispiel von Kristian Peters wirklich offen ist, oder im "Tunnel" liegt weiss ich jetzt immer noch nicht so richtig
Dieses Setup bedeutet, dass man mindestens einen Account auf "äusserer Rechner" haben muss um die Weiterleitung nutzen zu können.
Der Port 50022 ist auf "äusserer Rechner" offen und die Verbindung wird über den vom ersten Kommando >> ssh -g -R 50022:localhost:22 login@B << aufgebauten Tunnel durch die FW geschleust.
Die FW "sieht" nur die ssh-Session von "A" auf "B" und die Natur einer veschlüsselten SSH-Session erlaubt der FW auch keine weitere Analyse der Verbindung.
Dies ist btw. grad in größeren Firmen der Hauptgrund für sog. gepiercte Firewalls... schlimmer sähe das Ganze noch aus, wenn man das Forwarding nicht auf "localhost" sondern auf das eth0 Interface ( also IP) des Rechners (B) legt. Dann braucht man nämlich nichtmal mehr einen Account für B um auf A zu kommen ( ist natürlich auch "bequemer" ).
Bei beiden Setups kann die FW nichts machen.
Wegen solcher Setups empfiehlt sich IMMER die Einrichtung einer DMZ einer Rules im Firewall, die Traffic von innen nach aussen WENN dann nur ueber eine DMZ "Verbindungsstelle" ( Applicationproxy , Server in DMZ ) erlauben.
Was nicht heisst, dass SSH Tunneling dann nicht mehr geht. Nein, es kann nur nicht mehr JEDER in der Firma machen, die einen acc auf den internen Server haben ....
ich setze seit einiger Zeit erfolgreich Putty ein um eine RDP-Session zu tunneln, um auf meinen XP Rechner zu Hause zuzugreifen.
Da ich so ja einen offenen Port (OpenSSH Server auf Windows XP) habe wollte ich das ganze noch sicherer machen und einen meiner Linux Server im Netz dazu missbrauchen um RDP zu tunneln. Der Vorteil: Ich könnte die IP zum vertrauten Netzwerk auf dem WinXP Client hinzufügen und man könnte SSH/RDP Sessions von aussen nur von der IP des Linux-Server aufbauen.
Diese Anleitung habe ich bisher benutzt, um die RDP-Sessions zu tunneln:
also lasst euch net erwischen ;))
mfg
olli
mit ssh hat man ja schließlich nicht mehr Rechte, als wie wenn man in der Firma vor dem Rechner sitzt.
Wenn die Firma das aus irgendwelchen Gründen nicht will, dann sollte sie das dadurch zum Ausdruck bringen, daß sie kein sshd installiert, oder sshd entsprechend konfiguriert.
cu
snobbbby
Damit man z. B. trotz Firewall immer noch mit dem Büro in XYZ über einen *Tunnen* kommunizieren kann... nennt sich auch VPN
Kündigungsgrund... das ich nicht lache. Das müsstest Du schon begründen.
Mit so eine Mechanismus "verlaengerst" Du das Unternehmensnetz nach aussen hin, und damit ist es fuer das Unternehmen nicht mehr kontrollierbar was dort geschieht.
Mit so einem Tunnel umgeht man aber alle Sicherheitsrichtlinien des Unternehmens. Wo kaeme man denn hin, wenn jeder User sich eigene Tunnel nach draussen aufbaut!!!
Ich denke schon, das solche gewagten Aktivitaeten u.U. schon disziplinare Massnahmen des Unternehmens gegen solche BASTLER nach sich ziehen koennen!
Wenn ein remoter Zugang zum Unternehemn benoetigt wird, sollte dieser Zentral eingerichtet werden, und den jeweiligen Bedurfnissen der Nutzer angepasst werden.
MfG
Tim Stone
also rein rechtlich gesehen zieht das gar nix nach sich. wenn die firma so etwas nicht wünscht muss sie das in den arbeitsvertrag reinschreiben oder dich belehren. ist das nicht der fall kannst du jeden dienst benutzen den freigegeben ist.
ausserdem ist es möglich der firewall zu sagen wer ssh machen darf und wer nicht, sodas die sicherheit der firma absolut nicht gefährdet ist.
bye
Meine Posting sollte auf KEINEN Fall eine Kritik an dem Artikel sein.
Danke pro-Linux das es euch gibt, Ihr seit einfach Spitze !!!!
Mein Beitrag spiegelt nur generelle Gedanken zum "eigenmaechtigen" Tunneln von Verbindungen wieder. Das gabs auch schon bei uns im Unternehemen. Hier sollte warscheinlich ein privater Mailserver unterm Schreibtisch per http ins Internet getunnelt werden !!!
MfG Tim Stone
Richtig ist: Eine Firewall soll kontrollieren, welcher Verkehr vom Firmennetz nach außen und andersherum fließen soll und durch diese Kontrolle die Sicheheit erhöhen.
Wenn es nun möglich ist, dass ein Benutzer mittels eines Programmes (ssh) das Unternehmensnetzwerk nach außen "verlängert", so kann dies genausogut mit einem anderen Programm mit oder ohne Wissen des Benutzers passieren, man denke an Würmer, Hacker, weißderteufelwas...
Also: Wenn eine Firewall ein Unternehmensnetzwerk vor Tunneln schützen soll, dies aber mit ssh möglich ist, hat die Firewall versagt.
>Die Argumentation ist schlichtweg falsch!
Schau dir den Thread an, was ist bitte falsch an meiner Argumentation. Der einzige welcher hier von einem ssh-Tunnel spricht ist haertie.
Danke fuer die Blumen
Ich habe nie behauptet, das eine Firewall richtig konfiguriert ist, wenn sie von ueberall aus dem Firmannetz es ermoeglicht, einen ssh-tunnel aufzubauen! Bei diesem Thread ging es lediglich darum, welche rechtlichen Konsequenzen entstehen koennten, wenn sich jemand einen Tunnel nach aussen aufbaut, ohne dafuer eine Genehmigung von der Firma zu besitzen.
>Wenn es nun möglich ist, dass ein Benutzer mittels eines Programmes (ssh) das Unternehmensnetzwerk nach außen "verlängert", so kann >dies genausogut mit einem anderen Programm mit oder ohne Wissen des Benutzers passieren, man denke an Würmer, Hacker, >weißderteufelwas...
Richtig! Das geht aber auch mit einer Firewall/Proxy, welcher keine ssh durchlaesst. Es ist "relativ simple" einen Proxyfaehigen" http Tunnel zu schreiben.
Da nutzt die best konfigurierteste Firewall nichts mehr. Das ist ja auch da Problem von Outlook und VB-Scripten.
MfG Tim Stone
> Der einzige welcher hier von einem ssh-Tunnel spricht ist haertie.
Ich dachte, du hättest auf slow geantwortet, welcher da schrieb:
> Damit man z. B. trotz Firewall immer noch mit dem Büro in XYZ über
> einen *Tunnen* kommunizieren kann... nennt sich auch VPN
Ich finde die Argumentation, dass rechtliche Folgen entstehen können, wenn ein Benutzer einen Weg, der sowieso schon vorhanden ist, geht, nach wie vor falsch.
Anders sieht es natürlich aus, wenn explizit vereinbart wurde, dass der Weg verboten ist. Leider argumentieren da viele Firmen anders bzw. es fehlt das technische Verständnis, zu erkennen, das der Weg schon immer da war.
> Richtig! Das geht aber auch mit einer Firewall/Proxy, welcher keine ssh durchlaesst.
> Es ist "relativ simple" einen Proxyfaehigen" http Tunnel zu schreiben.
Das meinte ich unter anderem.
Ein anderes Beispiel wäre folgendes Szenario:
Ein Anwender möchte ab und zu Sachen nicht über die Firmendrucker drucken. Er schickt sie deshalb per mail zu sich nach Hause.
Ist das rechtlich abgesichert? - Sicherlich ja.
Alternativ könnte er einen ssh (ofer http,..)-tunnel verwenden, um die Daten von Firma -> nach Hause zu schaffen. Ich sehe da faktisch keinen Unterschied (sofern wirklich nur die Daten übertragen werden)
Nun könnte man ja sagen, über der tunnel könnte man auch sensible Daten übertragen, weshalb so ein Tunnel rechtliche Folgen haben könnte.
Was ist nun aber der Unterschied, ob die Daten über einen tunnel oder per email übertragen werden? Es gibt offenbar keinen.
Im Fall der unerlaubten Übertragung hat der Mitarbeiter sicherlich rechtliche Konsequenzen zu befürchten (so die Weitergabe sensibler Daten im Arbeitsvertrag untersagt wurde), im anderen Fall meiner Meinung nach nicht.
Fazit: Ein Computer ist nur dann sicher vor der Übertragung sensibler Daten wenn er nicht mit der Welt verbunden ist.
Gruß, Alex
Du brauchst sogar eine Erlaubnis, um deine Diplomarbeit, die du für eine solche Firma machst, auf einem Datenträger mit nach hause zu nehmen. Da sind die von solchen "Tunnel"-Aktion garantiert begeistert. Bevor ich so etwas machen würde, würde ich mir erst einmal eine Erlaubnis vom Chef holen. Fragen kostet schließlich nichts
Andernfalls waere ja eine entsprechende Policy in der Firewall vorhanden, die SSH Verbindungen (zu bestimmten Rechnern und/oder von bestimmten Clients) erlaubt.
Also waere so ein Tunneling ohne ausdrueckliche Erlaubnis des zustaendigen Admins oder Security officers (auf Neudeutsch CSO) schon ein Kuendigungsgrund, da vertrauliche Unternehmensdaten fuer den Zugriff von aussen bereitgestellt werden.
Sicherlich wird dies aber von Unternehmen zu Unternehmen differenziert betrachtet und auch behandelt. Grossunternehmen verstehen in der Regel hier keinen Spass.
Gruss
Torsten
VPNs werden normalerweise von der Firma bereitgestellt, und nicht von Laien durch Doppelklick auf irgendeine Exe inkl. Rumprobieren, bis es funktioniert, installiert.
dann kommt das problem: in einem firmennetz, denke ich mal, man darf als "einfacher" anwender sowieso keine "server"-dienste anbieten. und wenn die admins so dumm sind, und ssh auf den lokalen rechnern installieren, haben sie entweder sehr gute gründe (in dem fall, wird die firewall halt dementsprechend packet technisch konfiguriert, sodass der anwender (oder potentieller cracker) keinen tunnel öffenen kann), oder sie haben keine ahnung.
wenn du den tunnel öffnen kannst, dann weiß keiner, was da durch gegangen ist, und dass ist - denke ich mal - für einen chef nicht gerade beruhigend. also ist das mit der theorie und praxis auch etwas anderes.
theoretisch, ist es kein problem, es ist ein sicherheitsloch, pracktisch ist es dein rauswurf. (untreue der firma gegenüber, mutmaßlicher datenraub, usw.) im endeffeckt ist es dann egal, warum du entlassen wurdest, du bist halt nicht mehr da...
bye
ps.: und lasst euch nicht erwischen
es tut sooo weh.
sorry. es wird nicht wieder vorkommen
- Firma hat Socks-Server oder lässt aussgehende TCP-Verbindungen AUS dem Firmennetz nach DRAUSSEN zu.
- Mitarbeiter connected sich per ssh über Socks "nach Hause" (vielleicht am besten auch noch per cronjob nachts von seiner Linux-"Spielkiste" initiiert)
- Er richtet SSH-Port-Forwarding ein und hat dabei z.B. versehentlich auch noch "Gateway-Ports auf YES stehen.
- Er forwardet Ports wie 21,22,25,80 oder was auch immer, um z.B. von zu Hause Zugriff auf entspr. Applikationen/Dienste IN der Firma zu haben.
- Nunja - da sein Rechner am Internet hängt und regelmaessig die üblichen "Portscans" abbekommt(oder möglicherweise gar "owned" ist) - ratet mal auf welcher Maschine der Buffer-Overflow-Exploit wirkt, wenn der Hacker die Ports 21,22,25 oder 80 auf dem "zu Hause PC" offen vorfindet und sich daran zu schaffen macht???
naaaaa?
Da iss nix mit Firewall oder Stateful Inspection... Die Firewall bekommt nicht weiter mit, dass da "innerhalb" der SSH Session eine TCP-Session getunnelt wird.
(die wohlgemerkt aus der GEGENRICHTUNG aufgebaut wurde!)
Sorry - aber ich kann die Haltung verstehen: wäre ich IT-Verantwortlicher einer Firma, würde ich da eine ganz klare Policy aufstellen. Das fällt in dieselbe Kategorie wie: Illegaler Betrieb eines Modems am Arbeitsplatz und bewusste/unbewusste "Umgehung" der Firewall.....
Da hilft weniger Verbot oder Drohung sondern vielmehr Aufklärung. Wer SSH benutzt und selbständig administrieren kann, sollte auch in der Lage sein, ein Scenario wie dieses zu verstehen und als "dangerous" einzustufen.
CU
dev
GatewayPorts yes
steht.
Oder anders gefragt: Was kann ich mit so einem Tip realisieren?
Danke
Christian
cu.
peter
Das wird durch den obigen Tip dadurch umgangen, daß von "innen" eine ssh-Verbindung nach "außen" geschaffen wird (das ist meist erlaubt), über die man sich dann von einem dritten Rechner auf dem Zielrechner der ssh-Verbindung einloggen kann.
Gruß,
husky
Ich gehe mal davon aus, dass es dann ein Kunedigungsgrund ist, wenn es entweder ausdruecklich untersagt wurde oder eigentlich von der Konzeption der Sicherheitspolitik her klar ist, dass soetwas nicht gestattet ist.
Wenn Du/Ihr selber der Admin seid, waere das auf jeden Fall ein Punkt, den man beim Aufbau einer Sicherheitspolitik beachten sollte.
ciao Pierre
(so heisst die Option auch ;))
Gibt es da echt keine Comandozeilenoption?
allen postern, die sich darueber sorgen machen, kann ich nur computer-aus empfehlen...
wenn ich lust habe, schreibe ich mal n script, um als pill hates email ueber offene relaying mailhosts an irgendwen zu schicken und sende das hierhin zum veroeffentlichen. schaetze, das geschrei ist da noch groesser...
nur vergessen die leute, dass wir in einem freien staat leben, in der informationen, solange sie nicht verboten sind, frei verteilt werden duerfen.
ob die anwendung erlaubt/toleriert/oder_was_auch_immer gewertet wird, obliegt der verantwortung des taetigen und das ist gut so.
wo kaemen wir denn hin, wenn alle nur windoze nutzten???
ratte
und jetzt erklaer mir einer mal den grundlegenden unterschied?
ratte
Wenn wir schon mal beim Tunneln sind, habe ich mal eine Frage an die anwesenden Experten.
PC B:
-Webserver 80
-Eigener Server 1080
Wenn ich (PC A) jedoch hinter einem (Firmen)Firewall bin und mit einem Applet vom Webbrowser aus auf den Server im Internet zugreifen will, geht das nur über einen HTTP - Tunnel.
Wie muss ich jetzt den Server(PC B) einrichten, dass der Webserver und mein eigener Server auf Port 80 erreichbar sind?
Danke
user1
Es zeigt mal wieder den Leuten, dass eine Firewall nicht ein einzelner Rechner ist, sondern eigentlich ein ganzes Konzept. *g*
UNd für unsere Admins ein Tipp:
- Transfernetz (DMZ) schaffen.
- dort entsprechende Proxies einstellen
- nur connections von intern -> transfer erlauben
bzw.
direkten ssh nach aussen nur von bestimmten IPs zu bestimmten Ips erlauben
und die Sache mit den Tunneln hat sich erledigt :)
BYe
Johannes
Bei einer fernuenftig administrierten Sateful-Firewall ist aber eine Verbindung ueber High-Ports nicht moeglich, wiel diese in der Regel gesperrt sind.
Damit ist die Diskussion der Rechtlichen Aspekte natuerlich akademisch. Grundsaetzlich bin ich hier aber der Meinung, dass die Gefahr einer Entlasung oder Abmahnung vom Arbeitsvertrag und von Betriebsvereinbarungen abhängt.
cu
Tom
Absprache mit den Verantwortlichen der Firma IST ein Kündigungsgrund. Punkt.
Die Firma hat schon durch die bloße Präsenz einer Firewall - Installation
Ihre Sicherheitseinstellung zum Ausdruck gebracht. Für eine fehlerhafte
Installation ist nicht die Firmenleitung sondern eher der zuständige
Administrator/Dienstleister haftbar. Das befreit euch als Angestellte/Arbeitnehmer
aber noch lange nicht von der Sorgfaltspflicht.
Natürlich sollte eine entsprechende Richtlinie zur Benutzung von (internen) Server und Arbeitsstationen
existieren nur im Arbeitsvertrag haben solche Regelungen weiss Gott nichts zu suchen ( sonst steht
da demnächst auch noch drin, dass ich mich aufm Klo hinzusetzen habe ).
Auch hier gilt, die Firma muss deutlich zum Ausdruck bringen daß bestimmte Verbindungen/Konfigurationen usw. nicht erwünscht sind ... und eine Firewall ist Ausdruck genug.
M. Tschursch
Consultan IT-Sicherheit
Teleport Sachsen-Anhalt GmbH
tschursch@tsa.de
P.S.:
Warum schreit hier immer jeder nach Vorschriften und Regelungen ?
Reicht denn nicht genug gesunder Menschenverstand aus um Zusammenleben zu können,
neeeiiin ... am besten ihr bekommt noch gesagt (nat. schriftlich und notariel beglaubigt),
wie man wo und wie lange Luft holen darf....
Nein, nicht ganz.
1. Was hat das mit stateful inspection zu tun ?
2. Wir der HighPort am äusseren Rechner aufgemacht ... das sieht die FW schon gar nimmer
Wie willst du ssh-session's nach draußen verbieten,
FALLS die Firma draussen Rechner zu administrieren hat ?
Erstmal lesen, dann schreiben ...
Natuerlich ist der Artikel Hinweis gut und gemacht hab ich das auch schon oft genug, allerdings wie auch oben beschrieben entweder mit Erlaubniss oder bei NAT-Installationen ( d.h. nix Firewall ) .
Ich wollte nur mit euren Irrglauben aufräumen, der nach dem 1. Kommentar aufkam, denn der Mensch hat wirklich recht ... so sehr das eurer und meiner Robin Hood - Seele auf den Kranz geht.
Bei einem einfachen Paketfilter sind die Highports in der Regel per Default offen, weil ein Paketfilter nicht weiss auf welchem Highport der Server die Clientanfrage beantwortet.
Aber damit erzähle ich wohl nichts neues.
> 2. Wir der HighPort am äusseren Rechner aufgemacht ... das sieht die FW schon gar nimmer
OK, vielleich habe ich hier ein Verständnisproblem (aussen, innen, vor der FW, hinter der FW, Rechner A, Rechner B). Ist der Highport wirklich offen? D.h. zum Beispiel per Portscan aus dem selben IP-Segment sichbar? Oder "lebt" er nur innerhalb der Session über Port 22?
Wenn ja, dann hat das wirklich nichts mit Stateful Inspection zu tun.
Das kann man genauso mit einem einfachen Packetfilter verbieten ( Das == Highports ). Ob das nun sinnvoll ist oder nicht ist 'ne andere Frage
und btw.:
- wer heute "Firewalls" ohne Stateful Inspection einsetzt
- wer heutzutage nicht nach der Regel "Es alles verboten, ausser es ist erlaubt" Firewalls und Firmennetzwerke aufbaut
der gehört eh (virtuell) erschossen. :D
Somit erübrigt sich auch die Feststellung das highports per default offen sind ... das sind sie nämlich nur, wenn ein Verbindungsaufbau von INNEN erfolgt. Alle Versuche von AUSSEN Verbindungen aufzubauen ( egal ob highports oder nicht ) sollten von einer __echten__ Firewall geblockt werden.
>- wer heute "Firewalls" ohne Stateful Inspection einsetzt
>- wer heutzutage nicht nach der Regel "Es alles verboten, ausser es ist erlaubt" Firewalls >und Firmennetzwerke aufbaut der gehört eh (virtuell) erschossen. :D
Da stimme absolut zu.
Ich meinte uebrigens _nicht_, dass man Firewalls mit oder ohne Stateful Inspection daran unterscheiden kann , ob highports offen sind oder nicht.
Aber zurueck zur IP-Theorie:
)diesen Port nicht kenne, muss ich doch wohl moeglichst alle Highports offen lassen, oder? Eine Ausname wuerden hier natuerlich Ports von Diensten bilden, die bekanntermassen Highports belegen, wie z.B. Webmin
Wenn ich einen einfachen Paketfilter als "Firewall" einsetze, dann weiss dieses Teil nichts von Sessions. Das bedeutet, die Antwort des Servers auf eine Clientanfrage, zb. auf Port 80, erfolgt auf einen beliebigen Highport. Da ich (und der Paketfilter
Eine Stateful Firwall erkennt dagegen doch zu welcher Anfrage (des Client) die Antwort des Servers gehoert, und laesst diese Antwort zu, obwohl die Highports für _Anfragen_ dicht sind.
Sind wir und da einig?
Tja, und ob der Port 50022 in dem Beispiel von Kristian Peters wirklich offen ist, oder im "Tunnel" liegt weiss ich jetzt immer noch nicht so richtig
+------------+ +-------+ 50022 auf--+-------------+ +------------+
| interner | SSH - | FW - | SSH- 127.0.0.1 | äusserer | | Home |
| +============+ +====================+ +-- 22 ( sshd ) ----+ |
| Rechner(A) | Tunnel | Box | Tunnel | Rechner(B) | | Rechner(C)|
+------------+ +-------+ +-------------+ +------------+
Dieses Setup bedeutet, dass man mindestens einen Account auf "äusserer Rechner" haben
muss um die Weiterleitung nutzen zu können.
Der Port 50022 ist auf "äusserer Rechner" offen und die Verbindung wird über den vom
ersten Kommando
>> ssh -g -R 50022:localhost:22 login@B <<
aufgebauten Tunnel durch die FW geschleust.
Die FW "sieht" nur die ssh-Session von "A" auf "B" und die Natur einer veschlüsselten SSH-Session
erlaubt der FW auch keine weitere Analyse der Verbindung.
Dies ist btw. grad in größeren Firmen der Hauptgrund für sog. gepiercte Firewalls...
schlimmer sähe das Ganze noch aus, wenn man das Forwarding nicht auf "localhost" sondern auf das
eth0 Interface ( also IP) des Rechners (B) legt. Dann braucht man nämlich nichtmal mehr einen Account für B um auf A zu kommen ( ist natürlich auch "bequemer" ).
Bei beiden Setups kann die FW nichts machen.
Wegen solcher Setups empfiehlt sich IMMER die Einrichtung einer DMZ einer Rules im Firewall, die Traffic
von innen nach aussen WENN dann nur ueber eine DMZ "Verbindungsstelle" ( Applicationproxy , Server in DMZ ) erlauben.
Was nicht heisst, dass SSH Tunneling dann nicht mehr geht. Nein, es kann nur nicht mehr JEDER in der Firma machen, die einen acc auf den internen Server haben ....
Könnte der Webmaster evtl. um meine ASCII - Grafik ein setzen ?
ich meinte ein <pre> <----
"<pre>" ist wohl leider nicht erlaubt.
ich setze seit einiger Zeit erfolgreich Putty ein um eine RDP-Session zu tunneln, um auf meinen XP Rechner zu Hause zuzugreifen.
Da ich so ja einen offenen Port (OpenSSH Server auf Windows XP) habe wollte ich das ganze noch sicherer machen und einen meiner Linux Server im Netz dazu missbrauchen um RDP zu tunneln. Der Vorteil: Ich könnte die IP zum vertrauten Netzwerk auf dem WinXP Client hinzufügen und man könnte SSH/RDP Sessions von aussen nur von der IP des Linux-Server aufbauen.
Diese Anleitung habe ich bisher benutzt, um die RDP-Sessions zu tunneln:
http://
theillustratednetwork.mvps.org/RemoteDesktop/
SSH-RDP-VNC/RemoteDesktopVNCandSSH.html
Meine Frage jetzt: Wie tunnel ich auf meinem Linux-Server und übernehme praktisch die Aufgabe von Putty? (auch SSH-Protokoll 2 mit Kompression)
MfG
JohnBoy
Du überliest eine Anleitung die eigentlich für Linux ist ???