[300] Security

[thehog]

I'm wondering, how do you guys secure access to the NMT? I bought a A-300 and it provides telnet out of the box. But, there's no password and it actually gives root privileges! That means that although FTP and SAMBA request a password, anyone on the network can access and modify content on the NMT.

I'd like to e.g. enable dropbear and disable telnet and exclude root from remote logins.

Can this be done safely? I already installed opkg and rsync. But.. modifying the startup scripts to enable dropbear and disable telnet is a bit risky. Is there a (serial) console option on the PCH A-300 in case I mess it up?

Thanks!

[halfelite]

you cant modify startup scripts they are in read only section of memory, The easiest way is install dropbear at the same time use start_app.sh to kill -9 telnet

[thehog]

(05-18-2012 11:11 PM)halfelite Wrote:  you cant modify startup scripts they are in read only section of memory, The easiest way is install dropbear at the same time use start_app.sh to kill -9 telnet

Where can I find the start_app.sh script? It's not on the fs yet:

Code:

sh-3.00# uname -a
Linux A300 2.6.29.6-33-sigma #10 PREEMPT Tue Feb 28 17:15:42 MYT 2012 mips GNU/Linux
sh-3.00# find / -name start_app.sh
sh-3.00#

Second, is there a description of the sw design (layout of the filesystem, firmware in mtd, etc)?

[chris57]

I think you have to install something via the CSI for the script to be created. You should see it in the /share of the NMT Apps install location.

[halfelite]

i will give a better example then using start_app.sh start_app.sh is put on when you install something with csi. The trick to making your own is edit ftpserver.sh and after the line the ftp server starts edit in a line to launch another script in another file that way you can store whatever you want in the file on your local storage.

[Krusher_r]

I've been searching around here for the last hour and this is the most relevant topic I've found so far without posting "yet another post" about password protecting the telnet login.

Referencing the OP, is there a way to simply add a password to the root login? I thought this would have been fixed/enabled by now on the A-300's newer software (I have the A-210) but I see the problem still exists. I found some older references such as using dropbear and disabling telnet like you have also done, but I just want a password on it like FTP and SAMBA already has.

If I am missing some terribly easy instructions let me know; I guess I needed more searching.

Thanks!

[accident]

your samba and ftp isn't secure either.. the units aren't secure, can't keep up with security patches even if they try to be and shouldn't be treated as an internet ready server.

If remote access is really this important perhaps a different method which secures the entire house from 1 spot is better. There are reasonable cost routers with built in vpn servers. Then you have nothing in your house opened up, the router can keep up with security updates for vpn and it's pretty much built into every modern tablet, computer and mobile phone to vpn home.

[Krusher_r]

I'm not looking for remote access; this is just on my LAN behind a firewall. No firewall can be 100% safe, especially if you have a WiFi router. An accidental reset will default most routers to open WiFi. That is bad.

I have passwords on my home computers, NAS, and even my iPods. Why isn't the telnet ROOT login password enabled by default? This seems really unsafe.

[halfelite]

Passwords would be least of your worries everything on it has vulnerabilities that are years old. Seems like you are a bit too worried about security on your internal network.

[accident]

You can put usernames or passwords all you want, I can stlil probably gain access to any device on your network in a couple seconds.. you don't need to come in the front door..

A reasonable level of security is to step back and look at what they can do if they gained access. It's really your media files that need protecting. Read only access for the pch on your nas or don't use shares at all. usernames and passwords are good but a false sense of security because that's not how the people you need to worry about are getting in.

[Krusher_r]

Well, the way this is going seems to be that the rationale that no security is better than security. Do you have a SMB/FTP password on your box? Any on your home computer? NAS box? Router login?

After all, they're all on your Internal network and that's 100% safe anyway. Well except from accident who will get in a few seconds lol. Ok, sarcasm off.

Passwords provide a reasonable level of security in case something goes wrong. Like your WiFi router gets reset and is open to the world while you're on vacation. Or you're still using WEP because you don't know better and get hacked. Or you though your SMB/FTP password covered it all.

Rather than get into a long discussion that is off topic, is there any way to enable the root login to query you for a password? It seems like a simple problem/solution to define. Implementation, maybe not due to reasons I have not seen yet.

[halfelite]

Sounds like you are more worried about WIFI why not isolate your wifi so its not connected with the rest of your network. Again lets think about it, Your wifi gets reset someone logs into and they see a pch device, first thing first people would see its linux and try ssh as telnet is not default linux install, So when the doesnt work they would have to resort to port scanning or what not to see what services are running, Again if someone is running port scanner they are beyond the simple lets try the password of 1234.

And then we will say ok they got into the PCH now what. if the pch uses network shares make sure that users only has read access then nothing will happen. worst comes to worst you have local media on a drive it gets wiped. If you have a reason to harden your local network that is one thing. But you are talking wifi/firewalls like you are expecting something to come from the outside world.

[accident]

Nobody is disagreeing with the recommendation of a username/password on telnet. To think your secure with just a u/p or any method of wireless security is a lack of understanding how people "hack" their way into things and how minimal the security settings need to be on a samba server to allow the ancient samba client on the pch to use a username/password on your nas.

To answer your specific telnet login question, your only option that will remain after a reboot is going to be doing a boot script to kill the telnet server, setup the config for a u/p and turn it back on.

[Krusher_r]

@accident,
> To answer your specific telnet login question, your only option that will remain after a reboot is going to be doing a boot script to kill the telnet server, setup the config for a u/p and turn it back on.

Ok so that pretty much sums it up then . There's no way to add a password for Telnet right now (that survives a reboot) other than disabling it completely. I'll look around for the suggestion section to add a "me too" for such a request. I thought it would have been implemented by now.

Regarding WiFi hacking (cracking), I know...WEP was cracked a long time ago and is fairly easy with the right Linux distro that I won't mention lol. WPA/WPA2 is only vulnerable if you have a really short password. I don't have any short passwords.

@halfelite,
I know those scenarios are a stretch, but what I was trying to demonstrate is that you probably have passwords on everything else on the LAN side of your network "just in case"; why not the PCH? It's like it was half-finished. I had hoped that I was simply missing the easy activation.

Well, we don't need to keep going here as accident answered my question. I'll keep searching around a bit.

Thanks for your comments accident and halfelite.

[Omertron]

I think, you have to understand that the PCH, whilst it might be a point of ingress onto your network is unlikely to need a great deal of protection unless you open it up to the internet rather than your intranet.

If you feel the security on the PCH isn't sufficient for your network then you need to treat it as an untrusted client. Put it in a DMZ, don't store passwords on it, lock down the rest of your network from accessing it.

As others have said, there are workarounds for preventing access to telnet that you can do to increase the protection of the box itself.