mirror of
https://github.com/konstruktoid/hardening.git
synced 2026-04-27 09:45:54 +03:00
[GH-ISSUE #80] Remove NTP #39
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @disrupttheflow on GitHub (Jul 11, 2020).
Original GitHub issue: https://github.com/konstruktoid/hardening/issues/80
NTP is both an ancient and insecure protoocol.The protcol itself can be abused and cause much bigger replies than expected,thus crashing the system.This is known as an amplification attack.MOre n this here https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html and http://netpatterns.blogspot.de/2016/01/the-rising-sophistication-of-network.html
An attacker can exploit flaws in the protocol and gain access into the system.The unencrypted and unauthenticated nature of NTP makes this attack very easy. for network adversaries.More info https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html and https://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html.
NTP can leak host time and expose the system tyo attacks described here https://www.whonix.org/wiki/Time_Attacks.More M0re here https://trac.torproject.org/projects/tor/ticket/16659#comment:13.
\Its best fo the uses that is seek9ng high-lvel security to follow this https://www.whonix.org/wiki/Time_Attacks#GNU.2FLinux_Host.
The only two nice alternatives to NTP clients is sdwdate by Whonix or this
DO NOT use NTPsec as it is also not secure aand even its devs say so.More steps can be taken for time hardening.
@konstruktoid commented on GitHub (Jul 13, 2020):
Hi @disrupttheflow and thanks for the issue. Hopefully there's been some updates since 2016 but the the list of vulnerabilities at https://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html isn't acually that bad, have a look at https://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-585/Openbsd-Openssh.html for example. Not an excuse, but all software got bugs.
Removing NTP might make sense if you're using a system in risk of Advanced Deanonymization Attacks (https://www.whonix.org/wiki/Advanced_Deanonymization_Attacks) which applies to TOR and similiar systems.
The script does apply all Whonix suggested solutions except disabling systemd-timesyncd (it doesn't add NTP if it's not present) and it doesn't add the tirdad a kernel module.
However NTP or similiar services are required when following various standards, e.g http://static.open-scap.org/ssg-guides/ssg-ubuntu1804-guide-anssi_np_nt28_high.html#xccdf_org.ssgproject.content_group_ntp
I suggest that you follow the Whonix instructions when using anonymization software, otherwise use a time service; logs needs to accurate.
@disrupttheflow commented on GitHub (Jul 13, 2020):
Just looking at cvedetails.com is nt a goodresearch.Don't rely on it alone.
NTP protocol is not only vulnerbale to deanonymization attacks.But also vulnerable to other atacks such as RCE as noted in the links i provided,so it is dangerous for the user's security.
It should tbh.And mentioning NTP pools should in fact be removed.As for the tirdad module.Could be added in the script.
Alternatives can be used as NTP is flawed.Links in original message prove it.Also you can just Google it and find reviews and audits by security experts.
Again this is not a deanonymization issue.
@konstruktoid commented on GitHub (Jul 13, 2020):
I'm not, but the two links you included is from 2014 and 2016, and then you linked cvedetails.com.
Do you have any information regarding that, that is not 5 or 6 years old?
And why is mentioning NTP pools a bad thing?
swdatealso uses pools.There doesn't seem to be any official Ubuntu packages available?
I'm looking forward to reviewing the PR though.
Define flawed.
And why
swdateand not for exampletlsdate(https://linux-audit.com/tlsdate-the-secure-alternative-for-ntpd-ntpdate-and-rdate/)?@disrupttheflow commented on GitHub (Jul 13, 2020):
Yeah.Not ust cvedetails.
Well all those still apply.I mean NTP is stll unauthenticated and unencrypted.The cvedetails link i provided rove how vulnerable the software actually is.NTP is under constant reviews and audits and security experts do not recommend it for security.Here is a good read https://blog.apnic.net/2019/11/08/network-time-security-new-ntp-authentication-mechanism/.Also this is an audit of NTP and NTPsec https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Antp&cpe_product=cpe%3A%2F%3A%3Antp https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Antpsec&cpe_product=cpe%3A%2F%3A%3Antpsec.And Chrony was proven to be a better implementation https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Atuxfamily&cpe_product=cpe%3A%2F%3A%3Achrony
Also a good read https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
Another https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23687166
Because users would immediately think of NTP.
Only provided by Whonix.Needs another maintainer.
I already provided links.
Not saying sdwdate only.sdwdate requires Tor and that might not be the best option for some.This could be good https://gitlab.com/madaidan/secure-time-sync.Or just use no tool and fix time manually.tlsdate had some flaws and it it now unmaintained afaik.l
@konstruktoid commented on GitHub (Jul 13, 2020):
That last link is basically
curl -sI --tlsv1.2 --proto =https https://duckduckgo.com | grep -o '^date:\s.*' | sed 's/^date: //g',so this discussion boils down to:
sudo timedatectl set-ntp 0. But then we need an alternative since a correct date is kind of important,chrony? https://chrony.tuxfamily.org/comparison.htmlIf using chrony, we're still using NTP but the client software is safer? Is that acceptable?
Why not just purge the ntp client and let systemd handle everything with its SNTP implementaion?
Disable TCP timestamps via kernel sysctl. Already done at https://github.com/konstruktoid/hardening/blob/master/misc/sysctl.conf#L78
Block incoming ICMP messages and any other incoming traffic with iptables or any of its frontends, such as ufw. Already done in https://github.com/konstruktoid/hardening/blob/master/scripts/02_ufw
TCP Initial Sequence Numbers mitigation. Not applied since it's not really available on Ubuntu.
Application-level mitigation. For application-level leak mitigation, avoid sending any clearnet traffic but we can't really configure every client so it's not applicable.
Rename NTPSERVERPOOL to TIMESERVERPOOL? But
systemdstill got it, https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html,chronyis a NTP client and so on.TL;DR: are we looking for a NTP replacement or a NTP client replacement?
@konstruktoid commented on GitHub (Jul 13, 2020):
https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity#Detailed_Description
@disrupttheflow commented on GitHub (Jul 18, 2020):
No i say not chrony.
No.NTP is the problem.
Nice.
Nice
So?A script that builds tirdad from source is ok.
Yeah thats up to the user.
NTP is insecure.Not the client.
NTP replacement.Removal actually.
@disrupttheflow commented on GitHub (Jul 18, 2020):
Limited to packets and still doesnt do much.
@konstruktoid commented on GitHub (Sep 2, 2020):
Hi again @disrupttheflow, thanks for opening this issue and the following discussion.
I won't disable NTP, if someone feels the need to do so they'll
sudo timedatectl set-ntp 0and find an appropriate solution.Correct time stamping and time sync is required for useful logging.
@konstruktoid commented on GitHub (Oct 2, 2020):
https://github.com/konstruktoid/tymely