Vraag Verandert het veranderen van het standaard poortnummer de veiligheid eigenlijk?


Ik heb advies gezien dat je verschillende poortnummers moet gebruiken voor privétoepassingen (bijvoorbeeld intranet, privédatabase, alles wat geen enkele buitenstaander zal gebruiken).

Ik ben er niet helemaal van overtuigd dat dit de veiligheid kan verbeteren, omdat

  1. Portscanners bestaan
  2. Als een toepassing kwetsbaar is, blijft dit ongeacht het poortnummer.

Heb ik iets gemist of heb ik mijn eigen vraag beantwoord?


64
2017-09-28 19:04


oorsprong


Een ding dat ik heb gedaan is het gebruik van bepaalde standaardpoorten (bijv. SSH-poort 22) als honingpotten. Iedereen die probeert verbinding te maken met die poorten, is volledig geblokkeerd xtijdshoeveelheid. Het heeft bewezen effectief te zijn tegen poortscannen. Dit is natuurlijk slechts één tool in de toolbox voor beveiliging. - Belmin Fernandez
De algemene vraag over veiligheid door obscuriteit wordt hier gesteld: security.stackexchange.com/questions/2430/... - Tony Meyer
het is misschien een obstakel voor "scripting kids" - Lukasz Madon
@BelminFernandez, "één tool in de veiligheidstoolbox"? Nee, dit is om de serverbelasting (prestaties) te verminderen en heeft niets met veiligheid te maken behalve de illusie ervan. Wat de beveiliging betreft, is het totaal onnodig als de server al sterk is en als de server kwetsbaar is, maakt deze het niet veiliger. - Pacerier
@Pacerier, was het erover eens dat de inspanningen en focus moeten liggen op het implementeren van meer solide beveiligingsmethoden. Er is echter geen reden waarom u beide niet kunt doen. - Belmin Fernandez


antwoorden:


Het biedt geen serieuze verdediging tegen een gerichte aanval. Als je server wordt gericht, zoals je zegt, zullen ze je scannen en ontdekken waar je deuren zijn.

Het verplaatsen van SSH uit de standaardpoort van 22 zal echter een aantal van de niet-gerichte en amateur-script-kiddie-achtige aanvallen ontmoedigen. Dit zijn relatief onervaren gebruikers die scripts gebruiken om te scannen op grote blokken IP-adressen per keer, specifiek om te zien of poort 22 open is en wanneer ze er een vinden, zullen ze er een aanval op beginnen (brute force, woordenboekaanval, enz). Als uw machine zich in dat blok met IP's bevindt die wordt gescand en SSH niet op poort 22 wordt uitgevoerd, reageert het niet en verschijnt daarom niet in de lijst met machines waarop dit script Kiddie kan aanvallen. Ergo, er is enige beveiliging op laag niveau geboden, maar alleen voor dit soort opportunistische aanvallen.

Bijvoorbeeld, als u de time-log-duik op uw server hebt (aangenomen dat SSH op poort 22 staat) en alle unieke mislukte SSH-pogingen die u kunt uitvoeren eruit haalt. Verplaats vervolgens SSH van die poort, wacht even en ga opnieuw duiken. Je zult ongetwijfeld minder aanvallen vinden.

Ik gebruikte Fail2Ban op een openbare webserver en het was echt, heel duidelijk toen ik SSH van poort 22 verplaatste. Het sneed de opportunistische aanvallen met orden van grootte.


66
2017-09-28 19:19



