Cik riskanti ir palaist SSH nodrošināto mājas serveri?

Ja jums ir nepieciešams atvērt kaut ko savā mājas tīklā uz lielāku internetu, ir SSH tuneļa drošs veids, kā to izdarīt?

Šodienas jautājumu un atbilžu sesija mums dod pieklājību no SuperUser-Stack Exchange apakšnodaļas, kas ir kopienas orientēta Q & A tīmekļa vietņu grupa.

Jautājums

SuperUser lasītājs Alfred M. vēlas uzzināt, vai viņš atrodas pareizajā ceļā ar savienojuma drošību:

Nesen es izveidoju nelielu serveri ar zemas klases datoru, kurā darbojas debian, lai to izmantotu kā personisku git repozitoriju. Es esmu iespējojis ssh un bija diezgan pārsteigts par to, cik ātri tā cieta no brutālu spēku uzbrukumiem un tamlīdzīgiem. Tad es izlasīju, ka tas ir diezgan izplatīts un uzzinājis par pamata drošības pasākumiem, lai izvairītos no šiem uzbrukumiem (daudz jautājumu un dublikātu, kas saistīti ar servera apkalpošanu, skatiet, piemēram, šo vai šo).

Bet tagad es domāju, vai tas viss ir vērts. Es nolēmu izveidot savu serveri lielākoties jautri: es varētu paļauties tikai uz trešo pušu risinājumiem, piemēram, tiem, ko piedāvā gitbucket.org, bettercodes.org utt. Lai gan daļa no jautrības ir par interneta drošības mācīšanos, es neesmu pietiekami daudz laika, lai to veltītu, lai kļūtu par ekspertu un būtu gandrīz pārliecināts, ka es veicu pareizus profilakses pasākumus.

Lai izlemtu, vai es turpināšu spēlēt šo rotaļlietu projektu, es gribētu zināt, ko es patiešām riskēšu. Piemēram, cik lielā mērā ir apdraudēti arī citi datori, kas savienoti ar manu tīklu? Dažus no šiem datoriem izmanto cilvēki ar mazākām zināšanām nekā mana sistēma Windows.

Kāda ir varbūtība, ka es nonākšu pie reālām problēmām, ja ievēroju pamatprincipus, piemēram, spēcīgu paroli, izslēgtu root piekļuvi ssh, nestandarta portu ssh un, iespējams, atspējot paroli un izmantojot kādu no fail2ban, denyhosts vai iptables noteikumiem?

Citiem vārdiem sakot, vai ir daži lieli slikti vilki, no kuriem man būtu jābaidās, vai tas viss ir galvenokārt par skriptu nolaupīšanu?

Ja Alfredam jāatrodas pie trešo pušu risinājumiem vai arī viņa DIY risinājums ir drošs?

Atbilde

SuperUser ziedotājs TheFiddlerWins pārliecina Alfredu, ka tas ir pilnīgi droši:

IMO SSH ir viena no drošākajām lietām, lai klausītos atklātajā internetā. Ja jūs patiešām uztraucaties, klausieties par nestandarta augstas klases portu. Man joprojām ir (ierīces līmeņa) ugunsmūris starp jūsu kasti un faktisko internetu un vienkārši izmantojiet portu pāradresēšanu SSH, bet tas ir piesardzība pret citiem pakalpojumiem. SSH pati par sevi ir diezgan nopelt.

I ir Ja cilvēki dažkārt skāra manu mājas SSH serveri (atvērts Time Warner Cable). Nekad nav bijusi faktiska ietekme.

Vēl viens dalībnieks, Stephane, izceļ, cik viegli ir vēl vairāk aizsargāt SSH:

Publiskās atslēgas autentifikācijas sistēmas izveide ar SSH ir patiešām maznozīmīga un aizņem aptuveni 5 minūtes.

Ja jūs piespiežat visus SSH savienojumus to izmantot, tad tas padarīs jūsu sistēmu tikpat elastīgu, kā jūs varat cerēt, nepalielinot LOT drošības infrastruktūrā. Atklāti sakot, tas ir tik vienkārši un efektīvi (ja vien jums nav 200 kontu - tad tas kļūst netīrs), ka to neizmantojot, vajadzētu būt publiskam pārkāpumam.

Visbeidzot, Craig Watson piedāvā citu tipu, lai samazinātu mēģinājumus ielauzties:

Es arī vadu personisku git serveri, kas ir atvērts pasaulei SSH, un man ir arī tādi paši brutālu spēku jautājumi kā jūs, tāpēc es varu līdzināties jūsu situācijai.

TheFiddlerWins jau risina galvenās drošības sekas, kas saistītas ar SSH atvēršanu publiski pieejamā IP, bet labākais rīks IMO, reaģējot uz brutāla spēka mēģinājumiem, ir Fail2Ban - programmatūra, kas uzrauga jūsu autentifikācijas žurnāla failus, atklāj ielaušanās mēģinājumus un pievieno ugunsmūra noteikumus mašīnas lokālāiptables ugunsmūris. Jūs varat konfigurēt gan mēģinājumu skaitu pirms aizlieguma, gan arī aizlieguma ilgumu (mana noklusējuma vērtība ir 10 dienas).

Vai kaut kas jāpievieno paskaidrojumam? Skaņas izslēgšana komentāros. Vai vēlaties lasīt vairāk atbildes no citiem tehnoloģiju gudriem Stack Exchange lietotājiem? Apskatiet pilnu diskusiju pavedienu šeit.