5 ms·

A few insecure choices here: * fail2ban installed but no mention of actually setting up the rules. Additionally out of the box fail2ban won't work with docker c

A few insecure choices here: * fail2ban installed but no mention of actually setting up the rules. Additionally out of the box fail2ban won't work with docker containers * Wide open ports. Only open what you need * In the DNS script you are putting the username and password in the URL. This means even though you are using https anyone can see the username and password you're sending. Pass these options some other way.

rovr138 7y ago
fail2ban has some defaults. Definitely not for all those ports though. But 80, 443, 22 have them Regarding DNS, the query string is encrypted on HTTPS. It can still be cached on logs on their side for example. It can be seen on the script, but the credentials would still have to be there somewhere.
wheresvic3 7y ago
You're right in that it is better to only open ports that you require - will update :) I'm not quite sure what you mean by "Additionally out of the box fail2ban won't work with docker containers". fail2ban is installed locally on the pi.
- rovr138 7y ago
  fail2ban works by monitoring logs. If you had installed for example your web server on a container, the logs will be on the container. Fail2ban on the host won’t be able to parse the ones inside the container (by default, needs more work).
tyingq 7y ago
I like pam_shield better than fail2ban. It's directly inline with auth, versus parsing logs, and is easier to customize for any oddball setup you might want. There's also a similar pam module called pam_tally2, which I haven't used.
- jlgaddis 7y ago
  I'm not familiar with pam_shield but I've used the pam_faillock module (which is similar to pam_tally2) for years and it just works(TM) [0]. In fact, here, it's automatically configured on each and every host at install-time (via the post-installation scripts in my kickstart files). I can't remember a time when I ever needed to "touch" it afterwards. (A few years ago, I evaluated pam_tally2 vs. pam_faillock and settled on pam_faillock but, unfortunately, I can't recall what led me to that choice.) --- [0]: In reality, though, it doesn't really do much. There's only two Internet-facing servers with 22/TCP open to the world -- the bastion hosts -- and only public-key authentication is permitted on those.
jabbequbs 7y ago
URL parameters will be encrypted with HTTPS, so they're not plaintext over the wire. The problem is that requests are usually getting logged somewhere, so anyone with access to the logs can see your password.
Havoc 7y ago
>Additionally out of the box fail2ban won't work with docker containers oh snap...because the logs are in the container. Hadn't thought of that. Good shout
Sohcahtoa82 7y ago
> In the DNS script you are putting the username and password in the URL. This means even though you are using https anyone can see the username and password you're sending. Who is "anyone" in this context? At most, it would only be anyone that has access to logs and the Pi itself. A man-in-the-middle wouldn't see them because it's HTTPS.

rovr138 7y ago

fail2ban has some defaults. Definitely not for all those ports though. But 80, 443, 22 have them Regarding DNS, the query string is encrypted on HTTPS. It can still be cached on logs on their side for example. It can be seen on the script, but the credentials would still have to be there somewhere.

wheresvic3 7y ago

You're right in that it is better to only open ports that you require - will update :) I'm not quite sure what you mean by "Additionally out of the box fail2ban won't work with docker containers". fail2ban is installed locally on the pi.

rovr138 7y ago
fail2ban works by monitoring logs. If you had installed for example your web server on a container, the logs will be on the container. Fail2ban on the host won’t be able to parse the ones inside the container (by default, needs more work).

tyingq 7y ago

I like pam_shield better than fail2ban. It's directly inline with auth, versus parsing logs, and is easier to customize for any oddball setup you might want. There's also a similar pam module called pam_tally2, which I haven't used.

jlgaddis 7y ago
I'm not familiar with pam_shield but I've used the pam_faillock module (which is similar to pam_tally2) for years and it just works(TM) [0]. In fact, here, it's automatically configured on each and every host at install-time (via the post-installation scripts in my kickstart files). I can't remember a time when I ever needed to "touch" it afterwards. (A few years ago, I evaluated pam_tally2 vs. pam_faillock and settled on pam_faillock but, unfortunately, I can't recall what led me to that choice.) --- [0]: In reality, though, it doesn't really do much. There's only two Internet-facing servers with 22/TCP open to the world -- the bastion hosts -- and only public-key authentication is permitted on those.

jabbequbs 7y ago

URL parameters will be encrypted with HTTPS, so they're not plaintext over the wire. The problem is that requests are usually getting logged somewhere, so anyone with access to the logs can see your password.

Havoc 7y ago

>Additionally out of the box fail2ban won't work with docker containers oh snap...because the logs are in the container. Hadn't thought of that. Good shout

Sohcahtoa82 7y ago

> In the DNS script you are putting the username and password in the URL. This means even though you are using https anyone can see the username and password you're sending. Who is "anyone" in this context? At most, it would only be anyone that has access to logs and the Pi itself. A man-in-the-middle wouldn't see them because it's HTTPS.