Best practices when using add-ons?

[jetpack42]

Hi there,

I have recently started to venture into the world of add-ons (diversion/skynet) and so far, everything has been somewhat straightforward to learn.

However, when it comes to using SSH - does a security issue get introduced by leaving SSH enabled when not actively using it? I have my SSH setting set to "LAN-only", and it can only be accessed via an authorized key (password logon is disabled and my private key file is further protected with a password). I would rather not disable SSH in-between uses just for convenience, but does that introduce a security issue? From my tests, the port I am using for my router's SSH port is not open to WAN and does not respond to requests from the internet.

 

[Tech9]

You're good. You can leave it enabled.

 

[sfx2000]

I have recently started to venture into the world of add-ons (diversion/skynet) and so far, everything has been somewhat straightforward to learn.

I did a few source-code security scans of the add-ons that were hosted on github...

A number of issues were found, and I reported them to the authors, and they really didn't care...

Use the add-ons at your own risk...

 

[Kingp1n]

Hi there,

I have recently started to venture into the world of add-ons (diversion/skynet) and so far, everything has been somewhat straightforward to learn.

However, when it comes to using SSH - does a security issue get introduced by leaving SSH enabled when not actively using it? I have my SSH setting set to "LAN-only", and it can only be accessed via an authorized key (password logon is disabled and my private key file is further protected with a password). I would rather not disable SSH in-between uses just for convenience, but does that introduce a security issue? From my tests, the port I am using for my router's SSH port is not open to WAN and does not respond to requests from the internet.

Some may say enable it to use & disable it when not in use. I had it enabled as "LAN-only" running multiple add-on scripts for a few years without any issues!

Best of luck!

 

[Tech9]

without any issues

Because the hackers on your LAN are not good enough.

 

[Kingp1n]

Because the hackers on your LAN are not good enough.

Yep it should be easy peasy!

 

[thelonelycoder]

Shellcheck is not a security tool. Just saying.
Anyway, the cmd command in Windows is in most cases always unlocked and ready to use for any user.

 

[Benben]

I did a few source-code security scans of the add-ons that were hosted on github...

A number of issues were found, and I reported them to the authors, and they really didn't care...

Use the add-ons at your own ri

Do you mind sharing your findings?

 

[Mogsy]

Do you mind sharing your findings?

I don’t think such finds should be shared to public, devs only. Else, it’ll become an exploit

 

[thelonelycoder]

I don’t think such finds should be shared to public, deva only. Else, it’ll become an exploit

They are, actually. A plumbers assessment of the perfectly functioning backdoor latch. Nothing more.

 

[Benben]

I don’t think such finds should be shared to public, devs only. Else, it’ll become an exploit

Understood. I hadn't considered this until you brought.

 

[Viktor Jaep]

Do you mind sharing your findings?

This "shellcheck extract" I received didn't help a single bit. It's not a security auditing tool. It merely provides tips on proper syntax. Github, on the other hand, has a robust set of security tools that scans our hosted scripts when enabled. But these scripts are so simple, their attack surface is practically zero. From a security perspective they are pretty safe, since they're open source -- anyone can inspect the code at any time, and we literally have thousands of people doing that on these forums. Many of these add-on scripts are using POSIX scripting language, already available on the router... using functions to automate or bring functionality to the router where there was not any before. These scripts are only available to you, the owner of the router, behind your firewall. They are not exposed to the internet. You can run them, or stop them at any time. Or if you know your way around, you can make your life simpler, your router/connection more safe and stable, by using something that someone else has already built to help with the same problem you are facing. Risk of anything happening because of these scripts is near-zero. Just my 2 cents.

And yes... leaving SSH enabled locally (LAN only) is perfectly fine. It's a common tool that many use on enterprise networks to access their equipment. Communication is encrypted, and will lock you out after 3 invalid attempts for a certain amount of time to avoid brute force attacks.

 

[jetpack42]

You're good. You can leave it enabled.

Thank you to everyone for your advice RE: leaving SSH enabled. You're all awesome. I am slowly learning more regarding home network building as a hobby, but these small things sometimes trip me up.

Use the add-ons at your own risk...

I appreciate the advice, and I will continue to use add-ons at my own risk. I think the principle of "use at your own risk" applies even towards the big picture using custom firmware as a whole, such as AsusWRT-Merlin, even if the risk is somewhat minuscule (again, such as in the case of even using Merlin to begin with without using addons).

 

[sfx2000]

This "shellcheck extract" I received didn't help a single bit. It's not a security auditing tool. It merely provides tips on proper syntax. Github, on the other hand, has a robust set of security tools that scans our hosted scripts when enabled. But these scripts are so simple, their attack surface is practically zero. From a security perspective they are pretty safe, since they're open source

And this was your response...

It flagged a number of syntax issues, which you dismissed... you could have addressed them directly, but you chose to be defensive rather than say "Thank You, I'll fix it"

