Fail2ban sa isang VPN gateway: ano ang inaayos at ano ang hindi

Bawat nakalantad na serbisyo ay nakakakuha ng parehong payo: lagyan ito ng fail2ban. Para sa VPN gateway ang payo ay hindi mali at hindi sapat, at ang ituring itong check box sa hardening ang dahilan kung bakit nauuwi ang mga tao sa isang kulungan (jail) na walang binablock na kapaki-pakinabang. Binabasa ng Fail2ban ang mga record ng pagkabigo na itinuro mo at hinihiling sa isang backend ng pagpapatupad na i-block ang mga tugmang pinagmulan. Ang buong halaga nito ay nakadepende sa kung aling authentication surface ang gumawa ng record, kung ang address dito ay ang tunay na kliyente, at ano ang nangyayari sa lahat ng iba sa likod ng address na iyon.

Ano ang fail2ban sa mekanikal na paraan

Ang filter ay tumutugma sa mga linya sa log, ang kulungan ay nagbibilang ng tugma bawat pinagmulan, at ang aksyon ay naglalapat ng pag-block sa pamamagitan ng backend ng firewall. Tatlong gumagalaw na bahagi, at bawat isa ay maaaring mali nang mag-isa.

Wala sa tatlo ang humahawak sa landas ng authentication: ang fail2ban ay tumutugon sa ebidensya pagkatapos ng pangyayari at hindi kailanman nagpapatunay ng kredensyal sa sarili nito. Kaya ang isang kulungan ay maaaring tumakbo nang malinis habang ang surface na pinangalanan nito ay nananatiling eksaktong kasing lantad ng dati.

Ang tagapakinig ng tunnel ay hindi isang login form

Ang tagapakinig na OpenVPN na protektado ng tls-auth o tls-crypt ay nagtatapon ng mga packet na walang proteksyon ng control channel bago magsimula ang normal na pagproseso ng TLS. Ang scanner na hindi kailanman may susi ay walang ginagawang anumang mabibilang ng iyong filter. Ang authentication ng sertipiko ay nagdadagdag ng isa pang gate, dahil walang password na mahuhulaan. Proyektong Fail2ban ay nagdodokumento ng pangkalahatang modelong hinihimok ng log, at ang isang generic na VPN filter ay hindi ginagawang makabuluhang kaganapan ng pagkabigo ang isang hindi na-authenticate na packet.

Kung ang gateway ay tumatanggap lamang ng mga sertipiko, ang kuwento ng brute-force na ipinagtatanggol mo ay maaaring wala talaga sa port na iyon.

Kaya aling surface ang pinoprotektahan mo?

Ang parehong host ay madalas na naglalantad ng tatlong magkakaibang bagay: ang tagapakinig ng tunnel, isang portal ng profile ng kliyente o self-service, at isang pahina ng administrasyon. Ang portal at ang admin page ay may mga form ng password at gumagawa ng mga linya ng log na mabibilang ng filter. Ang tunnel ay maaaring gumawa lamang ng mga error sa handshake na nangangahulugang ibang-iba. Itugma ang kulungan sa surface, hindi sa pangalan ng produkto.

Ang isang kulungan na nanonood ng maling log ay mas masahol pa sa wala, dahil lumilikha ito ng tiwala na walang saklaw. Itutok ang filter ng login sa mga error sa handshake ng tunnel at tutunog ang counter sa mga scanner na hindi kailanman may susi, habang ang pag-atake ng password sa portal ay hindi mabibilang. Basahin ang linya ng log na itinutugma ng filter bago ka magtiwala sa numero ng kulungan.

Ang attribution ng pinagmulan ang mahinang kawing

Ang pag-block ay kasing ganda lamang ng address na pinupuntirya nito. Kapag ang serbisyo ay nasa likod ng lokal na reverse proxy, ang address ng kliyente sa log ay maaaring ang proxy, at ang pag-block nito ay nag-aalis ng lahat. Ang pagtitiwala sa isang forwarded header mula sa hindi mapagkakatiwalaang pinagmulan ay nagbibigay sa isang attacker ng kakayahang mag-block ng mga di-makatwirang address. Sa UDP ang mga source address ay maaaring pekein, kaya ang pagbilang sa kanila ay nangangailangan ng higit na pag-iingat kaysa sa pagbilang ng isang natapos na TCP login.

Itala ang paraan ng attribution ng pinagmulan sa README ng kulungan, dahil ang isang forwarded header mula sa hindi mapagkakatiwalaang hop ay ginagawang armas ang pag-block.

Ang collateral na gastos ay ibang tao

Maraming empleyado sa likod ng isang office NAT ay nagbabahagi ng isang address, kaya ang isang lumang naka-save na password ay maaaring mag-lock ng buong opisina kapag nalampasan ang threshold. Ipinapakita ng log ang isang pinagmulan at isang account na nabigo, hindi isang pagkawala ng serbisyo sa buong opisina.

Ang maiikling pag-block at katamtamang threshold ay nagbabawas niyon, at ang dokumentadong landas ng pag-unban ay nagbabawas ng kargada sa suporta kapag nangyari pa rin ito. Ang address ay isang magaspang na senyales, hindi isang pagkakakilanlan, at ang taong magbubukas ng ticket ay ilalarawan ang pagkawala ng serbisyo, hindi ang threshold.

Kailan ito dapat gamitin, at kailan aayusin ang ibang bagay

Gamitin ito kapag may tunay, maiuugnay, at paulit-ulit na pagkabigo sa online na pag-login sa isang surface na kinokontrol mo, at kapag ang backend ng pagpapatupad ay talagang sumasaklaw sa surface na iyon. Ayusin ang ibang bagay kapag ang problema ay mahinang patakaran sa kredensyal, isang pahina ng pamamahala na nakalantad sa internet, o isang account na matagumpay na nagla-login dahil na-compromise ito. Hindi kayang ayusin ng pag-block ang alinman sa mga iyon, at hindi nito kayang sumipsip ng trapikong nagpuno na sa iyong uplink. Ang huling problemang iyon ay pag-aari ng upstream, ng isang taong makakapag-filter bago pa dumating sa iyo ang mga packet.

Panatilihing nakatali ang bawat kulungan sa isang surface, suriin ang mga false positive, at sukatin ang naipigil na authentication work sa halip na ang bilang ng mga na-block na address.