ntpsec

Debian GNU/Linux

Sziasztok,

 

még nem teljesen értem. De! O.K. hogy a régi ntpd nem volt jó mert nem volt secure meg gonoszkodtak vele és most van ez a modern ntpsec. De! Van olyan régi cuccom ami régi ntpd-t használ és az új szerverrel nem tud syncelni. Gondolom kapja a KOD üzeneteket.

Tehát ha jókl értem, tartom a tempót, követem a trendet, frissítek, secure vagyok de a régi cuccom már nem tud hozzám syncelni? Fenn kell tartanom a régi cuccomnak egy régi ntpd-t vagy kiengedni a netre? APROPOS! A netes NTP serverek, hogy vannak beállítva, hogy felülről kompatibilisek maradnak?

 

-------cut here----------

# Default: elutasít mindenkit (KOD is)
restrict default kod nomodify notrap nopeer noquery

# Localhost always ok
restrict 127.0.0.1

# LAN networks allowed
restrict 172.16.0.0 mask 255.255.0.0 nomodify notrap

--------cut here--------

 

mondjuk. kb. ilyen. Valaki tud esetleg egy jobb configot, vagy stratégiát?

thx

  • 821 megtekintés

( bennyh | 2025. 09. 25., cs – 11:25 )

Én amúgy se szeretem, hogy egy IoT eszközöm kifelé nézegessen (majd én nézegetem őket VPN-en), legfeljebb frissítésekért, de azt is inkább csak kézzel indítva. Egy helyi NTP szerver meg csak egy plusz szolgáltatás egy értelmesebb routeren, annyira nem fáj se fenntartani se eltéríteni felé az NTP forgalmat.

nálam is ez az alap, ~mindent a ruter biztosít befelé:

NTP,  DNS, DHCP, de igény esetén HTTP Proxyt is.

így a belső kliensek - főként az IoT vackok - egyátalán nem akarnak (és nem is tudnak) direktbe netet elérni.

 

A saját belső hálózatomon meg nem érzem szükségét a DNS, NTP forgalom tikosításának, és az áltlam használt OpenWRT, pfSense sem erőlteti  - egyelőre..

zrubi.hu

( ricsip v | 2025. 09. 25., cs – 12:07 )

Good to know! Mikortól lesz kötelező?

öööö. tulajdonképp én most szembesültem vele, ez egy aktuális Debian

---------- cut here--------

# apt-cache search ntpd
collectd-core - statistics collection and monitoring daemon (core system)
cyrus-nntpd - Cyrus mail system - NNTP support
hobbit-plugins - plugins for the Xymon network monitor
htpdate - HTTP based time synchronization tool
jamnntpd - NNTP Server allowing newsreaders to access a JAM messagebase
ntpdate - Network Time Protocol client (transitional package)
ntpsec-doc - Network Time Protocol documentation
ntpsec-ntpdate - client for setting system time from NTP servers
ntpsec-ntpdig - ntpdig SNTP client
sntp - Network Time Protocol client (transitional package)
ntpstat - show network time protocol (ntp) status
openntpd - OpenBSD NTP daemon
root@clserv:/etc/ntpsec# dpkg -l | grep ntpd
ii  ntpdate                           1:4.2.8p15+dfsg-2~1.2.2+dfsg1-1+deb12u1      all          Network Time Protocol client (transitional package)
ii  ntpsec-ntpdate                    1.2.2+dfsg1-1+deb12u1                        amd64        client for setting system time from NTP servers
ii  ntpsec-ntpdig                     1.2.2+dfsg1-1+deb12u1                        amd64        ntpdig SNTP client

-------- cut here ----------

Ezt a kört megfutottam fél éve. Legalább 3 félre irányt kipróbáltam.

A feltételeim azok voltak, hogy tudjon DHCP-ből NTP szerver címet fogadni. Könnyen lehessen felülbírálni statikusan, custom fájllal etethető a config, amit sosem ír felül. Ne legyen extra függősége.

Végül ez vált be, ha már úgy is fent van az alapja:

systemd-timesyncd                  247.3-7+deb11u7                                                 amd64        minimalistic service to synchronize local time with NTP servers

Ilyen okosságok vannak benne:

