Vraag Waarom Block Port 22 Outbound?


Ik ben een programmeur en ik heb voor een paar klanten gewerkt waarvan de netwerken uitgaande verbindingen op poort 22 blokkeren. Aangezien programmeurs vaak poort 22 voor ssh moeten gebruiken, lijkt dit een contraproductieve procedure. In het beste geval dwingt het de programmeurs om het bedrijf te factureren voor 3G-internet. In het slechtste geval betekent dit dat ze hun werk niet effectief kunnen doen.

Gezien de moeilijkheden die dit met zich meebrengt, zou een ervaren systeembeheerder dan het gewenste voordeel kunnen uitleggen voor wat lijkt op een verliessituatie?


55
2018-06-14 17:08


oorsprong


Het blokkeren van poorten is slechts de helft van de strijd. Om de cyclus te voltooien, moet u ervoor zorgen dat de services die u probeert te beschermen niet op niet-standaard poorten worden uitgevoerd. - aharden
De vraag zou eigenlijk moeten zijn: "Waarom poort 22 outbound blokkeren?" omdat er een miljoen goede redenen zijn waarom je je ssh-service op een niet-standaardpoort wilt uitvoeren. Uitgaand ... niet zo veel. Ik plaatste een +1 op het antwoord van Robert Moir, omdat hij het behoorlijk goed uitlegde. - KPWINC
@KPWINC, heeft de verduidelijking toegevoegd aan de titel. Bedankt! - runako
Denk aan poort 22 als een soort doos van een pandora. Netwerkbeheerders kunnen niet zien wat er in het verkeer en het ergste is, maar SSH kan worden gebruikt om netwerkbeveiliging te omzeilen, wat de integriteit van het netwerk aantast. - biosFF
@biosFF: Poort 443. - Hello71


antwoorden:


Ik zie niet dat iemand het specifieke risico met SSH-port forwarding in detail heeft beschreven.

Als u zich binnen een firewall bevindt en uitgaande SSH-toegang hebt tot een machine op het openbare internet, kunt u SSH gebruiken voor dat openbare systeem en in het proces een tunnel maken zodat mensen op het openbare internet naar een systeem in uw netwerk kunnen sshoppen, volledig de firewall omzeilen.

Als fred uw bureaublad is en barney een belangrijke server is binnen uw bedrijf en wilma openbaar is, draait (op fred):

ssh -R *: 9000: barney: 22 wilma

en als je inlogt, kan een aanvaller SSH naar poort 9000 sturen op wilma en met de SSH-daemon van barney praten.

Uw firewall ziet het nooit als een inkomende verbinding omdat de gegevens worden doorgegeven via een verbinding die oorspronkelijk in de uitgaande richting was ingesteld.

Het is vervelend, maar een volledig legitiem netwerkbeveiligingsbeleid.


68
2018-06-14 19:50



Bedankt voor een zeer inzichtelijke reactie. Dit is een van de weinige antwoorden die de technische risico's (in tegenstelling tot de politieke risico's) van open uitgaande havens aanpakken. - runako
+1 voor het geven van een goede technische reden. (Dit kon echter alleen worden gedaan door een kwaadwillende stagiair, die ook andere poorten kon gebruiken dan TCP 22 op de externe host waarmee we teruggaan naar een blok alle beleid) - DerMike
Met een op maat gemaakt protocol en een aantal slimme proxy-programmering, zou dit kunnen worden gedaan via HTTPS - zij het trager. Zolang u uitgaand gecodeerd verkeer toestaat, bent u kwetsbaar voor dit soort "aanval". - Michael Sondergaard
Dit is een goede reactie op JamesF, maar geen beveiligingsprobleem dat de moeite van het overwegen waard is, omdat het een uiterst zeldzaam scenario veronderstelt en de exploitatie van SSH-servers / -clients vereist. De kwaadwillende gebruiker moet eerst de SSH-server (op uw bureaublad) misbruiken en een manier bedenken om uw SSH-client (op uw bedrijfshost) te exploiteren. Aangezien u poort 22 niet kunt gebruiken om toegang te krijgen tot of te praten met de bedrijfs-firewall host (die alleen uitgaande poort 22 heeft). Als uw beveiligingsstandaard zo hoog is, zou uw bedrijfshost in geen enkele situatie op het internet moeten zijn. - Dexter
Verdergaand op wat @Dexter te zeggen had, kan het firewallbeleid ook worden geïmplementeerd op de intranet-scope. Dus de interne servers zijn zelfs beveiligd vanaf desktops op het intranet. - nass


