amtm amtm - the Asuswrt-Merlin Terminal Menu

[TonyK132]

Is there a way to implement a watchdog timer for NTP with a variable that scripts could query to insure they only run if NTP is sync'ed? Or, maybe a better solution would be a small appliance on the network that is a battery-backed up NTP server? Maybe a RPi?

 

[thelonelycoder]

I've been thinking of hacking this together, as the delay of acquiring time-sync drives me nuts. "Raspberry Pi Buster – GPS Dongle as a time source" - talking to, or even taking the place of an RTC module... saw it on a ham radio video...

https://photobyte.org/raspberry-pi-stretch-gps-dongle-as-a-time-source-with-chrony-timedatectl/

I was wondering if, when a lower numbered stratum device becomes available over the network, would it take pref over the gps dongle?...maybe there's a better way...

What good would that do? Until the GPS dongle is up and running the router sure has synced with an NTP server.
Also, if there's no Internet while booting then getting NTP ready is only 10% of what I consider a useful router/Internet.
Apart from that, there are WebUI built in firmware functions to use a local machine as the NTP server, with the option to use a WAN server as the secondary NTP server.

Is there a way to implement a watchdog timer for NTP with a variable that scripts could query to insure they only run if NTP is sync'ed? Or, maybe a better solution would be a small appliance on the network that is a battery-backed up NTP server? Maybe a RPi?

Read above. And the check is while 0 it is not synced but 1 is OK:

nvram get ntp_ready

 

[thecheapseats]

What good would that do? Until the GPS dongle is up and running the router sure has synced with an NTP server.

The issue is the scripts losing ntp-sync during a reboot with no network attached - as the original poster pointed out... the gps dongle has power, as does the router - and the scripts don't time out with no sync reference as they wait for the network to come up... in his case a cable modem...

 

[gattaca]

^^^ I figured from following these forums over the years, the lack of an NTP sync was gumming up what I found/saw.

What you confirmed troubles me b/c that means when my router finally connected hours after it was rebooted with no internet connection, it had none of the AMTM tooling active - Diversion, Skynet, ...

So, didn't that operational state leave my "front door" open WRT firewall defenses? If so, then that troubles me more! That state becomes a high risk and quite possible which could expose users for weeks if you did not catch it like I did. Or do I badly misunderstand how all this is working?

This is also why I deploy a layered router/FW defense using multiple serialized routers -> 1 runs all the all the AMTM goodies and 1 downstream runs just Merlin with NO AMTM goodies - just default Merlin code. That means there are dual FW to jump thru to get to the most vulnerable PCs and other items. Yeah I know "dual NATing" is not optimal, but I'll take that small hit over the increase security against this corner case - or maybe I got the design of how these work wrong? I've used this dual layer approach for 15+ years b/c I did not trust the vendor's FW or their lack of updates on some other branded routers I used before switching to ASUS+Merlin.

 

[thecheapseats]

in defense of the hardware we're running here - this isn't enterprise class stuff... it's amazing it does what it does for the price point with the help of the skilled script-writers here... just my opinion, of course...

 

[thelonelycoder]

^^^ I figured from following these forums over the years, the lack of an NTP sync was gumming up what I found/saw.

What you confirmed troubles me b/c that means when my router finally connected hours after it was rebooted with no internet connection, it had none of the AMTM tooling active - Diversion, Skynet, ...

So, didn't that operational state leave my "front door" open WRT firewall defenses? If so, then that troubles me more! That state becomes a high risk and quite possible which could expose users for weeks if you did not catch it like I did. Or do I badly misunderstand how all this is working?

This is also why I deploy a layered router/FW defense using multiple serialized routers -> 1 runs all the all the AMTM goodies and 1 downstream runs just Merlin with NO AMTM goodies - just default Merlin code. That means there are dual FW to jump thru to get to the most vulnerable PCs and other items. Yeah I know "dual NATing" is not optimal, but I'll take that small hit over the increase security against this corner case - or maybe I got the design of how these work wrong? I've used this dual layer approach for 15+ years b/c I did not trust the vendor's FW or their lack of updates on some other branded routers I used before switching to ASUS+Merlin.

If you had NOT rebooted your router for the wrong reason, then none of this would have happened.

 

[reerden]

