Ако управљате Линукс сервером који је изложен интернету, пре или касније ћете видети у логовима хиљаде покушаја SSH пријаве са насумичних IP адресаНије да су вас заволели: то су аутоматизовани ботови који обилазе ИП опсеге тражећи слабо заштићена врата.
На малом серверу, ти покушаји могу се претворити у Скокови у употреби процесора, смањење перформанси, па чак и повремени прекиди сервисаДобра вест је да Линук нуди арсенал алата за ограничавање покушаја лозинке, блокирање агресивних ИП адреса и ојачавање SSH-а како би га нападачу учинио веома тешким.
Детекција SSH напада грубом силом и њихов утицај на сервер
Пре него што почнемо са конфигурисањем било чега, корисно је да разумемо како да откријемо да ли доживљавамо напад грубом силом на SSH или друге сервисеи какве ефекте то има на машину.
Веома типичан симптом је појављивање изненадно повећање оптерећења процесора без икакве промене у легитимном саобраћају или оптерећењу базе податакаНа пример, можете имати скок процесора на неколико минута док коришћење меморије и диска остаје практично непромењено, што обично указује на процесе који захтевају много рачунарских ресурса (као што је много покушаја аутентификације), а не на тешке упите.
Да би се анализирало шта се дешавало у одређеном интервалу, веома је корисно користити јоурналцтлАлат systemd за читање системских, сервисних, кернел и логова аутентификације. Класичан пример упита би био:
journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"Са том врстом упита можете детаљно прегледати Које је поруке систем забележио током периода у којем је дошло до скока оптерећења процесора?: сервиси који се поново покрећу, неуспеси аутентификације, грешке језгра итд.
У многим случајевима ћете наћи понављајуће редове везане за SSH, као што је „Неуспешна лозинка за“ означава неуспеле покушаје пријављивањаТо је практично синоним за ботове који грубом силом тестирају акредитиве.
Квантификујте неуспеле покушаје у /var/log/auth.log
На Debian/Ubuntu системима, кључна датотека за праћење свега што је везано за аутентификацију је /вар/лог/аутх.логОвде се бележе успешни покушаји пријављивања, неуспели покушаји, PAM догађаји, закључавања налога итд.
Ако желите да знате колико пута је образац снимљен „Неуспешна лозинка“ у тренутном дневнику, можете користити:
sudo grep 'Failed password' /var/log/auth.log | wc -lРезултат може бити изненађујући: није неуобичајено видети хиљаде неуспелих покушаја нагомиланих за само неколико сатиИ запамтите да је то само тренутна датотека.
Пошто се логови ротирају, важно је прегледати и старије датотеке. Можете видети који временски интервал покрива тренутни лог на неки начин:
head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.logНа тај начин ћете знати Датум првог и последњег записа присутног у auth.logОстатак претходних покушаја биће у датотеци auth.log.1 и у компресованим датотекама auth.log.N.gz.
Да бисте прегледали компримоване старе логове и пребројали неуспеле покушаје уноса лозинке, можете користити:
zgrep 'Failed password' /var/log/auth.log.*.gz | wc -lАко саберете оно што видите у auth.log, auth.log.1 и auth.log.*.gz Добићете добру представу о Историјски запис напада грубом силом, узимајући у обзир да су најстарији можда већ нестали због ротације.
Како функционише ротација дневника аутентификације
Начин и учесталост ротације логова зависи од конфигурације постићиУ Убунтуу, ротација датотеке auth.log је обично дефинисана у /etc/logrotate.d/rsyslog, где ћете обично пронаћи нешто попут:
weekly
rotate 4
compressТо значи да Дневник се ротира недељно, чувају се четири старе копије, а старе се компресују у .gz датотеке.Дневни cron задатак је одговоран за покретање logrotate-а и примену ових правила.
Стога, када израчунавате своје покушаје грубе силе, претпоставите да Видите само историјске податке од пре неколико недеља.Све што се догодило раније више неће бити у систему.
Идентификујте нападачке кориснике и ИП адресе
Поред укупног броја, важно је знати Који корисници су циљани и са којих ИП адреса долазе напади?Са мало awk-а на auth.log-у имате га при руци.
Да бисте видели која корисничка имена се користе у неуспешним покушајима:
sudo grep 'Failed password' /var/log/auth.log \
| awk '{print $(NF-5)}' \
| sort | uniq -cА да бисте видели ИП адресе са најсумњивијом активношћу:
sudo grep 'Failed password' /var/log/auth.log \
| awk '{print $(NF-3)}' \
| sort | uniq -c | headОво ће вам омогућити да брзо откријете да ли нападају. прави налози са вашег система или генерички корисници као што су root, admin, test, user итд., и које IP адресе треба најхитније да блокирате.
Да ли је заиста толико озбиљно да постоје хиљаде покушаја?
Мора се претпоставити да, ако је вашем серверу доступан са интернета и има SSH слушање на порту 22 или било ком другомОвај сервер ће примати ову врсту саобраћаја 24 сата дневно. Нормално је видети хиљаде неуспелих покушаја ако сервер ради дуже време.
Стварна гравитација зависи од ваших подешавања:
| конфигурација | Приближан ризик |
|---|---|
| Слабе лозинке + отворени SSH ка интернету | Веома висок ризик од компромиса |
| Јаке лозинке | Умерен ризик, али потрошња ресурса |
| Fail2ban је правилно конфигурисан | Напади ниског ризика и високог степена ублажавања |
| Приступ само са SSH кључевима | Ризик веома близу нуле уз помоћ грубе силе |
Другим речима: аутоматизовани напади су уобичајени, али ако је ваша конфигурација лабава, Само једна неуспешна лозинка је довољна да изгубите цео сервер.Зато је толико важно ограничити покушаје, блокирати ИП адресе и, где је то могуће, елиминисати лозинке.
Основно SSH јачање: критичне опције у sshd_config
Прва линија одбране је у себи самом SSH демон (sshd) и његова конфигурациона датотека /etc/ssh/sshd_config (и повезане .d датотеке). Неколико добро подешених директива значајно смањује површину напада.
Имајте на уму да у модерним дистрибуцијама као што је Ubuntu 22.04 и новијим, sshd прво чита /etc/ssh/sshd_config, а затим датотеке у /etc/ssh/sshd_config.d/*.conf по абецедном реду. Све што се појави касније може пребрисати претходно дефинисане параметре, зато будите веома пажљиви шта мењате.
Онемогућите приступ без лозинке и непотребне сесије
Иако долази добро конфигурисан у већини модерних дистрибуција, не шкоди потврдити то Пријављивања без дефинисане лозинке нису дозвољена.Кључна директива је:
PermitEmptyPasswords noОбично је коментарисано или експлицитно подешено на „не“. Такође, уверите се да имате онемогућене функције које нећете користити, као што су... X11 Преусмеравање (X11Форвардинг) Ако не радите даљинске графичке сесије:
X11Forwarding noШто се тиче протокола, ако из било ког разлога управљате веома старим системом, проверите да ли су дозвољене само одређене радње. SSH протокол 2:
Protocol 2Промените подразумевани порт и ограничите на ком интерфејсу слуша.
Још један једноставан, мада не и непогрешив, трик је Преместите SSH са порта 22 на нестандардни порт.Ово вас не штити од озбиљног нападача, али филтрира значајну количину аутоматизоване буке која скенира само 22.
Port 2222
ListenAddress 192.168.56.8Поред промене порта, можете навести одређену адресу на којој ће SSH слушати, на пример, вашу интерну IP адресу ако желите да је ограничите на одређену мрежу. Међутим, ако ваша дистрибуција користи systemd-ов ssh.socket, можда ћете морати... Онемогућите сокет и вратите се на класични ssh.service сервис. да би се поштовала конфигурација порта:
sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.serviceКад год промените порт, тестирајте везу са другог терминала пре него што затворите главну сесију, како не бисте остали без удаљеног приступа.
Блокирајте или ограничите root приступ
Корисник root је лак плен за нападаче, тако да има смисла. спречити повезивање преко SSH-ачак и са лозинкама. Ово понашање контролишете директивом:
PermitRootLogin noУ многим модерним инсталацијама, долази у режиму „забрани лозинку“, који спречава пријаве лозинком, али оставља врата отворена за сертификате. Ако желите да будете безбедни, оставите подешено на „не“ и користите обичан налог са sudo за администрацију.
Дефинишите ко може да приступи: ДозволиКориснике и ДозволиГрупе
Подразумевано, сваки корисник са важећа љуска и дефинисана лозинка Можете покушати да се повежете путем SSH-а. То обично није идеално на продукционим серверима, где би можда само два или три налога требало да имају приступ.
Да бисте ограничили дозвољене кориснике, имате следеће директиве. АлловУсерс y ДозволиГрупе. На пример:
AllowUsers harry hermione
AllowGroups gryffindorЛиста је одвојена размацима, а семантика је као код „беле листе“: Само наведени налози и групе ће моћи да се аутентификујуТакође имајте на уму да AllowUsers има предност над AllowGroups, зато их немојте мешати осим ако вам није јасан редослед евалуације.
Добра пракса је рад првенствено са типичним групама. ssh корисници или администратори и додајте овлашћене налоге тамо, уместо да чувате листу корисника једног по једног у датотеци.
Ограничите покушаје аутентификације и време застоја
Још један слој заштите је унутра Смањите број неуспелих покушаја дозвољених за једну везу и колико дуго сесија може остати неактивна. За прво питање можете користити:
MaxAuthTries 3Овим ће сервер прекинути везу након три погрешна покушаја, што Због тога је сваки напад који испробава много лозинки против исте SSH сесије мање ефикасан..
Што се тиче времена неактивности, SSH вам омогућава да прекинете везе које остају отворене без активности изван дефинисаног прага. ИнтервалживостиКлијента (у секундама):
ClientAliveInterval 180Након три минута без саобраћаја, сервер ће послати поруке о одржавању активности и, ако клијент не одговори, Сесија ће се аутоматски затворитиТо је начин да се смање ризици од заборављених, откључаних терминала.
Ограничите приступ по IP адреси: TCP Wrappers and Match
У неким сценаријима би вас могло занимати Само одређене IP адресе или опсези могу приступити путем SSH-аИмате неколико начина да то урадите: од самог заштитног зида (iptables/nftables), преко TCP Wrappers-а, до Match блокова sshd_config-а.
Са TCP Wrapper-има, који се и даље користе у многим дистрибуцијама, приступ се контролише помоћу /etc/hosts.allow и /etc/hosts.deny. Ток је следећи: Прво се процењује hosts.allow, а затим hosts.deny.Рестриктиван пример би био:
# /etc/hosts.deny
ALL: ALL# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENYСа том конфигурацијом, Само два одређена хоста ће моћи да се повежу путем SSH-аа остало ће бити забрањено. Веома је ефикасан у затвореним окружењима, иако мање флексибилан од доброг модерног заштитног зида (фајервола).
Друга опција, типичнија за SSH, је коришћење блокова Match унутар sshd_config да бисте применили правила на основу адресе или корисника. Замислите да желите да корисник „git“ може да се пријави са било ког места, али ваш администраторски корисник „greg“ може да се пријави само са локалне мреже 192.168.1.0/24. Можете комбиновати правила AllowUsers са Match Address, иако морате бити веома пажљиви да... не затварај се од себе.
Fail2ban: Аутоматски блокови наспрам грубе силе
Чак и ако ојачате SSH, ботови ће и даље покушавати да провере акредитиве, што ће довести до оптерећења процесора и буке у логовима. Да би се ово ублажило, ово долази до изражаја. Fail2ban, систем за спречавање упада заснован на логовима који аутоматски блокира ИП адресе са превише грешака.
Fail2ban је написан у Пајтону и ослања се на „затворе“ или затвори, сваки повезан са услугом и једном или више датотека дневникаКада открије понављајући образац грешке (грешке са лозинком, забрањен приступ итд.), покреће акције, обично правила заштитног зида (фајервола) како би блокирао извор.
Инсталирајте Fail2ban на уобичајене Linux дистрибуције
Основна инсталација је прилично једноставна користећи менаџер пакета ваше дистрибуције. На Ubuntu-у или Debian-у, ово би било довољно:
sudo apt update
sudo apt install fail2banУ системима заснованим на RHEL-у (RHEL, CentOS, AlmaLinux, Rocky, итд.) типична команда би била with dnf или yum, у зависности од верзије:
sudo dnf install fail2banПакет обично укључује системску услугу која се покреће аутоматски, мада је вредно проверити то Fail2ban се покреће при покретању система и активан је:
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2banСтруктура конфигурације: jail.conf, jail.local и jail.d
Конфигурација се налази у /etc/fail2ban/Главна датотека је jail.conf, али се не препоручује њено директно уређивање јер се преписује током ажурирања. Уместо тога, требало би:
- Креирајте или измените /etc/fail2ban/jail.local да пребрише подразумеване вредности.
- Или додајте одређене датотеке у /etc/fail2ban/jail.d/*.conf.
Fail2ban учитава конфигурацију овим редоследом:
/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.localСве што дефинишете у jail.local има предност над свим што је било пре тога, тако да Можете прилагодити без додиривања датотека пакета..
Важни глобални параметри: време забране (bantime), максимално понављање (maxretry), игнорисање IP-а
Унутар датотеке jail.conf (или jail.local) видећете одељак [DEFAULT] са глобалним параметрима који утичу на све затворе, осим ако се не пренапишу. Најважнији су:
- бантиме: време током којег ће IP адреса бити блокирана (у секундама) након прекорачења дозвољеног броја грешака.
- макретри: максималан број неуспелих покушаја пре примене забране.
- финдтимевременски прозор у коме се ти покушаји рачунају (нпр. 10 м током десет минута).
- игноришите ipлиста ИП адреса или опсега које Fail2ban никада не би требало да блокира (на пример, ваша јавна ИП адреса или ваша управљачка мрежа).
На пример, могли бисте имати нешто овако у [DEFAULT]:
[DEFAULT]
bantime = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24Са том конфигурацијом, Свака IP адреса која не успе пет пута у десет минута биће блокирана десет минута., осим ако није део игнорисаних опсега.
Конфигуришите jail sshd да бисте зауставили SSH нападе
Најчешћи затвор је SSH затвор. У многим дистрибуцијама, долази унапред конфигурисан у jail.conf; само треба да га активирате или фино подесите његове вредности у jail.local. Једноставан пример:
[sshd]
enabled = true
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 600
findtime = 10mУ овом случају Три неуспешна покушаја пријављивања забележена у auth.log у року од десет минута резултираће десетоминутном блокадом IP адресе нападача.Fail2ban убацује правила у заштитни зид (iptables, nftables или UFW, у зависности од система) тако да везе са те IP адресе чак ни не стижу до sshd-а.
Да бисте применили било какве измене конфигурације, не заборавите да поново покренете услугу:
sudo systemctl restart fail2banПогледајте статус затвора и блокираних ИП адреса
Fail2ban укључује веома практичан услужни програм за контролу, fail2ban-клијентПомоћу овог алата можете видети који су затвори активни и које су ИП адресе блокиране. На пример:
sudo fail2ban-client statusПоказало би нешто слично:
Status
|- Number of jail: 1
`- Jail list: sshdЗа детаљније информације о SSHD затвору:
sudo fail2ban-client status sshdИзлаз укључује, између осталог, број тренутно забрањених ИП адреса и укупан историјски број адреса које су блокиране барем једном, плус текућа листа ИП адреса.
Са овим подацима можете стећи представу о Колико злонамерног саобраћаја ваш сервер прима и колико је ефикасна тренутна конфигурација?.
Трајне браве и постепено забрањивање
Ако желите да будете посебно строги према поновљеним преступницима, Fail2ban нуди две занимљиве стратегије: трајна забрана и постепена забрана.
Да бисте трајно забранили било коју IP адресу која прелази праг грешке, једноставно унесите:
bantime = -1Са тим прилагођавањем, Санкционисане ИП адресе се никада не деблокирају аутоматскиМожете их ручно уклонити само ако је потребно.
Флексибилнији је инкрементални механизам, у којем сваки рецидив повећава време забране према одређеном фактору:
bantime = 10m
bantime.increment = true
bantime.rndtime = 0
bantime.factor = 4
bantime.maxtime = -1Са овим вредностима, прогресија би изгледала отприлике овако:
- 1. блок: КСНУМКС Минутос
- 2. блок: КСНУМКС Минутос
- 3. блок: КСНУМКС Минутос (~2 сата и 40)
- 4. блок: око КСНУМКС сати
- 5. блок: неки КСНУМКС сати
Пошто је bantime.maxtime -1, трајање може наставити да расте унедоглед, остављајући заиста тешке удараче ван игре заувек.
Коришћење Fail2ban-а изван SSH-а: Apache, WordPress, MySQL, онлајн продавнице…
Када се навикнете на Fail2ban, логично је да га проширите на заштитите друге осетљиве сервисе поред SSH-а: веб административни панели, CMS, базе података итд.
На пример, за онлајн продавницу (Magento, PrestaShop, WooCommerce…) има много смисла направити затвор који прати Записи о приступу Apache-у или Nginx-у који траже много 401/403 кодова у /admin или /loginМинимална конфигурација заснована на Apache-у би могла бити:
[apache-auth]
enabled = true
filter = apache-auth
logpath = /var/log/apache2/access.log
maxretry = 5
bantime = 3600У WordPress окружењима, уобичајена комбинација је праћење /wp-login.php и /xmlrpc.phpОво су класичне улазне тачке за нападе грубом силом и нападе ботом. Филтер би могао бити постављен у /etc/fail2ban/filter.d/wordpress.conf:
[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =И одговарајући затвор у jail.local:
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 3
bantime = 3600Иста идеја важи и за изложене базе података (нешто што је генерално најбоље избегавати): ако желите да заштитите MySQL од континуираних неуспелих покушаја приступа, можете креирати филтер за Поруке „Приступ одбијен за корисника“ у дневнику грешака:
[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =А онда затвор:
[mysqld-auth]
enabled = true
filter = mysql
logpath = /var/log/mysql/error.log
maxretry = 5
bantime = 1800На хостинг серверима са контролним панелима cPanel или PleskFail2ban се такође добро интегрише: може да прати поштанске сервисе, Apache, FTP, па чак и саму контролну таблу, блокирајући IP адресе које прекорачују дозвољену границу покушајима пријаве.
Аутентификација помоћу SSH кључева: крај напада лозинком
Све горе наведено помаже, али прави скок у квалитету долази када се ви одлучите Престаните да користите лозинке за SSH и пређите на јавне/приватне кључевеУ том тренутку, напади грубом силом на лозинку престају да имају смисла.
Идеја је једноставна: сваки легитимни корисник има пар кључева, приватни кључ који остаје на вашем уређају и јавни кључ који се копира на сервер у одговарајућој корисничкој датотеци ~/.ssh/authorized_keys.
Када се клијент повеже, он не шаље приватни кључ; он шаље јавни кључ, а затим потписује изазов сервера са приватним. Сервер проверава тај потпис у односу на јавни и само ако се подударају, дозвољава приступ.
Зашто SSH кључеви поништавају грубу силу лозинке
У класичној шеми лозинки, нападач једноставно мора да испробава низове текста док се један не подудара са сачуваном лозинком (или њеним хешем). Иако добра лозинка има много могућих комбинација, Говоримо о редовима величине као што је 10¹⁰ могућности за просечне лозинке.
Типичан 256-битни SSH кључ (као они у Ed25519) креће се у просторима претраге редоследом 10⁶¹⁷ комбинацијаУ пракси, математички је немогуће да нападач погоди приватни кључ грубом силом помоћу модерних рачунара.
Али штавише, сервер чак ни не покушава да израчуна било шта ако Приказани јавни кључ није у authorized_keysУ том случају, прекида везу готово одмах, без позивања PAM-а или традиционалних процеса аутентификације, тако да је потрошња процесора током масовног напада минимална.
Генеришите и верификујте SSH кључеве на клијенту
Пре него што приступите серверу, проверите да ли ваш рачунар већ има генерисан SSH пар кључева. Једноставно наведите садржај ~/.ssh датотеке:
ls -l ~/.sshАко видите датотеке попут id_ed25519 и id_ed25519.pub Ако користите id_rsa и id_rsa.pub, већ имате важећи пар. Ed25519 је модернији и лакши, тако да је обично најбоља опција ових дана.
Ако немате кључеве, генеришите нове помоћу:
ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"Команда ће креирати две датотеке:
- id_ed25519: приватни кључ, који никада не би требало да делите.
- ид_ед25519.пуб: јавни кључ, који можете копирати на сервере.
Садржај јавног кључа можете видети помоћу:
cat ~/.ssh/id_ed25519.pubКопирајте јавни кључ на сервер и тестирајте приступ
На серверу, уверите се да постоји директоријум ~/.ssh за корисника под којим ћете се пријављивати (на пример, git или ваш администраторски корисник) и да је дозволе 700:
mkdir -p ~/.ssh
chmod 700 ~/.sshЗатим додајте садржај датотеке id_ed25519.pub вашег клијента у ~/.ссх/аутхоризед_кеис (креирање датотеке ако не постоји) и давање овлашћења 600:
echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysНе заборавите да замените YOUR_PUBLIC_KEY комплетним редом који сте видели користећи `cat` на вашем рачунару. Одатле можете тестирати везу експлицитним навођењем кључа ако желите.
ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDORАко је све у реду, Сервер неће тражити лозинку и директно ћете прећи на командну линију.У том тренутку сте спремни да размислите о онемогућавању аутентификације лозинком.
Потпуно онемогућите аутентификацију лозинком на серверу
Када проверите да можете да приступите свом налогу помоћу лозинке са барем једног уређаја (идеално два, у случају да изгубите један), добра је идеја Онемогућите пријаву лозинком за SSHОво сасеца у корену сваки покушај класичне грубе силе.
Пре него што се додирнемо конфигурације, добра је идеја да видимо које датотеке дефинишу PasswordAuthentication, јер у многим модерним инсталацијама Постоје .d датотеке које преписују вредност главне sshd_config датотеке:
sudo grep -R "PasswordAuthentication" /etc/ssh/Уобичајено је пронаћи нешто попут:
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication noУ том случају, ефективна конфигурација ће бити „да“ јер се датотека 50-cloud-init.conf учитава накнадно и преписује вредност. Можете проверити коначни резултат који sshd примењује помоћу:
sudo sshd -T | grep passwordauthenticationДа бисте онемогућили праве лозинке, уредите одговорну датотеку (на пример /etc/ssh/sshd_config.d/50-cloud-init.conf) и оставите:
PasswordAuthentication noЗатим поново покрените SSH сервис:
sudo systemctl restart sshИ још једном проверите са:
sudo sshd -T | grep passwordauthenticationАко врати „не“, Покушаји пријаве лозинком биће одмах одбијениПрограми попут PuTTY-а ће приказати грешку јер не могу да обезбеде акредитиве типа лозинке, али ће ваши клијенти са кључевима наставити да функционишу без проблема.
Комбиновање SSH кључева са Fail2ban-ом и другим мерама
Када уклоните PasswordAuthentication из једначине, вредност Fail2ban за SSH постаје кориснија него критична, јер Ботови чак немају ни поље за унос лозинке.Упркос томе, препоручљиво је да sshd jail буде активан јер служи као додатни слој против необичних покушаја других врста или злоупотребе кључева.
Ако ова комбинација Само SSH кључеви + Fail2ban + root закључавање + фино подешене листе AllowUsers/AllowGroups Додајте рестриктивни заштитни зид (iptables/nftables, UFW, firewalld) и, ако је потребно, листе контроле приступа са TCP Wrappers-има, и смањићете вероватноћу грубе силе упада на занемарљив ниво.
У још осетљивијим окружењима, можете ићи корак даље и увести двофакторска аутентификација (2FA) за SSHкоришћење модула попут Google Authenticator-а или сличних путем PAM-а, или чак ограничавање ко може да приступи SSH порту коришћењем наменских VPN-ова.
Са свим овим елементима добро интегрисаним - детекцијом логова, пажљивом sshd конфигурацијом, широком употребом Fail2ban-а, SSH кључевима уместо лозинки и, када је потребно, IP контролама - Linux сервер може да обради континуирани напади грубом силом на SSH и друге изложене сервисеуз одржавање практичног и безбедног приступа за администраторе.