Vraag Waarom zou je de standaard ssh-poort veranderen? [Gesloten]


Ik heb gemerkt dat veel beheerders de standaard ssh-poort wijzigen.

Is er een redelijke reden om dit te doen?


46
2017-10-09 08:05


oorsprong


Duplicaat van unix.stackexchange.com/q/2942/9454 - Martin Schröder


antwoorden:


Het is niet zo nuttig als sommige mensen beweren, maar het vermindert op zijn minst de impact op je logbestanden omdat veel brute force-inlogpogingen alleen de standaardpoort gebruiken in plaats van scannen om te zien of SSH ergens anders luistert. Sommige aanvallen zullen echter elders op SSH scannen, dus het is geen wondermiddel.

Als uw server een soort gedeelde host van een bepaalde soort wordt, in plaats van alleen de behoeften van uw projecten te bedienen, kan het lastig zijn om een ​​niet-standaardpoort te gebruiken, omdat u dit steeds opnieuw aan uw gebruikers moet uitleggen en over wanneer ze het vergeten en hun client-programma's geen verbinding maken met poort 22!

Een ander mogelijk probleem met SSH op een niet-standaard poort is als u een client tegenkomt met een beperkende uitgaande filterset, die geen verbinding met uw aangepaste poort kan maken omdat hun filter bijvoorbeeld alleen poorten 22, 53, 80 toestaat en 443 als de bestemming voor nieuwe uitgaande verbindingen. Dit is ongebruikelijk, maar zeker niet ongehoord. Op dezelfde manier kunnen sommige ISP's versleuteld verkeer zien op een andere poort dan die waar het algemeen wordt verwacht (poort 443 of HTTPS, 22 voor SSH, enzovoort) als een poging om een ​​P2P-verbinding en gasklep (of blokkering) te verbergen de verbinding op een ongemakkelijke manier.

Ik houd SSH persoonlijk op de standaardpoort voor het gemak. Zolang de gebruikelijke voorzorgsmaatregelen worden getroffen (sterk wachtwoord / sleutelbeleid, beperking van rootaanmeldingen, ...) hoeft u zich geen zorgen te maken en kan het probleem met de groei van het logbestand wanneer u wordt getroffen door een brute force-aanval worden beperkt met behulp van tools zoals als fial2ban om hosts tijdelijk te blokkeren die in een bepaalde tijd te veel slechte sets verificatiegegevens bevatten.

Welke poort je ook kiest, als je 22 verwijdert, zorg dan dat deze onder de 1024 ligt. Onder de meeste Unix-a-like setups in hun standaardconfiguratie, kan alleen root (of gebruikers in de root-groep) luisteren op poorten onder 1024, maar elke gebruiker kan op de hogere poorten luisteren. SSH uitvoeren op een hogere poort verhoogt de kans dat een bedrieglijke (of gehackte) gebruiker je SSH-daemon crasht en vervangt door zijn of haar eigen proxy.


63
2018-02-07 16:26



Ik ben de enige gebruiker van deze server. Bedankt voor het verduidelijken van het probleem 1024+. Ik zou een 48xxx-poort hebben gebruikt als ik had gekozen. Hoe dan ook, ik snap het nog steeds niet als het nuttig is of niet = / - dynamic
+1 voor het> 1024-bit. - MattC


Het is een eenvoudige (maar verrassend effectieve) vorm van veiligheid door duisternis.

Als uw SSH-server zich niet op poort 22 bevindt, is het veel minder waarschijnlijk dat deze wordt gevonden door diegenen die het hele internet scannen op zoek naar zwakke wachtwoorden op standaardaccounts. Als u het hele net scant, kunt u het zich niet veroorloven om alle 64k mogelijke poorten te controleren om de SSH-server te vinden.

Als iemand echter specifiek op u gericht is, biedt het geen voordeel, omdat het een eenmalig probleem is nmap scan onthult de poort waarop het daadwerkelijk wordt uitgevoerd.


27
2017-10-09 08:25



