Ahoj. Díky za článek.
Nedávno tady k tomu byla zprávička s dlouhou, lehce offtopic, diskuzí.
Ještě by se hodilo přidat, jak to vypnout, pro ty, kteří to dál chtějí řešit třeba tím Fail2banem nebo firewallem. A do výčtu dalších možností ochrany možná zmínit "port knocking".
Mě v tom konceptu trochu neladí narušování principu Unixovského/Linuxového vrstvení funkcionality, kdy se má aplikace soustředit na svou úlohu a ty ostatní nechat na jiné aplikaci, ale proti vkusu, žádný dišputát.
Vsak samotna aplikace nejlip vi, co je a co neni z jejiho pohledu spravne, ne? ;-) Vse ostatni jsou spise work-aroundy na veci, co aplikace (driv) nezvladla. Mimoto to jiste unixove vrstveni je videt krom jineho i ze clanku a naopak se to zlepsilo - sshd se postupne rozdeluje... a veci kolem pripojeni nyni nove obhospodaruje sshd-session
, coz prislo prave s verzi 9.8 a kde samotny sshd je uz jen listener...
Jako že to teď bude fungovat podobně jako tcpsvd ( https://smarden.org/ipsvd/tcpsvd.8 )?
RE: ...samotna aplikace nejlip vi, co je a co neni z jejiho pohledu spravne:
Nebyl bych si tak jistý. IMHO záleží na úhlu pohledu.
Např. to že někdo skenuje porty a hledá SSHD službu, o tom aplikace nic neví ani na to neumí reagovat.
Nebo v případě, že bude z jedné veřejce port forwardovaných několik desítek SSHD služeb, tak může být výhodnější řešit ta pravidla centrálně.
Každopádně, když už si dal někdo tu práci a implementoval tam další volitelnou vrstvu zabezpečení, tak je tam, a ať ji využije, každý jak potřebuje. Snad je ta implementace dostatečně robustní a izolovaná, aby to necinklo o některý z Murphyho zákonů.
Mít možnosti základního rate-limitu/ blokování přímo v základní komponentě v základním systému mi dává smysl, zvlášť když za tím stojí lidi z OpenBSD.
Bohužel mají nftables poměrně těžkopádné rozhraní, aby se to šikovně rozšiřovalo z nějakého vysokoúrovňového jazyka bez mezivrstev a rozsáhlých knihoven v a pro C. Není mi jasné, proč nemůže volitelně nftables vypisovat, či získávat stav v nějakém příčetném datovém formátu kromě raw socketu ještě třeba přes unix socket nebo rovnou TCP socket. Však by to nemuselo být standardně zapnuté.
Potom by asi bylo i snazší různé přístupy k blokování, rate-limitingu apod. propojit a v nějakém démonu udělat kompletnější obrázek aniž by ta věc běžela víceméně jako root (resp. se kolem toho faktu muselo hackovat dalšími nástroji a frameworky).
Ale samozrejme, ze i ten "scan" v ramci aplikace poznate - jednoduse z toho, ze se neco pripoji a hned odpoji a ani se nepokusi o nejaky handshake. Ostatne to sshd taky zalogovat umi.
A ano, my uzivatele s IPv6 se uz tak netrapime problemy typu "na jedne verejce forwarduji nekolik desitek sluzeb" ;-) Specificky v pripade ssh se pak nabizi otazka, zda-li je fakt nutny mit do internetu vystaveny vsecko - a jestli treba nahodou nestaci jen mit jen jeden jump-host (pripadne dva kvuli redundanci, ale pokud je rec o jedne verejce, tak asi redundanci neresite...). Aneb je to tak trosku i o designu infrastruktury... a smysluplnosti tech "pozadavku". Ono i kdyz se bavime o te unixove filosofii, tak mit to "jednoduche" mimo jine znamena si to prave nezablesit infrastrukturu tim forwardem desitek sshd do sveta na ruznych portech, ze? :-) U toho jednoho jump hostu snaze vyresite i ten hardening... a treba clovek ani nemusi propadnout az tak velke panice, kdyz se najednou objevi dira v implementaci...
A jinak komentovany clanek popisuje i ty defaulty a zminuje jejich velkou konzervativnost. Ale nejde nezminit, ze vyvoj v OpenSSH jde proste spravnym smerem, kdy se funkcionality z jedne vseobjimajici binarky postupne oddeluji. I to dopady tech Murphyho zakonu logicky zmirnuje.
Pokud port knock,tak přivětivý(pro připojeného).ale tto.je subjektivní:
1.browser : http:/dst:5550
2. Browser + logika na serveru (https://dst/add)
3. nc dst 5550; sleep 3 ; nc dst 5558