Als ze een mengelmoes van poorten blokkeren, wat spullen doorlaten en willekeurig wat andere dingen blokkeren (ik hou van het droevige verhaal van Paul Tomblin over de mensen die SSH blokkeren en Telnet toestaan) dan hebben ze ofwel een heel vreemde scherpte voor hoe ze gaan over het beveiligen van hun netwerkperimeter, of hun beveiligingsbeleid is, van de buitenkant tenminste, blijkbaar slecht doordacht. Je kunt dergelijke situaties niet begrijpen, dus reken gewoon de gangbare tarieven op voor mensen die pijn hebben en doorgaan met je dag.

Als ze ALLE poorten blokkeren tenzij er een specifieke businesscase is om verkeer door die poort toe te staan, op welk moment het zorgvuldig wordt beheerd dan doen ze het omdat ze bekwaam zijn in hun werk.

Wanneer u een beveiligde toepassing probeert te schrijven, maakt u het dan gemakkelijk voor andere processen om informatie te lezen en te schrijven naar wens, of heeft u een paar zorgvuldig gedocumenteerde API's waarvan u verwacht dat mensen ze zullen bellen en die u zorgvuldig wilt opschonen?

Risicobeheer - als u vindt dat het verkeer naar of van uw netwerk op internet gaat, is een risico, dan wilt u het aantal manieren minimaliseren waarop het verkeer het internet kan bereiken, zowel wat betreft het aantal routes als het aantal methoden. U kunt vervolgens de gekozen "gezegende" gateways en poorten controleren en filteren om te zorgen dat het verkeer dat over hen reist, is wat u verwacht.

Dit is een 'default deny'-firewallbeleid en wordt meestal als een goed idee beschouwd, met een paar kanttekeningen die ik zal bespreken. Wat het betekent is dat alles wordt geblokkeerd tenzij er een specifieke reden is om het te deblokkeren en de voordelen van de reden opwegen tegen de risico's.

Bewerken: ik moet verduidelijken, ik heb het niet alleen over de risico's dat één protocol wordt toegestaan ​​en een ander wordt geblokkeerd, ik bedoel de potentiële risico's voor het bedrijf dat informatie ongecontroleerd in of uit het netwerk kan stromen manier.

Nu voor de restricties, en mogelijk een plan om dingen vrij te maken:

Het kan vervelend zijn als je ergens voor wordt geblokkeerd, wat de positie is waar je jezelf bevindt bij sommige van je klanten. Al te vaak denken de mensen die verantwoordelijk zijn voor de firewall dat het hun taak is om "Nee" te zeggen, in plaats van "Hier zijn de risico's, wat zijn de voordelen, laten we eens kijken wat we kunnen doen".

Als u spreekt met diegene die de netwerkbeveiliging voor uw klanten beheert, zijn zij mogelijk bereid iets voor u in te stellen. Als u een paar specifieke systemen aan het einde kunt identificeren, moet u toegang hebben tot en / of garanderen dat u alleen verbinding maakt vanaf een specifiek IP-adres, ze kunnen veel gelukkiger zijn om een ​​firewalluitzondering te maken voor SSH-verbindingen voor die specifieke voorwaarden dan ze zou zijn om gewoon verbindingen te openen met het hele internet. Of misschien hebben ze een VPN-faciliteit die u kunt gebruiken om door de firewall te tunnelen.


36
2018-06-14 17:52



+1 voor Als ze ALLE poorten blokkeren, tenzij er een specifieke businesscase is om verkeer door die poort toe te staan, op welk punt het zorgvuldig wordt beheerd, dan doen ze het omdat ze bekwaam zijn in hun werk. - cop1152
-1 omdat ssh niet kan worden bewaakt door de beveiligingsmensen maar wel door Telnet. Mijn punt is dat hoewel er een dwaas netwerkbeveiligingsbeleid bestaat, het karakteriseren van het beleid als "willekeurig" en "meppen" zonder een goed begrip van de daadwerkelijke bedrijfsbehoeften ook kort is. - pcapademic
Wel, je hebt natuurlijk recht op je mening, Eric, en ik zal die woorden graag veranderen als je denkt dat ze ongunstig zijn, maar ik heb er vrij zeker van dat een dergelijk beleid ofwel slecht doordacht is of een zeer ongebruikelijk voordeel. - Rob Moir
+1 voor "alle poorten" - Ian Boyd


Een bepaald groot bedrijf in Rochester, NY, dat vroeger veel film had gemaakt, blokkeerde uitgaande ssh toen ik daar werkte, maar toegestaan telnet! Toen ik ernaar vroeg, zeiden ze dat ssh een beveiligingslek was.

Met andere woorden, bedrijven nemen soms domme beslissingen en verzinnen flagrante excuses over beveiliging in plaats van hun fouten toe te geven.


