Jack Wallen walks you through the process of putting in place a temporary fix against SAD DNS for your Linux servers and desktops.
There’s a new DNS cache poisoning threat in town and it goes by the name of Side-channel AttackeD DNS (SAD DNS). This new attack works like so: SAD DNS makes it possible for hackers to reroute traffic destined to a specific domain to a server under their control. With this attack they can easily spy on your traffic. This is a weaponized network side-channel attack with serious security implications for both users and businesses.
This new flaw affects operating systems Linux (kernel 3.18-5.10), Windows Server 2019 (version 1809) and newer, macOS 10.15 and newer, and FreeBSD 12.1.0 and newer.
BlueCat, a software-driven DDI solution, reached out to me about this issue–mostly because the suggested temporary fix of disabling ICMP packets was a bit more nuanced. To that issue, a BlueCat representative said:
“If a DNS server has ICMP blocked completely, zone transfers could fail, if there is a hop with a smaller MTU (blocking ICMP causes PMTUD black hole) between it and the other server.”
BlueCat indicated there would be issues with IPv6 fragmentation.
BlueCat also informed me of a temporary fix for Linux servers and desktops. The fix is in the form of a simple script that can be easily employed. I’ve tested it and it works.
Let me show you how to deploy it to your Linux desktops and servers, so you can avoid problems until DNS server providers resolve the issue.
SEE: Linux service control commands (TechRepublic Premium)
What you’ll need
How to use the script
The script crafted by BlueCat is actually quite simple and looks like:
#!/usr/bin/env bash # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS # OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN # THE SOFTWARE. ########################################################################### # # Three options for installation. Choose one of the following: # # 1. Copy to /etc/cron.minutely # # 2. Copy the script to the DNS server. Create a file in /etc/cron.d with # the following syntax: # # * * * * *root /path/to/icmp_ratelimit.sh >/dev/null 2>&1 # # 3. Create a user cron entry while using `crontab -e` # # * * * * * /path/to/icmp_ratelimit.sh >/dev/null 2>&1 # # - Change "/path/to" to match the exact location of the script. # - Finally, make sure it is executable: chmod +x /path/to/icmp_ratelimit.sh # seconds="60" while [[ ${seconds} -gt 0 ]] do echo $((500 + $RANDOM % 1500)) > /proc/sys/net/ipv4/icmp_ratelimit sleep .95 let seconds=seconds-1 done
Note: BlueCat may be updating the script to include IPv6. Make sure to check their official GitHub page for any further updates to this script.
The script will do exactly what the forthcoming Linux patch will do and randomize the rate limit. To be more specific, according to David Maxwell, software security director at BlueCat:
“The script is roughly equivalent to the Linux kernel change committed Oct. 16. Once per second, it sets a new randomized limit on ICMP responses, between 500-1500/s. It will work on systems with a Linux kernel version 2.4.10 or newer.”
Create this script with the command:
sudo nano /usr/local/bin/icmp_ratelimit.sh
Paste the contents of the script in the new file and save/close the file. Give the file executable permissions with the command:
sudo chmod u+x /usr/local/bin/icmp_ratelimit.sh
With the script ready, let’s now create a cron job to use it. Create a new daily cron script with the command:
sudo /etc/cron.d/icmp_ratelimit
In that file, paste the following:
* * * * * root /path/to/icmp_ratelimit.sh >/dev/null 2>&1
Save and close the file.
Make sure to take care of the above on all of your Linux machines.
That’s all there is to it. Your Linux servers and desktops should be safe from SAD DNS until said time as DNS providers have a permanent fix in place, or the Linux kernel is officially patched against the attack.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.