https://wiki.archlinux.org/title/Systemd-timesyncd

Ahh nekem ez nem jó. én azt akarom, hogy a hálózatomban legyen egy általam kijelölt Time Server a vezérürü és a többi csak őt kérdezgeti, netre nem jut ki.

 

"

  • systemd-timesyncd alapból NEM NTP szerver, csak time client.

  • Tehát más gépek nem tudnak róla szinkronizálni, csak ő szinkronizál más NTP szerverek felé.

"

Arch-on én már régóta azt az ntp csomagot használom, ami tud openssl-t használni, magyarul tud titkosítást. Ennek ellenére tuti lehet vele titkosítatlan időszerverekhez is csatlakozni.

Szerk.: látom megoldottam az openntpd felrakásával. Én egyébként nem vagyok ellene, hogy az NTP is secure protokoll legyen, nem cserél sok adatot, nem tologatja őket túl sűrűn, ennyibe még egy gyenge retró gépen is belefér, hogy használ titkosítást.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

"ennyibe még egy gyenge retró gépen is belefér, hogy használ titkosítást"

Igen, de pont ez szokta a gondot okozni. ~2 évente jön egy ssl mizéria, ahol too weak hibaüzenettel berinyál valamelyik fél.

Jellemzően OpenVPN-nel szívok, ahol vagy a szerver cert túl régi és az új kliensek nem hajlandók csatlakozni vagy a szerver túl új és a régi kliensek nem ismerik az új SSL-t. Jelen példánál maradva most épp CA certje too weak...
Lehet lecserélni mindenhol, de sok vékony kliens van, amik szinte tuti, hogy nem fogják ismerni a legújabb OpenVPN által megkövetelt biztonsági szinteket.
Aztán lehet a közös nevezőt keresni. OpenVPN-nél még oké, ez az alapja. De számtalan protokoll van, főleg belső hálón, ahol azért annyira tűnik indokoltnak.

Jaja, ez az SSL / TLS cert-esdi nagy seggfájás tud lenni. Kripto-kat kiszedegetnek h. már ez se szekjúr, az se szekjúr, minden hónaoban új key exchange protokollt vezetbek be, már az SHA2 se jó, az SHA3-nak se szavazok sok évet. A kulcsok 4096 bitesek már a CA-knál, aztán van (régi) kliens ami már a 2048-as kulcsokra is beszarik. 

Mi főleg Java oldalon szívunk ezzel, értem Béla, hogy nem szekúr, mondom akkor a telefonszámokat, hogy hol kellene ezt előadni, de légyszi addig igenis kapcsolódj a kicsűrt szerverhez, mert nem nagyon van ráhatásom, hogy ez szekúr legyen. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( muszi v | 2025. 09. 25., cs – 13:39 )

Kipróbáltam, nekem működik.

Szerver: Debian 12, ntpd ntpsec-1.2.2

Konfig:

server -4 time.xxx.hu iburst

disable stats

driftfile /var/lib/ntpsec/ntp.drift

restrict 127.0.0.1
restrict default kod limited nomodify noquery

 

Kliens: Debian 6, ntpd Ver. 4.2.6p2 (2015 októberi a bináris)

Konfig:

server debian12.xxx.hu

disable auth stats

driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntpd.log

restrict default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*198.51.100.149    192.0.2.1      4 u   78  128  377    0.205   -0.004   0.014

ott kezdődik, hogy nekem a socketet sem nyitotta meg ezért ntpq -p nem is ment csak netesscocketen keresztül, pl. ntpq -p 127.0.0.1 na de ez mindegy is. ami nekem fájt az az, hogy restrict-tel beengedem local LAN-t és a local lanon lévő régi típusú szerver amelyik ntpd-t használ, na az amikor kérdezgette, csak KOD-ot kapott és nem tudott ide syncelni. hmmm. lehet nekifutok mégegyszer. Ez egy DELL EMC Unisphere és nem tetszett neki: 

Logid (00000fc3) continued, ErrorMessage='Failed to get NTP time data from given server: 192.168.10.106#012' ErrorEncodedMsg='{args":[]

szóval majd holnap újra maszírozom, hátha valamit elnéztem.

( ez van az EMC-n:  ntpd 4.2.8p10-a (1): Starting)