[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

[ugandy]

I'm seeing similar on 2.4Ghz in my case. The networks still appear using InSSIDer but clients can't connect and work. It needs a full system reboot to get them working again. This happens occasionally, but I can't work out any triggers. Sometimes I have a real game to get things working again as the devices do not reconnect straight away after a simple system reboot and I end up in a world of pain.

i'm stuck on 384.18 because of same problem. was hoping that it would be solved by 386...

 

[tsumeone]

Adaptive QoS working ok here on 100/40.

I have 300/25 and it was topping out at about 120mbps, when I could get the speed test page to actually load anyway. I think the issue may be related to DNS over TLS but I didn't think to test with all of that turned off. I just know it stopped happening when I turned off QoS and it doesn't happen when I use QoS on using the ASUS beta firmware. I also have a different router than you I think - I have the RT-AC68U.

 

[Stoonhea020]

I noticed that since flashing to the 386.1 alpha builds that on the Network Map screen where is shows Internet Status it shows my IP address, which is correct. However, if I turn on the VPN Client (SurfShark) it still shows the same IP address (even after refresh page or log off and back into router) even thought going through the VPN I should and do have a different IP Address. All the Merlin Builds before 386.1 when I turn the VPN on it would show not connected to the Internet (for some reason) and I can't remember if it showed a different IP Address or not. Using the ASUS RT-AC86U Router. Hope I explained so you can understand it. Have attached screen shot to show page I was talking about.

Thanks

I can understand your confusion and to be honest I don't know what your previous builds were showing as value and if the current behavior per design or not, but from my point of view this is something what is to be expected. If you build up a VPN connection you create a secure "tunnel" in which your (encrypted) communication is taking place between you and the destination (VPN server) with the different IP address as you described. However, the connection outside your tunnel is the (public) IP address provided by your ISP. The payload inside your packet that you generate is not regular http/ftp/bt whatever data, but the data from your VPN tunnel (encrypted). So for you as a user it seems you are communicating to the other side like if it was regular traffic with an IP address which can be seen by everyone but in fact you communicate via that encrypted payload send over your outside internet traffic via the IP provided by your ISP.
Simply see it as a networkcable. The connectors and cable itself is your outside connection between client and server and everyone can see that cable (your public IP address given by your ISP) but the wiring inside the cable is the VPN tunnel over which you communicate (which no one can see since it is inside the cable and encrypted with that different IP that you talked about).

 

[BigTim]

I tried to go to the Alpha 3 code a few days ago on the AX58U - read through this thread as well. Didn't go well. FlexQoS did not load. Uninstalled FlexQoS, formatted the JFFS partition. Reinstalled FlexQoS, still didn't work. Tried to revert to old Merlin code (stable release) but router would not install. Had to do a firmware restore and then back to last stable Merlin code, FlexQoS worked fine. Not sure why some are good with the Alpha 3 on the AX58U but my router didn't like it at all.

 

[brummygit]

i'm stuck on 384.18 because of same problem. was hoping that it would be solved by 386...

Out of interest what models are you running?

I have even run my mesh nodes with 5Ghz only and the AX88U for 2.4Ghz + 5Ghz but the 2.4Ghz died eventually. Next test might have to be running the 2.4Ghz only on the AX56U nodes although (non-scientifically) it feels as though both models suffer the same problem.

 

[ugandy]

Out of interest what models are you running?

I have even run my mesh nodes with 5Ghz only and the AX88U for 2.4Ghz + 5Ghz but the 2.4Ghz died eventually. Next test might have to be running the 2.4Ghz only on the AX56U nodes although (non-scientifically) it feels as though both models suffer the same problem.

single AX88.
with 384.19 the 2.4Gz kicks all clients eventually and only a reboot fixes it. 384.18 is fine.
must be triggered by one of my clients, because most people don't have this problem.

 

[brummygit]

single AX88.
with 384.19 the 2.4Gz kicks all clients eventually and only a reboot fixes it. 384.18 is fine.
must be triggered by one of my clients, because most people don't have this problem.

Interesting thought on it being a specific client - I have Nest IQ Cams, Ring Door Chime (doorbell is 5Ghz), Amazon Echos, Raspberry pies, and quite a few IOT things

 

[Wisiwyg]

i'm stuck on 384.18 because of same problem. was hoping that it would be solved by 386...

I'm also holding on 384.18, tried 384.19 multiple times, ended up having disconnect and internet outages, culminating in familly demanding 'fix it'! So now patiently awaiting Merlin alpha 386 on 386.40947 code base when he turns to that. I can wait.

 

[JWoo]

I'm also holding on 384.18, tried 384.19 multiple times, ended up having disconnect and internet outages, culminating in familly demanding 'fix it'! So now patiently awaiting Merlin alpha 386 on 386.40947 code base when he turns to that. I can wait.

Me too! Except I am on 384.17 on my RT-AX58U. Had similar issues with 384.19 with wireless devices. The 386.40947 seemed much improved when I tested it a week back and kicked the tires on it. Like you, I am also waiting patiently for this Merlin build as it should offer the new Asus features, Merlin features + more stable new 386.40947 code base. Cheers and stay safe and healthy!

 

[Wallace_n_Gromit]

CVE-2020-25705 https://www.saddns.net/

I'm trying to wrap my head around this Side Channel vulnerability on DNS and whether or not it affects Asus Routers both stock and Merlin.

The way I understand it, in 2008, DNS Cache poisoning/spoofing vulnerability was discovered. The solution/mitigation at that time was to have [DNS resolver port randomization] which increases entropy enormously and is now standard practice.

This side channel attack on DNS involves using the default global rate limit of outgoing ICMP messages. The attacker cleverly using ICMP error replies breaks the increased entropy of DNS resolver port randomization thus we are back to 2008, DNS Cache poisoning/spoofing vulnerability.

The temporary mitigation is to have Linux computers/servers (That's what a ASUS router is , right?) "...randomize the ICMP global rate limit to introduce noises to the side channel." again increasing the entropy enormously.

This mitigation depends on the linux server/computer (router?) being able and configured to use ICMP as the vector for the side channel attack.

Sooooooo... do Asus routers by default use/respond to ICMP packets? The below link offers a way to randomize the default global rate limit and adding it to crontab.
Will this break something on our ASUS routers?

Hardware | TechRepublic

www.techrepublic.com

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
Access to any Linux machines that use DNS on your network

A user with sudo privileges

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
     echo $((500 + ${RANDOM} % 1500)) > /proc/sys/net/ipv6/icmp_ratelimit
    sleep .95
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 job with the command:

sudo crontab -e
At the bottom of that file, paste the following:

*/10 * * * * flock -xn /root/.icmpratelimit-lock -c /usr/local/bin/icmp_ratelimit.sh
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.

 

[XIII]

NextDNS users should be OK:

https://www.reddit.com/r/nextdns/comments/ju9mpi

 

[Wallace_n_Gromit]

NextDNS users should be OK:

https://www.reddit.com/r/nextdns/comments/ju9mpi

I guess my thinking was that, is this an issue with BOTH the Server-side as well as the Client-side? If ONE side mitigates the error, is that enough? What if in the future (for some reason) you have to change DNS server you use (i.e. from your ISP) and they haven't implemented the solution?

And then finally, would it do any harm to have your Asus Device or any server/computer set up to randomize the ICMP as a future prophylactic/additional security measure against this vulnerabilty?

And the reason for posting this issue in this thread: If it is a legitimate issue with Asus (or any) routers, would it be worthwhile for adding this mitigation as an ongoing feature/radio button in future firmwares?

 

[cooloutac]

I guess my thinking was that, is this an issue with BOTH the Server-side as well as the Client-side? If ONE side mitigates the error, is that enough? What if in the future (for some reason) you have to change DNS server you use (i.e. from your ISP) and they haven't implemented the solution?

And then finally, would it do any harm to have your Asus Device or any server/computer set up to randomize the ICMP as a future prophylactic/additional security measure against this vulnerabilty?

And the reason for posting this issue in this thread: If it is a legitimate issue with Asus (or any) routers, would it be worthwhile for adding this mitigation as an ongoing feature/radio button in future firmwares?

to at least answer your other question, no, asus routers don't respond to icmp by default and ipv6 is disabled.

 

[Wallace_n_Gromit]

to at least answer your other question, no, asus routers don't respond to icmp by default and ipv6 is disabled.

Nevermind/Scratch that!

 

[cooloutac]

Nevermind/Scratch that!

I think it only relates to dns servers but I dont' blame you for being concerned. who knows. The bluetab article you linked implies otherwise. I also think any dns server that support dnssec should be ok from this attack. you can enable it on merlin firmware. alot of public dns servers support it. google, cloudflare, quad 9... A Pi-hole and attacker on local LAN might be another story though so that script you linked might be very helpful to protect those.

 

[Wallace_n_Gromit]

I think it only relates to dns servers but I dont' blame you for being concerned. who knows. I also think any dns server that support dnssec should be ok from this attack. you can enable it on merlin firmware. Pi-hole and attacker on local LAN might be another story though.

SAD DNS

www.saddns.net

Q&A
Does DNSSEC mitigate the attack?
Yes and no, the server must implement strict DNSSEC check (i.e., refuse the responses that break the trust chain) to prevent the off-path attacks. However, since DNSSEC is still under development and servers need to accept such responses (i.e., only DNSSEC aware but not DNSSEC validate) when visiting a misconfigured domain.

 

[cooloutac]

SAD DNS

www.saddns.net

Q&A
Does DNSSEC mitigate the attack?
Yes and no, the server must implement strict DNSSEC check (i.e., refuse the responses that break the trust chain) to prevent the off-path attacks. However, since DNSSEC is still under development and servers need to accept such responses (i.e., only DNSSEC aware but not DNSSEC validate) when visiting a misconfigured domain.

I'm not following especially your last statement. Regarding your first statement i dont' know of any implementations of dnssec where this doesn't happen? regarding the last, however what? I don't think you finished your thought. dnssec is designed to protect from this and if over TLS or dnscrypt, well then then doubly so but not even nescessary imo although recommended for stronger security. The problem here is that dnssec is not widely deployed not that it's half baked. You can also make the argument dnsscrypt is not fully developed to support the latest dns features but regardless would still be secure in any implementation against this attack.

But you do hit on something that i preach constantly. That Defensive security is a dying breed, less rewarding, and is constantly pressured against as useless when its furthest from the truth, leaving us more vulnerable because of it.

 

[RMerlin]

the server must implement strict DNSSEC check

This is what the "Validate unsigned DNSSEC replies" option does, and Asuswrt-Merlin enables that by default if you enable DNSSEC validation. If you issue a request for a signed domain and receive an unsigned reply, your router will reject it.

 

[Wallace_n_Gromit]

I'm not following especially your last statement. Regarding your first statement i dont' know of any implementations of dnssec where this doesn't happen? regarding the last, however what? I don't think you finished your thought. dnssec is designed to protect from this and if over TLS or dnscrypt, well then then doubly so but not even nescessary imo although recommended for stronger security. The problem here is that dnssec is not widely deployed not that it's half baked. You can also make the argument dnsscrypt is not fully developed to support the latest dns features but regardless would still be secure in any implementation against this attack.

But you do hit on something that i preach constantly. That Defensive security is a dying breed, less rewarding, and is constantly pressured against as useless when its furthest from the truth, leaving us more vulnerable because of it.

That last comment I posted was merely copy and pasted from the www.saddns.net Q&A section of the website. I don't fully understand what it meant, other than the "Yes and no" part which suggested to me that the comments that followed were correct/incorrect based upon the specific circumstances. i.e., That under certain circumstances even DNSSEC could be vulnerable to SAD DNS attack

 

[cooloutac]

That last comment I posted was merely copy and pasted from the www.saddns.net Q&A section of the website. I don't fully understand what it meant, other than the "Yes and no" part which suggested to me that those following comments were correct/incorrect based upon the specific circumstances.

I understand, I'm definitely no expert myself. As Merlin pointed out he implements it in his firmware. I guess the reason someone might not do strict checking is so a connection doesn't get rejected. But imo that is defeats the whole purpose lol. Maybe in its early stages that was a thing? Or maybe its when using multiple servers or the resolver using multiple servers. no idea. I use quad 9. pretty sure this wouldn't be an issue with cloudflare either according to their own article on sad dns, they don't even bring up validation as an issue.

SAD DNS Explained

Researchers from UC Riverside and Tsinghua University found a new way to revive a decade-old DNS cache poisoning attack. Read our deep dive into how the SAD DNS attack on DNS resolvers works, how we protect against this attack in 1.1.1.1, and what the future holds for DNS cache poisoning attacks.

blog.cloudflare.com