Github's security is what you pay it to be - it's free, so accept that -- A number of scripts won't even invoke the github scripts, as they're uploads, and not version controlled - if you understand how GitHub handles things there, you'd git it (pardon the pun).

While AsusWRT supports 3rd party integrations - the only ones I actually trust outside of AsusWRT itself is Eric's work on the current branches he supports, and John's LTS fork for legacy devices.

The scripter community is a hobby for them - @Viktor Jaep - this includes you - you're not a pro going into a production device.

The efforts of the 3rd Parties have a definite possibility of compromising the security of what should be a bastion of your LAN/WLAN...

Tread carefully...

 

[sfx2000]

Here's the deal - I'm part of the OpenWRT and Armbian community, and I've also developed multiple embedded linux devices...

As a developer, I've been thru multiple security audits, and had to respond accordingly...

AsusWRT, as part of the legacy of 20 plus years of a code-base, is fairly complex - as I mentioned earlier, @RMerlin is fairly savvy there, probably more that even the in-house devs over at Asus on the platform and the challenges it has.

That being said, the openness of the platform, has allowed it to be extended - in two parts...

1) Entware
2) Scripters

Entware, by itself, is fairly secure for platforms it supports - what I mean by "fairly" is that I haven't seen concerns as many of the packages track OpenWRT - but one always has to question these days - Russia...

Script Writers - I do have a fair amount of concern here, as it's not clear that they understand the implications of modifying a platform that has been under an aggressive attack profile by third parties - hackers and state actors.

So again - keep to stock/factory firmware on Asus - running Stock Firmware you'll be reasonably safe - @RMerlin, his firmware bridges the gaps with certain functionality, and there are times where he is ahead of the curve on security.

 

[dave14305]

I'm part of the OpenWRT and Armbian community, and I've also developed multiple embedded linux devices...

Please link to some of your personal contributions to those communities so we can learn how it’s done by the pros. Otherwise, you’re just grandstanding and trying to look smarter and more enlightened than everyone else here, especially we “the scripters.”

 

[sfx2000]

Please link to some of your personal contributions to those communities so we can learn how it’s done by the pros. Otherwise, you’re just grandstanding and trying to look smarter and more enlightened than everyone else here, especially we “the scripters.”

typical Trumpian response - fix your house first...

 

[dave14305]

typical Trumpian response - fix your house first...

“We’ve got the most terrific, fantastic scripts ever - they’re unbelievable! The best you ever saw. Then there’s do-nothing sfx2000 - the worst of them all! Nobody likes him.”

How’s that?

 

[ColinTaylor]

Dumping the output from shellcheck and claiming you've performed a "security audit" is as ridiculous as it is laughable. Shellcheck doesn't perform security checks and pasting its output into a text file isn't performing an audit on it. Moreover shellcheck generates masses of false warnings as by default it's largely incompatible with the busybox shell and asuswrt-merlin's shell extensions. Of course anyone that's done any rudimentary script writing for asuswrt would already know that. P.S. Paying a professional to audit your developers' code doesn't mean you know how to perform the audit yourself (or write the code).

 

[Viktor Jaep]

And this was your response...

No, this was was my response: "I've gone down the shellcheck rabbithole before... but it becomes a game of excluding multitudes of bogus messages in order to weed it down to the ones that might truly count. In other words, whack-a-mole. But this doesn't improve security... it improves stability and conformity with shell standards."

It flagged a number of syntax issues, which you dismissed... you could have addressed them directly, but you chose to be defensive rather than say "Thank You, I'll fix it"

Flagging optional arbitrary syntax issues ≠ Security issues

Github's security is what you pay it to be - it's free, so accept that -- A number of scripts won't even invoke the github scripts, as they're uploads, and not version controlled - if you understand how GitHub handles things there, you'd git it (pardon the pun).

If you're so worried about security issues in these scripts, then why have you not been submitting pull requests for all these 'dangerous scripts'. I would welcome input and feedback if for some reason or another I'm doing something so outlandish that it would be deemed insecure.

While AsusWRT supports 3rd party integrations - the only ones I actually trust outside of AsusWRT itself is Eric's work on the current branches he supports, and John's LTS fork for legacy devices.

If your view is this narrow that these are the only things you trust... and I'm sure you've done thorough code reviews on these... then by all means, stick with them. Which begs the question... then why are you here bashing 3rd party scripts and script writers and sowing so much mistrust and disinformation?

The scripter community is a hobby for them - @Viktor Jaep - this includes you - you're not a pro going into a production device.

The efforts of the 3rd Parties have a definite possibility of compromising the security of what should be a bastion of your LAN/WLAN...

I would love for you to show some actual examples of 3rd party scripts that we deal with here on a daily basis that are "compromising the security" of our routers. What examples are you able to show us what these security flaws are, and what we hobbyist scripters need to do instead to be more secure. The answer certainly is not to run more shellchecks against our code.

Tread carefully...

Into what?