"controleer alle 64k mogelijke poorten"... SSH uitvoeren in elke poort boven 1023 is gewoon verkeerd. Het maakt het systeem meer kwetsbaarder dan het draaiende te laten in zijn standaardpoort. - Juliano
@ Juliano - graag uitleggen. Alleen omdat jij hebben root zijn om te luisteren op een bevoorrechte poort maakt het niet (AFAIK) onzeker om op een niet-bevoorrechte poort te rijden. - Alnitak
Trouwens, het is geen beveiliging door middel van obscuriteit, anders zul je ook wachtwoordverificatie hetzelfde moeten noemen. Beveiliging door middel van obscuriteit is wanneer de implementatie niet wordt bekendgemaakt. Hier wordt de implementatie duidelijk vermeld (het is "ik veranderde de servicepoort"), en het geheim ("welke poort?") Is nog steeds geheim. - Juliano
@John - eigenlijk zie ik het punt van @ Juliano. Het maakt de SSH-daemon zelf niet intrinsiek minder veilig, maar in het algemene geval loopt het gebruik van een niet-bevoorrechte poort de normale veronderstelling dat root begonnen de daemon. Dus als je die daemon op de een of andere manier kunt stoppen (bijvoorbeeld door DoSing it), kun je je eigen nepdaemon op zijn plaats starten zonder root-exploit. Die valse daemon kan dan voldoende details vastleggen om verdere exploits mogelijk te maken. - Alnitak
@John, dat klopt - het vereist nog steeds dat de aanvaller voldoende toegang heeft gekregen om zelf een nieuwe daemon te starten. Het belangrijkste punt is dat ze niet langer nodig hebben wortel toegang om het te starten. - Alnitak


Om bruteforce-aanvallen echt te vermijden, is het altijd belangrijk om een ​​aantal stappen te volgen:

  • Installeer denyhosts of fail2ban
  • Beperk het aantal verbindingen per seconde op de ssh-poort
  • Wijzig ssh-poort
  • Geweigerde root-aanmelding
  • Schakel verificatie per sleutel in in plaats van wachtwoord

22
2017-11-14 21:29



Lijkt een goede lijst, behalve het deel voor poortwisseling waar ik het niet helemaal mee eens ben, dat is te veel onduidelijkheid. Een moderne poortscanner zal het toch binnen een paar seconden vinden? (en veel netwerken laten geen willekeurig poortverkeer uit, meestal beperkt tot bijvoorbeeld 22, 80 en 443) - Oskar Duveborn
De poortwijzigingslimiet brute force-aanvallen die controleren of SSH op de standaardpoort wordt uitgevoerd, is goed als de aanval ernstiger is, alleen kan de aanvaller in dit geval een scan uitvoeren van de gatpoorten in uw netwerk / hosts. - Ali Mezgani
In feite denk ik dat achter een goede firewall, als u uw services up-to-date houdt en als u de standaardinstelling van hen wijzigt, u mogelijk veilig bent voor kwaadwillende aanvallen. en mogelijk niet vanaf 0-daagse exploits of onbekende aanvallen - Ali Mezgani
Het gebruik van denyhosts / fail2ban vermindert de noodzaak om van poort te wisselen of sleutels nodig te hebben. Als u geen wachtwoorden toestaat, heeft het geen zin om denyhosts / fail2ban te gebruiken of poorten te wijzigen. - Jeremy L
Het gebruik van denyhosts / fail2ban hoeft niet noodzakelijkerwijs de noodzaak van aanvullende beveiligingsmaatregelen te verminderen. Het punt van beveiliging is om zoveel mogelijk wegblokkeringen te creëren voor gebruikers die proberen de beveiliging te omzeilen. Natuurlijk hoef je de poort waarschijnlijk niet van 22 tot 2222 te veranderen, maar zeg je dat een andere beheerder langskomt en wachtwoord opnieuw inschakelt ... je hebt nog steeds verschillende andere verkeersdrempels op zijn plaats. Elke stap hierboven vermeldt de beheerder een percentage dicht bij de onmogelijkheid van 100% beveiliging. - Patrick R


Ja, het is handig omdat het gewoon helpt alle brute force-aanvallen te voorkomen en helpt om de logs vrij te houden :)

wat betreft het poortnummer dat aan jou ligt, ik heb gezien dat bedrijven 1291 vrij vaak gebruiken. Ik gebruik echter iets hogers alleen om te helpen sommige van de scripts te vermijden.

Geen root SSH-aanmeldingen toestaan ​​en het poortnummer wijzigen en misschien iets als fail2ban en u zou goud moeten zijn. voeg iptables toe voor een goede maatregel en hou je spullen up-to-date en je zou geen problemen mogen hebben.


12
2018-02-07 16:13



+1 voor "het bijhouden van de logboeken" - Lekensteyn
Maar kijk naar Het antwoord van David Spillett om te weten waarom poort 1291 (groter dan 1024) gevaarlijk kan zijn. - Konerak
Als je 2 jaar na veel andere, betere antwoorden gaat adviseren om een ​​niet-bevoorrechte haven te gebruiken, bereid je dan misschien een betere reden voor dan 'Ik heb bedrijven het zien doen'. Ik heb bedrijven veel dingen zien doen. Ik wil zelden hun voorbeeld volgen. - underscore_d


Het gebruik van een niet-standaard SSH-poort vereist meer uitleg en documentatie, en het beantwoorden van "ik kan niet inloggen" e-mails.