Akkoord. Ik zag een zeer vergelijkbare druppel bij het experimenteren met bewegende SSH naar een niet-standaard poort. Gelukkig is met wachtwoord uitgeschakeld, het is echt een non-issue. - EEAA
Beste antwoord hier tot nu toe. Het komt allemaal neer op wie aanvalt. Ik heb ooit geholpen een systeem te beheren dat werd geraakt door een zero-day-aanval van een scankiddie. Vermoedelijk in MS-RDP omdat we geen IIS hebben laten zien door de firewall. Onze host stond ons niet toe om de RDP-poort (managed hosting) te veranderen, dus we moesten daar eigenlijk blijven zitten terwijl ze aan een nieuw patroon werkten voor hun IDS / IPS-filtering. Hoewel het misschien niet zo veel helpt voor meer gevestigde servers zoals SSH die minder beveiligingsproblemen lijken te hebben dan sommige MS-producten. - Matt Molnar
Zeker mee eens. Bij beveiliging gaat het om lagen, en hoe meer je hebt, hoe veiliger je bent. Dit kan een zwakke laag zijn, maar toch een laag. Zolang het niet alleen wordt gebruikt, kan het alleen maar bijdragen aan de beveiliging. - Paul Kroon
Een ander punt om SSH uit poort 22 te verwijderen is dat een groot aantal SSH-pogingen plus services, omdat Fail2Ban soms kostbare CPU-tijd in beslag kan nemen. Het kan verwaarloosbaar zijn bovenop de lijn hardware, maar sommige oudere servers kunnen CPU spikes ervaren. De CPU-tijd, het geheugen en de bandbreedte kunt u gebruiken voor andere dingen. - artifex
Ik heb hetzelfde gedaan met RDP op Server 2003 - het verminderde het aantal mislukte authenticatie-items in Logboeken aanzienlijk. - Moshe


Het is erg handig om de logs schoon te houden.

