preventing remote access to pi account

04 Dec 16 20:50, you wrote to bob prohaska:

CG> On my pi they'd find some boring linux'y technical stuff and that CG> would be all.

they don't care what's on the machine... only what they can use it for in their purposes... botnet zombie is the first on the list... done properly, you won't even know it is a zombie and participating in DDOS attacks and other shenannigans...

)\/(ark

Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... By my weirdness, you shall know me...

Reply to
mark lewis
Loading thread data ...

The user pi seems to be a very popular target of remote ssh attacks, perhaps second only to root and admin.

Even though my pi is behind a firewall, I'd like to suppress remote access to the pi account, without disturbing access via the machine's console. There are special provisions for doing this with the root account by setting /etc/ssh/sshd_config to PermitRootLogin No or setting the root login shell to /etc/nologin.

Is there a better/easier way to secure a Raspberry Pi against intrusions via the default account? Ssh likely isn't the only way in (there's a lot going on under the hood). Something more general than sshd_config would be desirable if it exists.

My first thought was to simply remove the pi account and put another user in the group wheel, so as to allow su to root for administrative activity. Will that cause intractable breakage? The Pi is being used mostly as an X terminal for a small network. Thanks for reading!

bob prohaska

Reply to
bob prohaska

Use the local firewall on the Pi to allow only local users to log into ssh.

Use a public/private key for login to your ssh server.

Don't allow root or pi to login to ssh and create another user that is the only account allowed to login to ssh and put him in the sudoers file. (see allowusers in sshd_config).

--

Knute Johnson
Reply to
Knute Johnson

Removing the default user is one of the first things I do with any system that has one. It comes after adding another user and before exposing to the internet. Anything that breaks as a result is already broken - so far nothing has.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>WIN                                      | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

The first and most obvious step is to harden your firewall:

- change the password on its admin login to something non-obvious, unrelated to its default setting and not the same as ANY other passwords you've used for anything anywhere.

- make sure that admin logins are only accepted from your local net, e.g by setting its netmask to only accept logins from 192.168.255.255 if that's possible.

The default setting on many cheap COTS ADSL routers (assuming that's where your LAN firewall lives) is to accept logins from anywhere, so doing this locks out external access.

- make sure you don't allow port forwarding from any external addresses.

The only case where this can cause a problem is when you're running a private mailserver that accepts inward SMTP connections to receive mail. However there is a workround. Use 'getmail' to retrieve incoming mail from your ISP's mail server via POP3 and pass it to your internal mail server for delivery within your LAN.

No other comms protocol needs to accept inward connections from the 'net, unless you're running a public-facing web server or database, because the client programs you or your computers start will always make an outward connection to a server somewhere out on the wider net.

- when you've done the above, visit the Gibson Research Corp,

formatting link
and use his Shields Up! tool to make sure that your LAN can't be accessed from the outside. If it won't accept incoming connections but it externally visible, consider further hardening it so it won't respond to external probes.

If you're running a wireless network, make sure that it will not accept connections from other peoples toys, i.e make sure its using good encryption, always requires passwords and only advertises the minimum set of services, restricted if possible to you and your family.

- You can always run a firewall on the RPi. This will allow you to limit access to a defined set of IP addresses and/or a range of IPs. It will also let you restrict the list of active ports (why would you let anything connect to port 80 if you're not running a web server?)

Nothing wrong with that. I allow root access from my LAN's range of subnet addresses, but be aware that I've also hardened my ADSL modem's firewall (no port forwarding and set to be totally unresponsive to external probes and connection attempts.

While you're at it, set up SSH for X-11 forwarding. This lets you run graphical programs on the RPi from any other computer on your LAN that has an SSH client installed. Of course, if other computers on the LAN are also set up this way, you can also connect to their X.11 graphical programs from the RPi.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

... and what does the attacker find if they succeed in breaking in?

On my pi they'd find some boring linux'y technical stuff and that would be all.

--
Chris Green
Reply to
Chris Green

Don't know your life, but speaking in general:

1) a willing recruit to a botnet 2) a machine that can monitor your LAN traffic and see how you do your on- line banking.

These things could happen to some people.

Reply to
Mel Wilson

a platform from which to attack your LAN, or create a BOTnet?

Until they installed something else...

--
Gun Control: The law that ensures that only criminals have guns.
Reply to
The Natural Philosopher

If simply removing the pi account won't cause major breakage (essential files owned or something like that) that seems the simplest approach.

The existing DSL modem/router is reasonably secure, the login attempts are showing up in log files on publicly-visible name and web servers.

Thanks to everyone for reading and patient good counsel!

bob prohaska

Reply to
bob prohaska
05 Dec 16 14:59, you wrote to bob prohaska:

rc> make the network invisible - not broadcasting ssid.

that doesn't work... i can easily detect your so-called hidden wireless network simply by listening to your devices calling to it... it is a fallacy... sorry...

)\/(ark

Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... The shortest line always becomes the slowest when you choose it.

Reply to
mark lewis

make the network invisible - not broadcasting ssid.

Reply to
ray carter

This doesn't help. When the client tries to connect to the network, it broadcasts the network name in clear anyway.

Reply to
Roger Bell_West

Right up until they installed a rootkit. At which point, you'd be part of a botnet, and then the rest of your internal lan analyzed looking for more recruits. All that "internet of things" they're trying to sell you? all potential victims.

And they'd be able to come and go as they pleased.

--
Consulting Minister for Consultants, DNRC 
I can please only one person per day. Today is not your day. Tomorrow 
 Click to see the full signature
Reply to
I R A Darth Aggie

Perhaps I neglected to mention that I wanted to keep using the GUI. In light of that detail, removing the pi account does portend major breakage.

It wasn't hard to add a new user, add the user to the wheel group and set the Pi to boot to CLI, resulting in a login prompt at boot.

Logging in to the new account worked fine, and startx brought up the desktop, but none of the menus worked. I couldn't even log out. Had to pull the plug.

A little Web searching revealed several account of how to let a new account make use of the GUI, but all were somewhat involved and none were recent (pi3) vintage.

Seems like this ought to be a FAQ....

Thanks for reading,

bob prohaska

Reply to
bob prohaska

Hmm, that shouldn't be too hard to fix by copying the appropriate configuration from the pi account to the new one, although it would be a lot better if there were a template set to use. I'm not sure what configuration files you'd use, I always set up my own rather idiosyncratic GUI arrangements.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>WIN                                      | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

Il giorno domenica 4 dicembre 2016 18:50:05 UTC+1, bob prohaska ha scritto:

- change ssh port or at least change the NATting port on the router (so that from WAN you access using port 45634 but from LAN you still use port 22)

- install failtoban

- use non trivial password or (better) use certificates

formatting link

Bye Jack

Reply to
jack4747

Set the ListenAddress in /etc/ssh/sshd_config to LAN port. PermitRootLogin to No.

--

Chris Elvidge, England
Reply to
Chris Elvidge

If simply copying the dot files from /home/pi to the new account would do the job it's worth a try. I'm thinking there are other configuration issues, group memberships among them. Adduser clearly does not know about the details..

Thanks for reading!

bob prohaska

Reply to
bob prohaska

In case you might not be acquainted with the process, group membership is easy. Simply do "id" as user pi, then do it as the new user, then use adduser to add the new user to all the missing groups.

HTH

--
Robert Riches 
spamtrap42@jacob21819.net 
 Click to see the full signature
Reply to
Robert Riches

Just copy /home/pi to /home/new_user and change ownership.

Reply to
Rob Morley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.