Ik beschouw het volgende voordelen van het runnen van sshd op a niet standaard poort belangrijker dan de problemen die het creëert:

  • 99,9999% van de aanvallen met brute kracht worden uitgevoerd door bots die alleen naar poort 22 zoeken en nooit tijd verspillen met het proberen de niet-standaard poort te vinden. Brute-force aanvallen en de tegenmaatregelen zoals denyhosts of fail2ban verbruik resources, die je opslaat door simpelweg de ssh-server op een niet-standaard poort te gebruiken.
  • U raakt verlost van alle nutteloze rapporten over bots die proberen in uw systeem te breken. Als er een IP wordt weergegeven in het rapport met mislukte aanmeldingen, is de kans groot dat dit een mens is.

Bovendien, als je echt heel smerig wilt zijn, kun je altijd een valse sshd uitvoeren (met DenyUsers * ) op de standaardpoort 22, terwijl uw reguliere sshd op poort 54321 werkt. Dit verzekert u dat alle bots en indringer-wannabes voor eeuwig zullen proberen in te loggen bij een service die alle aanmeldingen weigert, omdat niemand ooit zal denken om te proberen uw echt sshd-service.

Mijn 2 cent.


11
2017-11-14 23:17



Dit kan echter resulteren in nog meer ondersteuningsoproepen. - Brad Gilbert
Dit is waar, maar voor verbeterde beveiliging geldt een prijs. :) - Born To Ride


Om dit te doen voor een "beveiligings" reden is nep. Het is het beste voorbeeld van beveiliging door onbekendheid dat geen beveiliging is.

Als je je logs een beetje lichter en schoner wilt houden, dan is dat inderdaad handig, want je zult niet zoveel port-knocking / script-kiddy bruteforce-pogingen krijgen.


10
2017-10-09 08:25



Yep. Toen ik ssh had op poort 22, had ik> 20000 mislukte wachtwoordpogingen in mijn logs per dag. Wat betekende dat ik elke dag een e-mail met beveiligingswaarschuwingen ontving. Ik had wachtwoordverificatie uitgeschakeld - je moest een goede privésleutel hebben om in te loggen - dus ik maakte me geen zorgen over iemand die instapte, maar ik kreeg liever alleen e-mails over beveiligingswaarschuwingen als er iets echts aan de hand was. - jdege


Ik zou SSH op de standaardpoort uitvoeren en zoiets gebruiken fail2ban of denyhosts om het aantal woordenboekaanvallen te beperken.

Een andere optie is om inloggen met wachtwoorden altogheter uit te schakelen en alleen aanmeldingen met ssh-sleutels toe te staan.


9
2017-11-14 21:27





Omdat er veel slechte mensen zijn die alle server-IP's scannen op open poorten in een poging misbruik te maken. Ik had de hele dag hameraanvallen op mijn SSH-poort totdat ik deze naar een andere poort en op een IP-adres verhuisde dat niet meer aan een van mijn websites was gekoppeld.


8
2017-10-09 08:08





Ik verander altijd mijn SSHd om poort 2222 te gebruiken, iedereen die op mijn servers moet komen weet dit en het is geen geheim. Er is absoluut geen veiligheidswinst te behalen (tenzij de zogenaamde hacker een absolute idioot is).

Het enige voordeel Ik krijg hieruit dat het Auth-logboek geen miljoen mislukte inlogpogingen heeft voor 'root', 'alice', 'bob', 'sally', 'admin', etc.


7
2018-02-07 20:04





Het is handig dat de script-bots die brute-force wachtwoord-gissende aanvallen gebruiken zich meestal richten op poort 22, dus het veranderen van de poorten gooit ze meestal uit. Je zult de waarde van het mitigeren van dat risico in evenwicht moeten brengen met de pijn van het configureren van SSH-clients om verbinding te maken met de niet-standaardpoort (geen erg grote pijn als je niet veel gebruikers hebt die verbinding maken, weliswaar).

Als alternatief kunt u het brute-force-risico verminderen door wachtwoordverificatie uit te schakelen en in plaats daarvan RSA-key-verificatie te vereisen.

Ik verander meestal niet de poort op SSHD, dus ik kan geen ander nummer voorstellen, maar controleer de veelgebruikte lijst met poorten om een ​​ander nummer te vinden (dat wil zeggen een nummer dat niet door iets anders wordt gebruikt en dat dus kan worden gescand).


6
2018-02-07 16:16





Ik zou zeggen dat het ding waar je jezelf het meest tegen beschermt bij het veranderen van de SSH-poort geautomatiseerde scans zijn die proberen toegang te krijgen met behulp van standaard gebruikersnamen / wachtwoorden, als je wachtwoordbeleid krap is, hoef je je geen zorgen te maken over hen.


4
2017-11-14 21:28



om nog te zwijgen van dat een havenscanner andere havens ook zal proberen. - Jim Deville