MaxSessions, MaxStartups vai ierīces reģistrācija: kuru SSH ierobežojumu izvēlēties

Tuneļu pakalpojumi, kas sola vienu ierīci uz abonentu, šo solījumu reti saņem no MaxSessions, un pirmais tests to parasti pierāda. Abonents atver otru ssh procesu, pirmā sesija turpina darboties, un abi tuneļi pārvadā datu plūsmu. Katra konfigurācijas opcija skaita ko citu, un neviena no tām neskaita ierīces. Solījuma nosaukšana vispirms padara izvēli starp tām acīmredzamu.

Ko katra opcija patiešām skaita

MaxSessions ierobežo atvērto sesiju skaitu, ko pārvadā viens autentificēts tīkla savienojums. Sesija šeit nozīmē čaulu, exec pieprasījumu, apakšsistēmu, piemēram, SFTP, vai līdzīgu kanālu, kas multipleksēts vienā SSH transportā. Otrs ssh izsaukums atver otru transportu, autentificējas no jauna un saņem savu atļauju. Pirmā savienojuma sesiju skaits tam nav svarīgs.

MaxStartups ierobežo vienlaicīgus savienojumus, kas vēl nav autentificēti, izteiktus kā sākuma slieksni, likmi un pilnu slieksni. Tas pastāv, lai puscaurspīdīgu rokasspiedienu uzplūds nevarētu izsmelt dēmona resursus pirms autentifikācijas. Kad klients autentificējas, šis savienojums pārstāj skaitīties pret MaxStartups un kļūst par kāda sesiju. Tas nekad nav bijis kvota uz lietotāju, un tā palielināšana neļauj abonentam darīt vairāk.

Ierīces reģistrācijas noteikums nemaz nav sshd opcija. Tas pieder jebkurai sistēmai, kas izsniedz akreditācijas datus un seko līdzi, kura ierīce tos glabā, kas nozīmē, ka tai vajag reģistrāciju, uzskaiti un atsaukšanu, nevis skaitītāju. Šīs prasības sajaukšana ar sshd konfigurāciju ir vieta, kur lielākā daļa šādu projektu iestrēgst.

Kur MaxSessions pārstāj būt kvota

Match User bloks maina, kuras konfigurācijas vērtības attiecas uz šo lietotāju, tāpēc tā ir dabiskā vieta stingrākai MaxSessions pakalpojuma kontam. Ko tas nevar, ir apkopot starp savienojumiem, jo opcija tiek novērtēta katram transportam. Divi transporti saņem katrs savu ierobežojumu, un lietotājam beigās ir divreiz vairāk, nekā bloks atļauj.

Pāradresēšana ir atsevišķs pārsteigums. TCP pāradresēšanai nav vajadzīgs sesijas kanāls, tāpēc MaxSessions 0 var aizliegt čaulas un apakšsistēmas un joprojām atļaut -L un -R tuneļus. Pakalpojums, kas tikai pāradresē un uzskata sesiju skaitu par savu tuneļa kvotu, nemēra neko. Šī uzvedība ir dokumentēta OpenSSH servera konfigurācijas uzziņā, un to ir vērts izlasīt pirms projektēšanas ap opcijas nosaukumu.

Izvadiet efektīvo konfigurāciju, nevis failu, kuru, jūsuprāt, esat ielādējis. Iekļaušanas un drop-in mapes bieži nozīmē, ka spēkā esošā vērtība nav tā, kuru jūs rediģējāt.

MaxStartups aizsargā dēmonu, nevis abonentu

MaxStartups trīsdaļīgā forma apraksta, cik neautentificētu savienojumu var pastāvēt, pirms dēmons sāk izmest procentuālu daļu jauno. Tā noklusējuma forma pastāv tāpēc, ka neautentificētu SSH savienojumu ir lēti atvērt un dārgi uzturēt. Tas ir servera resursu aizsardzības kontrole, un tā attiecas uz visiem vienlaikus.

Tā palielināšana pieteikšanās vētras laikā apmaina dēmona aizsardzību pret uzņemšanu, kas dažkārt ir pareizā apmaiņa un vienmēr apzināta. Tas neko nedod abonentam, kurš vēlas otru tuneli, jo pirmais tunelis jau ir autentificēts. Abu sajaukšana noved pie izmaiņām, kas labo nepareizo simptomu un vienlaikus vājina serveri.

Kad pieteikšanās tiek noraidīta grūzienos, pirms pieskaraties jebkurai opcijai apskatiet dēmona žurnālā ziņojumu pirms autentifikācijas. Ziņojums nosauc, kura aizsardzība iedarbojās, un aizsardzības nav savstarpēji aizvietojamas.

Slotam uz lietotāju vajadzīgs kopīgs stāvoklis

Īstai viena aktīva transporta politikai vajadzīga rezervācija, kas tiek turēta kaut kur ārpus sshd. Uzņemšanas solim ir atomiski jāieņem konta slots, jāatbrīvo tas, kad savienojums aizveras, jāļauj tam beigties, kad klients pazūd, neaizverot, un jāizlemj, vai jauns mēģinājums tiek noraidīts vai aizstāj veco. Šis pēdējais lēmums ir produkta lēmums, nevis tehniska detaļa, jo aktīva tuneļa aizstāšana kādu atvieno.

Rezervācija ir jādala arī katram serverim, kas pieņem kontu. Divi resursdatori ar neatkarīgiem vietējiem skaitītājiem piemēro divus atsevišķus ierobežojumus, un abonents, kas atkārtoti piesakās caur otru vārteju, bez maksas iegūst otru slotu. Kam vien glabājas stāvoklis, tam vajadzīga sava atteices uzvedība, jo nepieejama krātuve nedrīkst bloķēt visus abonentus.

Vienas ierīces solījumam izsniedziet atsevišķus akreditācijas datus katrai reģistrētajai ierīcei un kontrolējiet reģistrāciju un atsaukšanu tajā slānī. Nokopēta privātā atslēga joprojām autentificējas no jebkurienes, tāpēc vienas atslēgas izsniegšana vienam lietotājam nav pierādījums par to, cik daudz mašīnu to glabā.

Pārbaudiet politiku ar diviem īstiem savienojumiem

Uzrakstiet pieņemšanas testus kā komandas, pirms rakstāt politiku. Pieci gadījumi ir otrs transports, kas atvērts, kamēr pirmais ir aktīvs, vairāki kanāli vienā transportā, klients, kas tikai pāradresē portus, atkārtota savienošanās pēc saites pārrāvuma, un tas pats konts, kas ierodas citā vārtejā.

Vispirms izlasiet efektīvos ierobežojumus, pēc tam atveriet savienojumus, kurus politikai vajadzētu noraidīt. Abas šī testa puses ir svarīgas, un neviena neaizstāj otru.

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

Palaidiet tuneļa komandu divreiz divos termināļos un saskaitiet izveidotos savienojumus portā 22. Ja abi pārvadā datu plūsmu, kamēr jūsu politika apgalvo vienu aktīvu transportu, politika ir dokumentācija, nevis izpilde. Labojiet šo plaisu uzņemšanas slānī, nevis samazinot MaxSessions un cerot, ka otrais transports to pamanīs.