[SOLVED]NTP not working

Hugovsky

I think I have a problem with NTP service. Seems not to be working maybe arround 27th December onward. I tried everything I can remember and can't make it work. I've attached a pic of ntp status page. No special config except I've selected only 3 interfaces. But it was already running that way a long time ago. No errors in log. Any ideas?

Jan 20 00:07:53 	ntpd 	58466 	Listening on routing socket on fd #34 for interface updates
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 13 igb2.600 192.168.54.1:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 12 igb2.600 [fe80::ec4:7aff:fe6a:bc5a%15]:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 11 igb1.500 192.168.53.1:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 10 igb1.500 [fe80::ec4:7aff:fe6a:bc59%13]:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 9 igb1.400 192.168.52.1:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 8 igb1.400 [fe80::ec4:7aff:fe6a:bc59%12]:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 7 igb1.3 10.10.10.2:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 6 igb1.3 10.10.10.1:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 5 igb1.3 192.168.50.1:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 4 igb1.3 [fe80::ec4:7aff:fe6a:bc59%11]:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 3 igb1.120 10.1.2.1:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 2 igb1.120 [fe80::ec4:7aff:fe6a:bc59%9]:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 1 lo0 127.0.0.1:123
Jan 20 00:07:53 	ntpd 	58466 	Listen normally on 0 lo0 [::1]:123
Jan 20 00:07:53 	ntpd 	58466 	proto: precision = 0.190 usec (-22)
Jan 20 00:07:53 	ntpd 	58181 	Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Jan 20 00:07:53 	ntpd 	58181 	ntpd 4.2.8p10@1.3728-o Mon Apr 3 21:03:28 UTC 2017 (1): Starting 
```![ntp.jpg](/public/_imported_attachments_/1/ntp.jpg)
![ntp.jpg_thumb](/public/_imported_attachments_/1/ntp.jpg_thumb)

Hugovsky

Details:

SM A1SRi 2558 with 16GB

2.4.3-DEVELOPMENT (amd64)
built on Wed Jan 17 16:06:08 CST 2018
FreeBSD 11.1-RELEASE-p6

freeradius3 0.15.3
haproxy 0.54_2
pfBlockerNG 2.1.2_2
suricata 4.0.3_1

Hugovsky

Found it! Suricata was blocking it. Sorry to waste your time. All is good now.

bmeeks

@Hugovsky:

Found it! Suricata was blocking it. Sorry to waste your time. All is good now.

Suricata would not normally block NTP. About the only valid reason I could imagine for it blocking NTP would be if the destination server's address was on one of the IP blacklists in a couple of the Emerging Threats rules categories. What NTP peer host is it blocking? Also, which rule (GID:SID) is generating the block? It's also possible there might be an error in a rule that is now causing a false positive, but something like that should show up fast on the mailing lists for the ET rules or other IDS/IPS rules.

Bill

Hugovsky

Hi bmeeks. I don't use any rule from emerging threats. From a few updates back, I had to enable ntp on wan so it talk to ntp servers. Since then, my ntp peers started to get blocked. I have ntp enabled on all interfaces except one.

I'm only using this rules in custom rules:

drop tcp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023] (msg:"Golden Rule BAD TCP"; classtype:attempted-recon; sid:9900001; rev:1;)
drop udp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023,![53,67,68,500,4500]] (msg:"Golden Rule BAD UDP"; classtype:attempted-recon; sid:9900002; rev:1;)
drop udp $EXTERNAL_NET any -> $HOME_NET [0:1023,![53,500]] (msg:"Golden Rule NO SERVER UDP"; classtype:network-scan; sid:9900003; rev:1;)
drop tcp $EXTERNAL_NET any -> $HOME_NET [0:1023,![21,53,80,443,8080]] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900004; rev:2;)

# Authors: Jayden Zheng (@fuseyjz) and Wei-Chea Ang (@77_6A)
# Company: Countercept
# Website: https://countercept.com
# Twitter: @countercept

alert tcp any any -> $HOME_NET 445 (msg:"DOUBLEPULSAR SMB implant - Unimplemented Trans2 Session Setup Subcommand Request"; flow:to_server, established; content:"|FF|SMB|32|"; depth:5; offset:4; content:"|0E 00|"; distance:56; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618009; classtype:attempted-user; rev:1;)
alert tcp $HOME_NET 445 -> any any (msg:"DOUBLEPULSAR SMB implant - Unimplemented Trans2 Session Setup Subcommand - 81 Response"; flow:to_client, established; content:"|FF|SMB|32|"; depth:5; offset:4; content:"|51 00|"; distance:25; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618008; classtype:attempted-user; rev:1;)
alert tcp $HOME_NET 445 -> any any (msg:"DOUBLEPULSAR SMB implant - Unimplemented Trans2 Session Setup Subcommand - 82 Response"; flow:to_client, established; content:"|FF|SMB|32|"; depth:5; offset:4; content:"|52 00|"; distance:25; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618010; classtype:attempted-user; rev:1;)

#forum
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [3389] (msg:"Admin Rule NO SERVER RDP TCP"; classtype:network-scan; sid:990050; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5500] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990052; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5800] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990053; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5900] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990054; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [4899] (msg:"Admin Rule NO SERVER RADMIN TCP"; classtype:network-scan; sid:990055; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [1433] (msg:"Admin Rule NO SERVER MSSQL TCP"; classtype:network-scan; sid:990057; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP TCP"; classtype:network-scan; sid:990059; rev:1;)
drop udp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP UDP"; classtype:attempted-recon; sid:9900060; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [8172] (msg:"Admin Rule NO SERVER IIS TCP"; classtype:network-scan; sid:990061; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [31337] (msg:"Admin Rule NO SERVER Back Orifice TCP"; classtype:network-scan; sid:990063; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [47001] (msg:"Admin Rule NO SERVER WinRM TCP"; classtype:network-scan; sid:990064; rev:1;)

EDIT: Only using WAN interface with suricata. And I do have some internal servers.

bmeeks

I think this rule is blocking your NTP traffic:


drop udp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023,![53,67,68,500,4500]] (msg:"Golden Rule BAD UDP"; classtype:attempted-recon; sid:9900002; rev:1;)

NTP uses UDP by default on port 123. One of your custom rules says to drop any UDP traffic from EXTERNAL_NET on ports 0 through 1023 unless the destination port is in the list of 53, 67, 68, 500 or 4500. NTP traffic would be coming from the EXTERNAL_NET NTP peer host as UDP on port 123. Your custom drop rule is going to block the traffic. You should add port 123 to your list of ports in the NOT (!) brackets. Suricata is indeed blocking your NTP, but it's not a defect. It's because your custom rule told it to… ;)

Bill

Hugovsky

Yes, you're right. I'm not blaming suricata. It's my fault. And intended. I will correct that rule to include ntp. Do you think I should delete the thread so people don't be confused?

bmeeks

@Hugovsky:

Yes, you're right. I'm not blaming suricata. It's my fault. And intended. I will correct that rule to include ntp. Do you think I should delete the thread so people don't be confused?

You can delete it, or leave it with [SOLVED] in the title. Your call. It might prove educational for someone else later.

Bill