Kritické chyby v ntpd starším než 4.2.8

To ntpd snad navrhoval kretén. Pustím si ntpd server, aby mi udržoval správný čas, a on si otevře socket trvale poslouchající na portu 123 a baví se s kýmkoli z internetu. Proč to dělá??? Vždyť to k udržování lokálního času vůbec nepotřebuje!

Má se snad bavit jenom se servrama, které má uvedené v konfiguraci, a má zpracovávat jenom odpovědi na dotazy, které sám poslal. Pokud dostane nevyžádaný packet, neměl by na něj reagovat vůbec.

Dá se to nějak rozumně nakonfigurovat, aby to ten socket trvale nedrželo otevřený? Nebo je jediná možnost ntpd smazat a dát si ntpdate do cronu?

Cyba se snad týká jen ntpd - serveru. Ten samozřejmě otevře port a poslouchá požadavky na synchronizaci času.

No ale ked chces na svojom stroji drzat cas synchronizovany, musis si nainstalovat prave ten ntp server. A ten je tak "zvlastne" navrhnuty, ze otvori port na vsetkych sietovych rozhraniach. Dokonca aj ked ho nakonfigurujes, aby pocuval len na jednej z adries, aj tak v netstat vidis, ze port je otvoreny pre vsetky. V syslogu sice ntp pise nieco ako "prestal som pocuvat na rozhrani XY", mozno naozaj vsetky packety odtial zahadzuje, ale aj tak ten port je stale otvoreny.
Druha vec je, co spominal potex: Aj ked si nakonfigurujem ntp server, aby len synchronizoval cas z netu (ale nikde dalej ho neposkytoval, teda len na lokalne udrziavanie casu), aj tak stale pocuva na porte 123. Tiez som nikdy nerozumel, preco je to urobene takto...

Stacit by melo omezeni pristupu v konfiguraci ntpd(Debian i Centos maji):
restrict 127.0.0.1
restrict ::1

Nebo:

http://www.openntpd.org/

IMHO to nestaci. Za prve tym co si uviedol len povolis, ze lokalny uzivatel moze kontrolovat ntp server. Na obmedzenie sluzia ine nastavenia v ntp.conf - a tie tiez su standardne. V Debiane je to takto:
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

Ale aj ak bezis s ntpd len ako s klientom (neposkytuje cas inym strojom, len sam seba synchronizuje s casom z netu), tak pocuva na UDP porte 123. A ked synchronizuje cas (napriklad pri svojom starte), tak posiela poziadavku zo svojho portu 123 na port 123 vzdialeneho servera - a odpoved takisto ide z portu 123 na port 123. Ak neveris, over si to prakticky, tie "restrict" nastavenia mozes mat a aj tak uvidis pakety z portu 123 na port 123 (oboma smermi).

A ak si utocnik pocka na to, az tvoj ntpd posle request do netu a potom zacne komunikovat s tvojim UDP portom 123, tak ti to pusti aj tvoj stavovy firewall (obvykle tam byva pravidlo ESTABLISHED,RE­LATED) pretoze to bude vyzerat ako odpoved na vyzvu tvojho ntpd...

Nikdy som sa nepozeral na detaily, preco je to urobene prave takto, ale tento sposob komunikacie (zdrojovy port je vzdy 123) sa mi vzdy zdal velmi podozrivy, az hlupy. Pokial si pamaam, jedna zo zranitelnosti DNS servera BIND bola v tom, ze sa dali predvidat zdrojove porty ziadosti (myslim, ze boli sekvencne) a potom sa dala otravit cache DNS. Tam to okrem ineho vyriesili aj randomizovanim zdrojovych portov, takze sa nedaju predvidat. A ntpd komunikuje VZDY len cez port 123... oni sice riesia autenticitu vzdialeneho servera cez kryptograficky podpis (aby sa nedala lahko podvrhnut falosna odpoved), ale podla popisu tato zranitelnost suvisi prave s tym podpisom! Respektive tych zranitelnosti je viac, jedna je o tom, ze ntp-keygen generuje slabe kluce...

Nastastie bezny clovek tie podpisy pravdepodobne nema nastavene pretoze v standardnej konfiguracii nie su zapnute (inak dokumentacia k ntpd sa mi vzdy zdala nejaka divna a mal som vzdy problem sa z toho vysomarit, ti ludia maju nejake zvlastne uvazovanie). To je jeden dovod preco nepanikarit. Druhy je, ze v Debiane je to medzicasom uz opravene. No a v Debiane tiez bezi ntpd pod specialnym neprivilegovanym uzivatelom ntp.

Ano, mate pravdu, "restricted" na tuto chybu nestaci.

no tak opet, nabubrely kod, kdyz se lidi z openbsd projektu snazili vytvorit projekt na audit ntpd tak je lidi od ntpd ignorovali. takze theo rekl henningovi at napise maleho privsep ntp daemona s funkcemi, ktere uspokoji 98 % uzivatelu. a tak se stalo a openbsd ntpd nebyl nachylny nekterym poslednim zavaznych ntpd chybam.