17
2018-06-14 17:33



TELNET is het beveiligingslek. Het moet worden verboden (dit is alleen voor mensen om in de toekomst betere domme beslissingen te nemen). - nik
Laat me hier verder uitleggen, wat een beveiligingsgat is, is subjectief voor het oppervlak dat wordt beveiligd. Als u een websiteleigenaar bent die probeert verbinding te maken met uw server, is TELNET een gat. Als u een werknemer van een financieel bedrijf bent die buiten probeert te verbinden met uw basisserver (via regels die door uw werkgever worden gecontroleerd), is SSH het veiligheidslek voor uw werkgevers! - nik
Als je bedenkt hoe gemakkelijk het is om telnet in beide richtingen te vervalsen, zou ik zeggen dat telnet een beveiligingslek is, zelfs voor het bedrijf dat het uitbesteedt. Maar een bedrijf dat het toestaat maar ssh niet toestaat, zal in geen geval intelligente beveiligingsbeslissingen nemen. - Paul Tomblin
Telnet is het geschenk dat maar blijft geven. Het was ok 20 jaar geleden maar nu zou ik echt willen dat het zou stoppen. - Rob Moir
Het hangt allemaal af van je POV. Ze hadden waarschijnlijk mensen die toegang nodig hadden tot een oud proces via Telnet, wiens ons eenvoudig te controleren is. OTOH, je hebt geen idee wat er met SSH aan de hand is, mensen kunnen tunnels vestigen op buitenlandse netwerken en allerlei domme dingen doen. Telnet moet tegenwoordig niet worden gebruikt, maar iedereen die uitgaande SSH toestaat, moet een nieuwe carrière zoeken. - duffbeer703


Ik kan het begrijpen van inkomende SSH-communicatie begrijpen als het bedrijf externe aanmeldingen niet toestaat. Maar dit is de eerste keer dat ik hoor van een uitgaand SSH-blok.

Het is belangrijk op te merken dat zo'n firewall waarschijnlijk alleen de toevallige SSH-gebruiker zal beperken. Als iemand echt van buiten SSH wil (wat meestal een server / machine is waar ze aanzienlijke toegang tot hebben, buiten het bedrijfsnetwerk), kunnen ze de SSH-server eenvoudig uitvoeren op een andere poort dan 22 (zeg, poort 80). Het blok zal gemakkelijk worden omzeild.

Er zijn ook verschillende hulpprogramma's voor het publieke domein waarmee u de onderneming via HTTP (poort 80 of HTTPS-poort 443) kunt afsluiten en proxies kunt leveren waarmee u verbinding kunt maken met poort 22 buiten.


Bewerken: OK, wacht even, ik heb een idee waarom dit een beleid zou kunnen zijn.

Soms gebruiken mensen SSH-tunnels om standaard outbound-firewalls te omzeilen voor protocollen zoals IM en Bittorrent (bijvoorbeeld). Deze // kan // een dergelijk beleid hebben geactiveerd. Ik heb echter nog steeds het gevoel dat de meeste van deze tunneltools zouden kunnen werken op andere poorten dan 22.

De enige manier waarop dergelijke uitgaande tunnels kunnen worden geblokkeerd, is door SSH-communicatie on the fly te detecteren en (dynamisch) deze TCP-verbindingen te blokkeren.


5
2018-06-14 17:32



Poort 443 is beter, omdat er al van wordt aangenomen dat deze is gecodeerd, zodat proxies niet van streek raken over vreemde gegevens. Je kunt eenvoudig een ssh-server instellen die op poort 443 luistert, en vanaf daar kun je overal naartoe gaan. - bandi
Op een plaats waar ik werkte, gebruikte een van mijn collega's een programma dat al het netwerkverkeer via een ssh-tunnel via onze webproxy naar poort 80 op zijn thuiscomputer en vandaar naar internet tunnelde. Hij kon elk protocol gebruiken dat hij wilde, maar het leek erop dat het van zijn huis kwam in plaats van het bedrijf. Gelukkig wist hij hoe dom de netwerkbeheerders waren, dus riskeerde hij niet betrapt te worden. - Paul Tomblin
Natuurlijk, als je betrapt wordt op het doorlopen van een van deze uitgebreide dansen om de firewall te omzeilen, kun je niet echt smeken om onschuld en onwetendheid. Moeilijk om dat allemaal te doen en te zeggen "sorry baas, het werkte gewoon" dus ik wist niet dat ik iets verkeerd deed. " - Rob Moir


Het is waarschijnlijk een kwestie van regelgeving / compliance. Uw werkgever wil alle communicatie kunnen lezen / archiveren. Dit is heel vaak een vereiste in bedrijfstakken zoals het bankwezen.


