DrKK
FreeNAS Generalissimo
- Joined
- Oct 15, 2013
- Messages
- 3,630
Gentlemen:
I don't know how big of an issue this is to you, as most people do not run FreeNAS directly on the WAN, so this is largely moot. (That being said, I know at least a couple of the guys in IRC, for God knows what reason, run their FreeNAS directly on the WAN without an intervening gateway/firewall). (Yes, I've had words with them about this--and no, they don't seem to care).
But, with respect to the network time protocol amplification attack described here (and this is the same attack vector that brought down the IRC network a couple week ago), it appears to be the case that:
ntpd as configured out of the box on FreeNAS will respond to the MONLIST query, and all sorts of other amplifiable queries, and hence would appear to be vulnerable to the NTP amplification attack in the worst possible way. I have verified this by sending ntpq queries of various types, as well as ntpdc monlist queries from a WAN-ingress after temporarily opening up the firewall. This should be patched immediately, since I can't think of any reason why ntpd in a FreeNAS needs to respond to any queries of these type at all.
The OPEN NTP Project describes some queries that are vulnerable (you will see FreeNAS responds fully vulnerable) and has some pointers on how to fix it, but in the case of FreeNAS, I think the right fix would be to adjust the script in /conf/base/etc/ix.rc.d to include the following lines:
If any user goes into their /etc/ntp.conf file, adds those two lines, then restarts the service with:
they will find that their FreeNAS IP, as well as all of the jails that share that stack (obviously) will no longer respond to amplifiable queries. Of course, that's not a final fix for the end-user. If the end user is sophisticated enough to make the change in /etc/ntp.conf, he'll lose it on his next reboot. Even if the user mounts the filesystem writable and makes the appropriate changes in the /conf/base script, they will be lost on the next (frequent! lol) update release.
Anyway, I suggest a fix be committed posthaste. Forgive me if someone else has already pointed this out elsewhere and I missed it.
I don't know how big of an issue this is to you, as most people do not run FreeNAS directly on the WAN, so this is largely moot. (That being said, I know at least a couple of the guys in IRC, for God knows what reason, run their FreeNAS directly on the WAN without an intervening gateway/firewall). (Yes, I've had words with them about this--and no, they don't seem to care).
But, with respect to the network time protocol amplification attack described here (and this is the same attack vector that brought down the IRC network a couple week ago), it appears to be the case that:
ntpd as configured out of the box on FreeNAS will respond to the MONLIST query, and all sorts of other amplifiable queries, and hence would appear to be vulnerable to the NTP amplification attack in the worst possible way. I have verified this by sending ntpq queries of various types, as well as ntpdc monlist queries from a WAN-ingress after temporarily opening up the firewall. This should be patched immediately, since I can't think of any reason why ntpd in a FreeNAS needs to respond to any queries of these type at all.
The OPEN NTP Project describes some queries that are vulnerable (you will see FreeNAS responds fully vulnerable) and has some pointers on how to fix it, but in the case of FreeNAS, I think the right fix would be to adjust the script in /conf/base/etc/ix.rc.d to include the following lines:
Code:
restrict default noquery disable monitor
If any user goes into their /etc/ntp.conf file, adds those two lines, then restarts the service with:
Code:
service ntpd restart
Anyway, I suggest a fix be committed posthaste. Forgive me if someone else has already pointed this out elsewhere and I missed it.