So, didn't that operational state leave my "front door" open WRT firewall defenses? If so, then that troubles me more! That state becomes a high risk and quite possible which could expose users for weeks if you did not catch it like I did. Or do I badly misunderstand how all this is working?

These scripts aren't a replacement for client side security. They are complementary in case something slips through. They add another security layer for your clients.

Remember that most people with Asus routers run the default firmware without issues.

The default firewall rules are secure enough, and drop all incoming packets by default, unless a forward rule is present, or when you explicitly enable something that opens up a port (Web WAN access, SSH etc.). Script like Skynet just complement that by adding explicit DROP rules and adding DROP rules for outbound connections, as well as performing some checks like having WAN access enabled (and correcting that by disabling it).

They increase security but they aren't essential. You have to keep in mind that they are essentially complicated cronjobs, so there are limitations.

 

[gattaca]

^^^ I agree with the statement. However, it does not alter the root cause failure scenario. The fact this failure scenario is quite possible and feasible exposes an issue which maybe should be considered in future designs. That is 100% up to @thelonelycoder and the many other developers of AMTM's many aswesome add-ons! Quite often we make the reward/risk ROI assessments on code or product changes at work and sometimes the risk is accepted. That may be fine here too.

I also agree with the prior poster about not running enterprise class devices - never said we were nor do I think ASUS is an enterprise-class device. But, my home setup connects to enterprise class work VPNs with PII and other nasty gotchas if exposed - so I can never be too careful.

Sorry, if me not hiking all the way into the basement at 4:00 AM to see if the modem was actually up was not my first action. Please don't shoot the messenger. It helps everyone to understand how this works. I admire all the work TLC has done with AMTM for the entire ASUS community. I have also supported Merlin for years. I just needed to understand this failure scenario.

Updated: The poster above says the default ASUS FW is remains active and is supplemented by skynet, diversion etc... which lowers the overall security risk substantially on this failure scenario. Thank You. Peace.

 

[reerden]

^^^ I agree with the statement. However, it does not alter the root cause failure scenario. The fact this failure scenario is quite possible and feasible exposes an issue which maybe should be considered in future designs. I also agree with the prior poster about not running enterprise class devices. But.. my home setup connects to enterprise class work VPNs with PII and other nasty gotchas if exposed - so I can never be too careful.

Sorry, if me not hiking all the way into the basement at 4:00 AM to see if the modem was actually up was not my first choice of actions. Don't shoot the messenger. I admire all the work TLC has done with AMTM for the entire ASUS community. I have also supported Merlin for years. I just want to know how exposed I am with this scenario.

Like I said in my previous post, you weren't exposed. Security is complementary, and the Skynet lists complements your client side web blocking, and probably has like 90% overlap. You would also have to specifically land on a site that serves malware.

The idea behind the script is not to replace client side web protection, but to bump up its blocking rate from say something like 75% to 85%. No antivirus solution or block list is 100% secure, especially not considering IPs and domains are increasingly shared across legitimate websites. This is due to the way the web works with CDNs and cloud services like AWS and Azure.

Keeping malware out of your life is 50% antimalware solutions, and 50% common sense. Even that is not 100% foolproof. Aside from disconnecting from the internet and keeping all PCs isolated forever.

I can also assure you that your work VPN probably has similar, more enterprisy solutions enabled on their network. If the client is supplied by your work as well, it's probably loaded with a overzealous antimalware solution as well. Especially when you're dealing with personal information. This will probably block more than Skynet alone.

 

[thecheapseats]

I understand your concern... I don't think it's unreasonable to throw 60-70 bucks of hardware - if maybe a low-fi RPi3 w/a gps usbstick and a bunch of time (if it can be made to work) to temporarily jam-sync ntp if that's a solution that covers some scenarios... I want to do it because it can - if I beat it hard enough... I want my router to wake up and know what time it is 'just because'... but that's me...

However, I telecommute as well - and the bonded/provisioned telco network that goes to the big cities from 'dirtland' where I live had to be qualified for the suits with expensive hardware, service contracts and security audits - I had no choice... In my case, liability insurance without that was unobtanium... and that network never touches my cable-modem home network with the fantastic-plastic stuff we all use... and yes it is fantastic - I'm not slamming it...

somebody will figure this out... just jabbering from thecheapseats, here...

 

[reerden]