4
2018-06-14 17:11



Betekent dit niet dat ze ook HTTPS moeten blokkeren? - runako
Nee, ze maken SSL-inspectie mogelijk. Met dit proces wordt HTTPS gedecodeerd en vervolgens worden inkomende en uitgaande pakketten opnieuw gecodeerd door een vertrouwd certificaat in alle werkstations te injecteren volgens groepsbeleid. Op deze manier kunnen ze hetzelfde filteren / scannen als met HTTP. Het bankwezen is een van de meest draconische omgevingen voor het afsluiten van netwerken. - spoulson


Er zijn twee primaire redenen om uitgaande poort 22 te blokkeren, naar mijn mening.

Ten eerste, zoals mensen al hebben gezegd, kan doorsturen van SSH-poorten worden gebruikt als een proxy of omzeilen rond andere poorten en services om te voorkomen dat IT-beleid bepaalt dat dergelijk verkeer is toegestaan.

Ten tweede zullen veel malware / botnets poort 22 gebruiken omdat het vaak als "veilig" wordt gezien en daarom wordt toegestaan. Ze kunnen vervolgens die poort opstarten en geïnfecteerde computers kunnen ook SSH-brute force-aanvallen starten.


4
2018-06-15 03:38





Vaker wel dan niet is het meer het geval van het blokkeren van alle uitgaande verbindingen tenzij nodig, en totdat je probeerde, had niemand poort 22 gevraagd om beschikbaar te zijn voor uitgaande verbindingen (alleen 80, 433, enzovoort). Als dit het geval is, is de oplossing misschien net zo eenvoudig als contact opnemen met IS / IT en hen vertellen waarom u een uitzondering moet toevoegen, zodat uw station uitgaande SSH-verbindingen met specifieke hosts of in het algemeen kan maken.

Soms is het de zorg dat mensen de mogelijkheid zouden gebruiken om SSH te gebruiken als een manier om proxy's in te stellen (via port forwarding via de link) om andere besturingselementen te omzeilen. Dit kan een zeer belangrijke factor zijn in sommige gereguleerde industrieën (dwz banken) waar alle communicatie moet worden gemonitord / geregistreerd om juridische redenen (het ontmoedigen van handel met voorkennis, het detecteren / blokkeren van overdracht van bedrijfs- of persoonlijke gegevens, enzovoort) of bedrijven waar is een grote angst voor interne lekken en geeft bedrijfsgeheimen, per ongeluk of anderszins, weg. In deze gevallen kan het gebruik van uw 3G-link (of andere technieken zoals het proberen om SSH via HTTP te tunnelen) om de beperkingen te omzeilen een schending van uw contract zijn en daarom een ​​plundering (of waarschijnlijk nog erger, een juridisch misdrijf), dus wees voorzichtig zorg dat je actie overeenkomt voordat je het probeert.

Een andere reden zou kunnen zijn om de uitgaande footprint (tot interne services toegankelijk voor hosts binnen de firewalls van het bedrijf en voor de wereld in het algemeen) te verminderen als iets ongewenst zichzelf zou kunnen laten installeren op een door het bedrijf draaiende machine. Als er geen SSH-verbindingen mogelijk zijn op poort 22, zullen veel eenvoudigere hacks die brute force SSH-aanmeldingen proberen gebruiken als een van hun propagatieroutes worden geblokkeerd. In dit geval kunt u opnieuw gewoon om een ​​uitzondering vragen om toe te voegen, zodat uw machine SSH-verbindingen kan maken, als deze verbindingen kunnen worden verantwoord aan de mensen die de firewall (s) onder controle hebben.


3
2018-06-14 17:33



Ja, het is vrij waarschijnlijk dat alle uitgaande services die nog niet hoeven te worden gebruikt, mogelijk zijn geblokkeerd (standaard). - nik
Maar het blokkeren van tcp / 22 zal veilige uitgaande communicatie (die op elke poort kan worden gemaakt) niet voorkomen zolang de gebruiker een luisteraar buiten heeft, wat tegenwoordig niet moeilijk is). - nik
Als het interne netwerk gebruikmaakt voor SSH-communicatie, zal het blokkeren niet werken en als er geen SSH-communicatie vereist is, zijn er doorgaans ook geen kwetsbare SSH-luisterapparaten in het netwerk. En typische wormvoortplanting probeert SSH niet bruut te maken (als je je zorgen maakt over die blik en.wikipedia.org/wiki/SSHBlock) zal het waarschijnlijker zijn om tcp / 445 met uw venstersmachines te proberen. - nik