All users...
We were hit hard by this attack yesterday on our Thirdlane MTE. It took up all the inbound and outbound bandwidth on our Fiber Connection. (40 mbs up and down). Never have seen a NTP attack before but below is a announcement by another software providers email to users that might help us on some of the Thirdlane products...and a vulnerability that needs to be addressed.
11
February 2014
IMPORTANT SECURITY MESSAGE
We have become aware of a security issue with the NTP Server
used by our products and we must advise our users to modify your configuration files as soon as possible in order to avoid potential attacks.
NTP, or Network Time Protocol, is used to sync the time between a client and the server. It is a UDP protocol and runs on port 123. In an NTP reflection attack, the attacker sends a crafted packet which requests a large amount of data to be sent to the host.
In this case, the attackers are taking advantage of the monlist command. Monlist is a remote command in older versions of NTP that sends the requester a list of the last 600 hosts who have connected to that server. For attackers, the monlist query is a great reconnaissance tool. For a localized NTP server, it can help to build a network profile. However, as a DDoS tool, it is even better because a small query can redirect megabytes worth of traffic.
The following procedure will prevent the attacker from utilizing the security bug in the NTP server:
• If you have a SERVERware, these changes must be made on every running instance.
• If you have PBXware running on a dedicated server, you must perform this procedure on each PBXware.
1. Login to your SERVERware/PBXware
2. Edit /etc/ntp.conf
nano /etc/ntp.conf
3. Insert these lines to your ntp.conf
restrict default kod nomodify notrap nopeer no query
restrict 127.0.0.1
disable monitor
4. Save the changes and restart ntpd
/etc/init.d/ntpd stop
killall ntpd
/etc/init.d/ntpd start
This will solve the security issue with NTP server.
You may also reference the Common Vulnerabilities and Exposures (CVE) website or the National Vulnerability Database website for more information and support.
Watch out, I didn't expect this attack and it took down everything on the network around the TL MTE...
Greg
TL MTE
yeah all of our 3rd lane
yeah all of our 3rd lane boxes loaded from ISO had this in the conf file
driftfile /var/lib/ntp/drift
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 127.127.1.0
fudge 127.127.1.0 stratum 10
I pulled a better config file from one of our other Linux servers
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1
# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
#broadcast 192.168.1.255 key 42 # broadcast server
#broadcastclient # broadcast client
#broadcast 224.0.1.1 key 42 # multicast server
#multicastclient 224.0.1.1 # multicast client
#manycastserver 239.255.254.254 # manycast server
#manycastclient 239.255.254.254 key 42 # manycast client
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift
# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys
# Specify the key identifiers which are trusted.
#trustedkey 4 8 42
# Specify the key identifier to use with the ntpdc utility.
#requestkey 8
# Specify the key identifier to use with the ntpq utility.
#controlkey 8
Given the important nature of
This post was removed because it violates our posting guidelines about advertising
This problem only affects
This problem only affects servers where UDP or TCP port 123 is open to the world.
The standard Thirdlane firewall configuration has these ports closed so NTP service (used internally) is not affected by the external attack as it does not respond to any external requests. If for some reason your port 123 is open, the problem is likely to include an attack attempting to exploit this ( regardless of the NTP server configuration). So the best option is to keep the port closed to discourage the attackers, and if for any reasons you want the port 123 open, then you have to modify the configuration to disable the commands that are typically used by the attackers.
It is our understanding that the Bicom recommendations above were issued in response to problems on Bicom installations which do not follow what we consider to be proper firewall configuration, have NTP and other ports open, and are a likely subject for various attacks on unprotected servers.
We recommend you follow these general security guidelines:
1. Keep all the ports that are not open by default closed. We recommend that for maximum security, you use your PBX server only as a PBX, and do not run other services on it that are not enabled by default.
2. If for any reason you must run NTP or similar services, then you should configure them to disable any features that are typically exploited by attackers, per the latest security guidelines available. In the case of NTP, this would mean using it in client mode only and using the latest recommended settings to help prevent DDOS amplification or other attacks.
3. Install and use the latest update for your product that is available from Thirdlane. We include security patches as part of our regular set of updates, including patches for Linux and Asterisk.
4. We don’t recommend relying on third-party software vendors such as Bicom for security information, since our software is quite different and may not have the same packages and vulnerabilities. Instead, there are a number of authorities that regularly distribute information about known bugs and attacks on Linux and other network components, such as http://www.us-cert.gov/ and https://lwn.net/Alerts/CentOS/. For NTP specific security notices and recommendations please refer to http://www.ntp.org/
If you have any questions about whether your Thirdlane system is subject to a specific new attack and if it is covered by a Thirdlane product update, please ask us.
Hey Greg,
Thanks for looking out for everyone. I'm really sorry to hear that the hackers got to you before you could apply these changes. We are now safe from the attack.