However, I telecommute as well - and the network that goes to the big cities from 'dirtland' where I live had to be qualified for the suits with expensive hardware, service contracts and security audits - I had no choice... In my case, liability insurance without that was unobtanium... am that network never touches my home network with the fantastic-plastic stuff we all use... and yes it is fantastic - I'm not slamming it...

If security needs to be that high, than personal devices (including the Asus router) are a big no-no anyway. Your employer cannot guarantee security on a device they don't control.

 

[Butterfly Bones]

See this thread about a local network time server. Note posts #4 and #9
https://www.snbforums.com/threads/s...le-using-local-time-server.54461/#post-458759

 

[thelonelycoder]

You have to keep in mind that they are essentially complicated cronjobs, so there are limitations.

That‘s a surprizing statement and raised my eyebrows by about an inch.

 

[thecheapseats]

If security needs to be that high, than personal devices (including the Asus router) are a big no-no anyway. Your employer cannot guarantee security on a device they don't control.

yep - they don't control it - it's consumer stuff and it never touches that network, which is all enterprise-class hardware...

 

[thelonelycoder]

^^^ I agree with the statement. However, it does not alter the root cause failure scenario. The fact this failure scenario is quite possible and feasible exposes an issue which maybe should be considered in future designs. That is 100% up to @thelonelycoder and the many other developers of AMTM's many aswesome add-ons! Quite often we make the reward/risk ROI assessments on code or product changes at work and sometimes the risk is accepted. That may be fine here too.

I also agree with the prior poster about not running enterprise class devices - never said we were nor do I think ASUS is an enterprise-class device. But, my home setup connects to enterprise class work VPNs with sensitive PII and other nasty gotchas if exposed - so I can never be too careful.

Sorry, if me not hiking all the way into the basement at 4:00 AM to see if the modem was actually up was not my first choice of actions. Please don't shoot the messenger. It helps everyone to understand. I admire all the work TLC has done with AMTM for the entire ASUS community. I have also supported Merlin for years. I just needed to understand how exposed I am with this failure scenario.

Updated: The poster above says the default ASUS FW is remains active and is supplemented by skynet, diversion etc... which lowers the overall security risk substantially on this failure scenario. Thank You.

amtm, including its disk check and Diversion start and work even if NTP failes to sync. My work has already been done and completed, a long time ago.

 

[thecheapseats]

See this thread about a local network time server. Note posts #4 and #9
https://www.snbforums.com/threads/s...le-using-local-time-server.54461/#post-458759

thanks - and yep, 'zactly that... I first saw this stuff with Pi front ends that a bunch of ham operators were using for time sensitive comms as ntp servers all running on batts... cheap and dirty - all good...

 

[gattaca]

^^^^ Absolutely! That's great to understand. Thank You. I was/am an early adopter and I was not being critical of the works here. I do find it interesting, surprising and a bit disappointing that the tone from many posts, since mine identifying something which maybe could be improved - which I stumbled on at 4:00 this morning - adopted a "shoot the messenger tone" - rather than seeing a potential opportunity. Let me be clear - I was not being critical of AMTM or any of the works done in AMTM. I was attempting to make sure folks knew this gotcha existed b/c I've never seen anything like this condition reported. Everything in AMTM and all the scripts shared by this community were developed, debugged and tested by countless people finding things - a team of interested parties. Let's remember that and keep it going b/c there's no other consumer router community I know with this much talent and backing working to improve a router.

This will be the last statement I make on this matter. Peace and have a great evening.

 

[dave14305]

That‘s a surprizing statement and raised my eyebrows by about an inch.

Better than being reduced to a Windows Scheduled Task!

 

[TonyK132]

nvram get ntp_ready

OK, so for the scripts that need NTP to be up in order to function properly, why don't they test this variable?

 

[Adamm]

OK, so for the scripts that need NTP to be up in order to function properly, why don't they test this variable?

They do;

ntptimer="0"
while [ "$(nvram get ntp_ready)" = "0" ] && [ "$ntptimer" -lt "300" ] && ! echo "$1" | grep -qE "(uninstall|disable)"; do
    ntptimer="$((ntptimer + 1))"
    if [ "$ntptimer" = "60" ]; then echo; logger -st Skynet "[*] Waiting For NTP To Sync"; fi
    sleep 1
done
if [ "$ntptimer" -ge "300" ]; then logger -st Skynet "[*] NTP Failed To Start After 5 Minutes - Please Fix Immediately!"; echo; exit 1; fi