Als u mislukte pogingen ziet met sshd op poort 33201, kunt u er zeker van zijn dat de persoon target u en je hebt de mogelijkheid om de juiste actie te ondernemen als je dat wilt. Zoals contact opnemen met de autoriteiten, onderzoeken wie deze persoon is (door te verwijzen naar de IP's van je geregistreerde gebruikers of wat dan ook), etc.

Als u de standaardpoort gebruikt, is het onmogelijk om te weten of iemand u aanvalt of zijn het gewoon willekeurige idioten die willekeurige scans uitvoeren.


42
2017-09-28 22:58



prachtig onderscheid - ZJR
+1 Dit is het beste argument voor het wijzigen van poortnummers die ik ooit heb gehoord en tot nu toe het enige dat me zou verleiden om dit te doen - squillman
+1 Dit is een goed punt. Gerichte bedreigingen zijn veel gevaarlijker dan willekeurige sondes (de scriptkiddies gaan gewoon door naar gemakkelijkere doelen als u fatsoenlijke beveiliging hebt). De gerichte aanvaller weet mogelijk veel meer over specifieke kwetsbaarheden of zelfs wachtwoordpatronen. Het is goed om deze aanvallen buiten de stroom spam op poort 22 te kunnen herkennen. - Steven T. Snyder
Dit is fout. Ik heb gezien dat minstens één server in gevaar kwam door een scan op een niet-standaard SSH-poort. Er is geen inherente reden waarom een ​​aanvaller ook geen andere poorten zou kunnen scannen. - Sven Slootweg
@SvenSlootweg, True, zeker nu computers sneller en goedkoper worden, is een scan die 65535 keer langer duurt niet langer veel langer meer. - Pacerier


Nee, dat doet het niet. Niet echt. De term hiervoor is Beveiliging door Obscurity en het is geen betrouwbare praktijk. Je hebt gelijk in beide punten.

Beveiliging op zijn best zal de toevallige pogingen die alleen maar rondgaan op zoek naar standaardpoorten afwenden, wetende dat ze op een gegeven moment ze zullen vinden iemand die de voordeur open liet. Echter, als er ooit een serieuze dreiging is dat je geconfronteerd wordt met het veranderen van de deault poort zal dit de initiële aanval op zijn hoogst vertragen, maar slechts zo marginaal vanwege wat je al hebt aangegeven.

Doe jezelf een plezier en laat je poorten correct geconfigureerd, maar neem de juiste voorzorgsmaatregelen om ze te vergrendelen met een goede firewall, autorisaties, ACL's, enz.


28
2017-09-28 19:10



De projectie van (sterke) wachtwoorden en encryptie in het idee van veiligheid door obscuriteit is een beetje een streling, naar mijn eigen bescheiden mening ... - squillman
Met behulp van slechts 8 karakters met het volledige alfabetische en numerieke bereik (en zelfs geen speciale karakters toe te staan) is het aantal mogelijke combinaties 62 ^ 8 (218,340,105,584,896). 65535 bevindt zich niet eens in hetzelfde universum als dat, zelfs wanneer poortdetectoren worden gebruikt. Let op, ik deel zwakke wachtwoorden. - squillman
Nog een keer, "het is niet zo dat de niet-standaardpoort het volledige beveiligingsapparaat is". Elk kleine beetje helpt. Het is een aanpassing van 10 seconden die, als er niets anders is, zal voorkomen dat je server wordt weergegeven aan iemand die op zoek is naar SSH om aan de deur te kloppen. - ceejayoz
Meh. Het bijhouden van niet-standaard poorten is het niet waard in mijn boek. Ik ga akkoord met het niet eens te zijn met iemand ... Het toevoegen van verdere tegenmaatregelen behalve het veranderen van de poort is zeker een deel van de vergelijking en ik laat de dingen liever over aan die stukjes van de puzzel. - squillman
Van wat ik heb gezien, zijn de niet-standaard poorten vrij standaard geworden. 2222 voor ssh, 1080, 8080, 81, 82, 8088 voor HTTP. Anders wordt het te obscuur en vraag je je af wat voor service er is op poort 7201 en waarom je geen verbinding kunt maken met ssh op 7102. - BillThor


Het is een klein beetje duister, maar geen noemenswaardige snelheid op de weg naar hacking. Het is een moeilijkere configuratie om langdurig te ondersteunen, omdat alles wat met die bepaalde service te maken heeft, verteld moet worden over de verschillende poorten.

Er was eens een goed idee om netwerkwormen te vermijden, omdat die de neiging hadden om slechts één poort te scannen. De tijd van de snel vermenigvuldigende worm is nu echter voorbij.


13
2017-09-28 19:10



+1 voor moeilijk configuratie- en ondersteuningsprobleem. Je verspilt tijd die kan worden besteed aan het beveiligen van de deur (in plaats van dat je moet zoeken naar waar in je huis je het hebt gestopt). - Macke


Zoals anderen hebben opgemerkt, biedt het wijzigen van het poortnummer niet veel beveiliging.

Ik wil hieraan toevoegen dat het wijzigen van het poortnummer mogelijk schadelijk is voor uw veiligheid.

Stel je het volgende vereenvoudigde scenario voor. Een kraker scant 100 gastheren. Negenennegentig van deze hosts hebben services beschikbaar op deze standaard poorten:

Port    Service
22      SSH
80      HTTP
443     HTTPS

Maar dan is er één host die zich onderscheidt van de massa, omdat zij de systeemeigenaar hebben geprobeerd hun diensten te verbergen.

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

Dit is misschien interessant voor een cracker, omdat de scan twee dingen suggereert:

  1. De eigenaar van de host probeert de poortnummers op hun systeem te verbergen. Misschien denkt de eigenaar dat er iets waardevols is aan het systeem. Dit is misschien geen doorsnee systeem.
  2. Ze kozen de verkeerde methode om hun systeem te beveiligen. De beheerder heeft een fout gemaakt door te geloven in port obfuscation, wat aangeeft dat deze een onervaren beheerder kan zijn. Misschien hebben ze port-obfuscation gebruikt in plaats van een goede firewall, of een goede IDS. Ze hebben mogelijk ook andere beveiligingsfouten gemaakt en zijn mogelijk kwetsbaar voor extra beveiligingsaanvallen. Laten we nu een beetje verder onderzoeken, zullen we?

Als je een cracker was, zou je ervoor kiezen om naar een van de 99 hosts te kijken die standaarddiensten uitvoeren op standaardpoorten, of deze ene host die poort-obfuscatie gebruikt?


12
2017-09-28 19:45



Ik zou naar de 99 gastheren kijken, tenzij de ervaring me dat anders had geleerd. Iemand die poorten verplaatst, heeft waarschijnlijk meer kans om te patchen en te beveiligen, als je het mij vraagt. - ceejayoz
Ik zou naar de 1 gastheer kijken die eruit sprong, in de mogelijke kans dat een of andere PFY dacht: "Als ik de poortnummers wijzig, BEN IK ONONTVANGBAAR!" maar heeft het root-wachtwoord ingesteld op "wachtwoord". - Andrew
@Ceejayoz, helemaal mee eens. Ik voer SSH uit op 2222, geen beveiligingswaarde maar verlaagt me veel op scriptkiddies. Ik denk dat ze ook meer geneigd zijn om mij te negeren, de moeite nemen om de poort te veranderen, waarschijnlijk ook andere maatregelen hebben genomen. Het is duidelijk dat niet alle standaardconfiguratie ... - Chris S
Ik begrijp dat niet iedereen het eens is met mijn mening. Maar in mijn ervaring waren er veel systeemeigenaren die poort-obfuscatie zouden gebruiken, maar ze zouden fouten maken zoals het niet updaten van OpenSSH nadat een aantal kritieke beveiligingskwetsbaarheden waren blootgelegd, of zou niet-versleutelde SSH-sleutels gebruiken van een gedeeld universitair systeem, enz. deze systemen waren sappige doelen. - Stefan Lasiewski
Bij uitbreiding: naar een niet-standaardpoort gaan, heb je meer kans om de scriptkiddies te ontmoedigen, maar ook vaker om een ​​ervaren hacker te intrigeren. Wat de vraag oproept: waar ben je meer bang voor om aangevallen te worden? - tardate


Ik ga ten minste gedeeltelijk tegen de algemene trend in.

Op zichzelfals u naar een andere poort overschakelt, krijgt u misschien een paar seconden de tijd om ernaar te zoeken en krijgt u dus niets in reële termen. Als u echter het gebruik van niet-standaard poorten combineert met anti-portscan-metingen, kan dit een zeer waardevolle verbetering van de beveiliging opleveren.

Dit is de situatie zoals die van toepassing is op mijn systemen: Niet-openbare services worden uitgevoerd op niet-standaard poorten. Elke verbindingspoging naar meer dan twee poorten vanaf een enkel bronadres, ongeacht of deze succesvol is of niet, binnen een opgegeven hoeveelheid tijd resulteert in het wegvallen van al het verkeer van die bron.

Om dit systeem te verslaan zou geluk nodig zijn (het raken van de juiste poort voordat het geblokkeerd raakt) of een gedistribueerde scan, die andere maatregelen triggert, of een zeer lange tijd, die ook opgemerkt en opgevolgd zou worden.


9
2017-09-29 01:11



Combineer dit met het punt door Andreas Bonini over gerichte aanvallen en het is een sterk argument voor het gebruik van alternatieve poorten. - JivanAmara


Naar mijn mening verhoogt het verplaatsen van de poort waarop een toepassing draait de beveiliging helemaal niet - alleen omdat dezelfde applicatie draait (met dezelfde sterke en zwakke punten) alleen op een andere poort. Als uw toepassing zwak is, wordt de zwakte niet verholpen door de poort waarnaar wordt geluisterd naar een andere poort te verplaatsen. Erger nog, het moedigt je actief aan om de zwakte NIET aan te pakken, want nu wordt het niet voortdurend gehamerd door geautomatiseerd scannen. Het verbergt de echt probleem dat is het probleem dat eigenlijk moet worden opgelost.

Een paar voorbeelden:

  • "Het ruimt de logs op" - Dan heb je een probleem met de manier waarop je met je logs omgaat.
  • "Het vermindert de overhead van de verbinding" - De overhead is niet significant (zoals de meeste scans) of u hebt een soort filtering / Denial-of-Service-beperking nodig stroomopwaarts gedaan
  • "Het vermindert de blootstelling van de toepassing" - Als uw toepassing niet bestand is tegen geautomatiseerd scannen en misbruiken, dan heeft uw toepassing ernstige beveiligingstekorten die moeten worden verholpen (d.w.z. houd hem bij de hand!).

Het echte probleem is administratief: mensen verwachten dat SSH op 22 staat, MSSQL op 1433 enzovoort. Het verplaatsen van deze is een extra laag van complexiteit en vereiste documentatie. Het is heel vervelend om op een netwerk te zitten en nmap te gebruiken om erachter te komen waar dingen naartoe zijn verplaatst. De toevoegingen aan de beveiliging zijn op zijn best efemeer en de nadelen zijn niet onbelangrijk. Doe het niet. Los het echte probleem op.


5
2017-09-29 16:56





U hebt gelijk dat het niet veel beveiliging biedt (aangezien het poortbereik van de TCP-server slechts 16 bits entropie heeft), maar u kunt dit om twee andere redenen doen:

  • zoals anderen al hebben gezegd: indringers die veel aanmeldingen gebruiken, kunnen uw logbestanden onoverzichtelijk maken (zelfs als woordenboekaanvallen van één IP kunnen worden geblokkeerd met fail2ban);
  • SSH-behoeften openbare sleutel cryptografie om geheime sleutels uit te wisselen om een ​​beveiligde tunnel te maken (dit is een kostbare operatie die je onder normale omstandigheden niet vaak hoeft te doen); herhaalde SSH-verbindingen kunnen CPU-kracht verspillen.

Opmerking: ik zeg niet dat u de serverpoort moet wijzigen. Ik beschrijf alleen redelijke redenen (IMO) om het poortnummer te wijzigen.

Als u dat doet, denk ik dat u aan elke andere beheerder of gebruiker moet duidelijk maken dat dit niet als een beveiligingsfunctie moet worden beschouwd en dat het gebruikte poortnummer zelfs geen geheim is en dat dit als een beveiligingsfunctie wordt beschreven dat echte veiligheid oplevert, wordt niet als acceptabel gedrag beschouwd.


2
2017-09-29 00:53



Logbestanden kunnen eenvoudig worden opgeruimd met de juiste filters. Als u het heeft over de prestaties van de server als gevolg van minder logboeken, dan hebben we het niet langer over beveiliging. Prestaties zijn helemaal een totaal ander onderwerp. - Pacerier
Niet wanneer de computer onbruikbaar wordt door overmatig schijfgebruik. - curiousguy
Ja, dat is een prestatieprobleem. Prestaties zijn ook zeker belangrijk, maar deze specifieke discussie gaat specifiek over alleen beveiliging. (Voor het doel van deze thread stelt u zich voor dat u de Google-grootte heeft en Google dat doet werkelijk wil die gegevens voor analyse en / of verkoopdoeleinden.) - Pacerier


Ik zie één hypothetische situatie waarbij er een potentieel beveiligingsvoordeel is bij het uitvoeren van uw sshd op een alternatieve poort. Dat zou in het scenario zijn waarin een triviaal uitgebuite externe kwetsbaarheid wordt ontdekt in de sshd-software die u gebruikt. In een dergelijk scenario kan het uitvoeren van uw sshd op een alternatieve poort u net de extra tijd geven die u niet nodig hebt om een ​​willekeurig drive-by-doel te zijn.

Zelf voer ik de sshd uit op een alternatieve poort op mijn privémachines, maar dat is vooral handig om de rommel in /var/log/auth.log tegen te houden. Op een systeem met meerdere gebruikers beschouw ik het bovenstaande kleine hypothetische beveiligingsvoordeel niet als voldoende reden voor extra gedoe doordat de sshd niet wordt gevonden op het standaardgedeelte.


1
2017-09-28 19:55



Het scenario zou alleen geldig zijn als alle admin (s) helemaal geen speelruimte zouden hebben met deze "extra tijd" ooit ga naar de lunch en etc. - Pacerier