Given the nature of PiHole, I want to ensure the box is reasonably secure.
It'll be running on a Raspberry Pi3 with raspbian running behind my router and will not be publicly accessible. I suspect this is a highly common setup among pihole users.
I'm not a linux savvy either, but my research has lead me to these points below. I would like to know the thoughts of the pihole team, or others to see if this should be sufficient or if any of these steps could break pihole.
This site appears to have a wealth of info about securing raspbian albeit it's for a webserver. Here are the things I dug out that looked useful.
Delete the default 'pi' user and setup a new user.
Update the os.
Disable SSH password authentication and root login in favor of SSH Key Pair Authentication.
(Optional) Create a firewall and only allow access for the console, ssh, and dns ports.
Hi @sandman, if it is not a public server, like you said, there is no real need for these modifications.If you running a big LAN where many people got access to, it would be reasonable to make your server as secure as possible.
Thats nonsense. But you have to change the default password "raspberrypi". It is reasonable to
run special services with it's own users.
You always should keep your os up to date.
For a public server, this is a very important modification, but you do not have to do that.[quote="sandman, post:1, topic:1867"]
4. (Optional) Create a firewall and only allow access for the console, ssh, and dns ports.
[/quote]
Never setup a firewall, if you do not know what you are doing, you can rip off huge security holes.[quote="sandman, post:1, topic:1867"]
5. (Optional) Install Fail2Ban.
[/quote]
It is "useless" for a home environment, it makes only sense for a public server.
I am not sure if it is ok to discuss those security questions in this forum, because they have nothing to do with pihole.
I do NOT agree with the analysis of Vertux. Having little or no security on your pi implies you are trusting your network never to be breached, however, once somebody has taken control of a machine on your network (not necessarily your pi), they can do just about anything they want, if the other machines on your network aren't sufficiently protected. I've written a manual to help users setting up pi-hole with some (but not all suggested) security measures, you can find it here.
A simple example that bypasses your main firewall (the one that protects your entire network): A users opens a VPN connection to gain some anonymity. Everything passes trough your main firewall, leaving you with no protection, apart from the protection, added to the individual machines. If this machine is compromised (you never know what is on the other end of the VPN), you'll definitely want the aditional protection.
Definitely not! It is all about your personal model of threat. Let me explain what I mean by giving two extreme examples. You can try to justify where in between the two described models you see yourself.
My parents at home
They have only a limited number of devices in their local network (only Linux and Mac)
Nobody except them knows the password and nobody will get it since it is very long, I change it every 6 months and it is securely hidden written on a piece of paper
They don't even know what VPN is and are generally not interested in such "internet things"
They have a very limited and conservative usage strategy of the Internet. They basically do nothing despite Onlinebanking, Webmail, eBay and such, they do only ever use the browser and no other software
The flat-sharing community of my sister
Everyone that visits them gets the password of the local WiFi and they never change it
You have no idea who is visiting and what their attitude is
There is a number of devices where you can't see what is going on behind the scenes (games consoles, smart TVs, other smart home devices)
Some of the visitors that are staying longer might do bad things (in the sense of illegal) and might be using whatever tool to download whatever
Some of them might even try to conquer the devices in the local network, just because they are bored
Situation 1:
Yes, change the password of pi, because this is always the first thing you should do. But, I feel perfectly safe by not applying any other protection measures. I check every few weeks that the OS is updated.
Situation 2:
The Pi-hole has to be protected as if it would be open top the Internet, as you have to take into account that the threat can be inside you local network (i.e. there is no NAT/firewall in between to protect your device). Yes, change the password (do that always!) or switch to Key-only login for SSH. No, don't change the username (that is meaningless). Yes, update regularly, although that might not be super-critical. No, don't install a firewall - just remove the services you don't want to listen. Yes, install fail2ban (you will even be happy with the standard configuration, no need to do anything further than just apt install it), as the thread can be inside your local network, i.e. secure it as if it would be out in the wild.
PS: This is what my Pi-hole Raspberry listens on, no extra firewall is installed:
me@desktop ~ $ nmap pi.hole
Starting Nmap 7.01 ( https://nmap.org ) at 2017-02-24 13:28 CET
Nmap scan report for pi.hole (2003:x:x:x:x:x:x:x)
Host is up (0.0065s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
Chose for yourself - what is your personal model of threat?
I think it is very important, that users get a feeling of security and think about security when they change things or install some "fun stuff". It is always a tightrope walk between comfort and security - literally it is a very personal decision. [quote="jpgpi250, post:4, topic:1867"]
Correct me if I'm wrong.
[/quote]
I would not contradict you.
[quote="PromoFaux, post:3, topic:1867"]
Discuss whatever you want wherever you want! (Though try to keep it in the named categories )
[/quote] Thanks for the clarification
I have the feeling that I cannot leave that alone as it stands there. I personally don't see that this - if you do it right.
Let me give only a few examples:
Certainly, a super-long password may be inconvenient, but look only at public-key authentification. You gain a vast amount of security by a one-time configuration. You can even feel perfectly safe with having a less-super-complicated password as long as you can ensure that your key does not get into the wrong/other hands.
If you don't feel comfortable with SSH keys and you prefer to use passwords only, that might first be understood as a convenience measure, but also keys are convenient. You will see that it will limit you to only log into your devices from computers you can trust (i.e. would put your private key on). It does not sound like a good idea to SSH into your devices from computers you don't trust, right? There could still be keyloggers or whatever installed, which would render the strongest password useless.
Many strong security measures go even unnoticed and don't touch your everyday work at all. An excellent example is fail2ban. The only thing you have to do is running sudo apt install fail2ban. The default configuration will (temporalily) ban clients which failed to log in six times. Honestly, if you have to try so often, you should change your password anyhow
The list continues but I stop here since we are all busy people...
Many sources on the internet state: <quote>Fail2ban is fundamentally a wrong answer to the problem. If you're taking the time to install such things, you should instead either be turning off password authentication (relying only on keys)</quote>
I've tested fail2ban (SSH jail) on a system with keys and disabled password authentication, fail2ban detects absolutely nothing. This is also confirmed by multiple internet articles.
As an alternative, you can lock-down SSH even more by using the guidelines in this article.
You could use something like (/home/pi/.ssh/authorized_keys):
I also think you're in the wrong to underestimate elderly people. Using their mail contacts, they learn a lot about the internet and sometimes end up on the darker side. One keylogger is enough to break your security model.
If people don't want to set up key authentication (for various reasons), then fail2ban is a very good thing to have. For a former employer, I had to set up a number of servers who have their SSH port facing the public Internet with the requirement of allowing password logins. The servers got continuously bombarded by (mostly Chineese) brute-force SSH attacks.
I can confirm that fail2banindeed worked quite well by locking out several attackers ever few minutes.
The link you provide suggests to restrict SSH logins to particular IP addresses, but that can easily lock you out of your server if you don't have static IPs.
I'm saying I'm going to underestimate elderly people, I'm just saying that I perfectly know what my parents would do and what not. They have a clear feeling for security and won't do anything on the Internet which they are unsure about (even if their best friend sends them something).
Don't get me wrong, what I wanted to say with my statement was, that you can carry security to extremes, which would lead to a loss of comfort e.g. if you change your password every day etc. - I am absolutely sure that everybody can reach a very solid security level without to lose any comfort in usability. I currently think about buying a Yubikey - IMHO a nice piece of hardware which gives you even more security.
I've already read through all of the source code of pihole and trust it enough. However, given the nature of pi-hole, and the fact it'll always be running, I intend to try to secure the pi a little more.
'Reasonable security' as many of you have hit on is subjective. I have some reading to do, but perhaps I'll come back and suggest a prioritized list of security items.
First of all, I don't want to end up in a YES/NO discussion, just want to state my findings, as a reply to the simple question:
sandman suggested:
DL6ER replied:
I want to prevent users to get a false secure feeling, as my findings do NOT confirm this.
On a system (raspbian, version january 2017), configured with key authentication and passwords disabled, fail2ban does nothing without additional configuration.
I'm using keys without a passphrase (I keep my keys in a TrueCrypt container).
I'm using putty (version 0.68), OpenSSH for Windows (version 7.4p1-1) and WinSCP (version 5.9.4) to access my raspberry pi.
In order for fail2ban to detect login attempts (attempts with or without a key), using OpenSSH, I added the following to /etc/fail2ban/filter.d/sshd.conf:
^%(__prefix_line)sConnection closed by <HOST> \[preauth\]\s*$
The above 'failregex' will catch (from /var/log/auth.log) the following message:
Feb 25 14:19:16 raspberrypi sshd[4537]: Connection closed by 192.168.2.127 [preauth]
In order for fail2ban to detect login attempts (attempts with or without a key), using Putty and WinSCP, I added the following to /etc/fail2ban/filter.d/sshd.conf:
^%(__prefix_line)serror: Received disconnect from <HOST>:.*\[preauth\]\s*$
The above 'failregex' will catch (from /var/log/auth.log) the following message:
Feb 25 14:21:36 raspberrypi sshd[4587]: error: Received disconnect from 192.168.2.127: 14: No supported authentication methods available [preauth]
This will protect your pi from login attempts,using Putty, OpenSSH and WinSCP, fail2ban reports:
This configuration may NOT protect you from other SSH clients, as they may well generate a different message in /var/log/auth.log. The messages in auth.log may differ on other linux distributions, they may even change in the next version of raspbian!
If you want to test your expressions (verify if the expression is detected by the 'failregex'), you may test them with the following utility (installed with fail2ban):
If you followed my guidelines, setting up SSMTP mail, (you can find the instructions here, chapter 4.8), all you need to do to receive mail (gmail account required):
copy the original fail2ban configuration (you should do this once, if you intend to change the default configuration):
edit /etc/fail2ban/jail.local
find the following setting: destemail = root@localhost, modify the setting (replace <your_email>):
destemail = <your_email>@gmail.com
find the following setting: action = %(action_)s, modify the setting:
action = %(action_mw)s
important: if you have been testing fail2ban (try a lock out detection), to verify the functionality, clear your auth log before restarting the service!
fail2ban does nothing without additional configuration.
So you agree it can be done ?
Just asking because I dont see the proper failregex for failed login attempts via key in your previous posting.
And yes its a layered defense, one security measure on top of another to plug the holes.
Am not into discussing whats best, i am just pointing out that it can be done to ban failed attempts using key only.
And this statement seems highly unlikely:
This configuration may NOT protect you from other SSH clients, as they may well generate a different message in /var/log/auth.log.
When I get a new VPS instance, the first thing I do is copy over /.ssh/authorized_keys, chmod it, uncomment PasswordAuthentication no in /etc/ssh/sshd_config, and restart ssh. This way I can block most of the people, most of the time, with the least amount of steps.
I would recommend puttygen for windows users who want to create a key pair for themselves.
I think you very misunderstood me - I never said anything in the explicit combination of fail2ban and SSH with keys.
I rather said something like: when you use SSH with password logins, you should rather use fail2ban. In its standard configuration is is quite powerful and severely hardens your security by rendering brute-force attack almost impossible (by slowing them down a lot). I could tell you about at least five experienced guys who successfully locked themselves out of a remote system where fail2ban is running (remember, if you don't own the server, you might not be in the position to dictate that password-logins are forbidden).
If you use keys (given that they are sufficiently strong), you won't even need something like fail2ban. It will not increase security but could rather be used to reduce the stress on the server with external parties running brute-force attacks on you. I agree that fail2ban
Yeah, you should have other access via VPN or KVM over ip to not get locked out by mistake
Ps. the default ban is only 3 or 5 minutes i believe ... long enough to slow down brute force.
)
