With any of the solutions posted in this thread that won’t work. Anyone who really wants to scan your box will do so with custom or lengthened delays or distributed scans to get around timing window bans.
1 Like
Though I agree nothing is vulnerability proof, I can’t fault the OP for venturing into the world of mitigating risk and looking under the hood of the tools to do so.
2 Likes
I’ll have to say sorry in advance, for I will be talking out of my ass.
Coincidentally, while reading the hardening wiki of Bitwarden_RS, I stumbled upon this:
You can probably do something similar. I’m not running f2b, because I only allowed access to the bitwrden_rs server from my IP in apache. I would probably be vulnerable to DDOS, but I don’t worry to much about someone getting unauthorized access. F2b is something I will look for in my future setups, but at the moment, I have no idea how to use it. But from what I understand, you just need to give fail2ban a path to some logs and it basically “greps” how many failed attempts to login or access or something then bans IPs for a set amount of time.
If this is the case, I highly recommend you put your docker services behind a reverse-proxy and put fail2ban on it. Set a password for it and if there is an attempt to brute-force it, ban the IP(s). Probably what I would do (again, I haven’t used fail2ban yet, so I could be literally talking s***).
1 Like
@Token That’s exactly what I wanted to do. Just some mitigation against scripts randomly scanning ports.
Maybe my post wasn’t clear but I’ve never expected miracles from this, just less noise in the logs and less automatic knocking on my ports. Stopping a dedicated hacker is a whole other story.
@ThatGuyB Don’t you worry, I appreciate the effort of answering me. The jail for bitwarden_rs is already in place and I’m using Nginx Proxy Manager with forced HTTPS connection to it.
That’s exactly what it is. You just need to know how to parse the logs with regular expressions. If you’re running Docker containers I still haven’t figure out how to make that work. Maybe I could re-purpose this jail, not sure yet.
1 Like
Maybe you can run a separate process in the background (worst-case scenario a screen session) and do
docker logs -f --tail container_name >> /var/log/container_name.log
… and then just point fail2ban to this log. I haven’t tried it with docker logs, but it seems like doing it with just echo and tail to a file works, so I see no reason why it shouldn’t work. But obviously, the service needs to spew access logs into docker logs.
2 Likes
You know, I’m just dumb. I’ve mistaken what has been said by mr. Garcia in the instructions for Bitwarden_rs because he’s talking about fail2ban in a docker container, while my istance is installed natively on the system to reduce headaches.
If you didn’t post this I would’ve never come to this conclusion so thank you so much for this!
2 Likes
You’re welcome 
glad to be of some help.
2 Likes
All you can do is open or close ports.
If a port is open, it can be scanned.
What you can do is often configure the service running on said port to divulge less information (e.g., if its an SMTP server, don’t display OS/server version, etc.). You can also do your best to harden the service - and I’d also recommend locking the permitted IP ranges down to where you will be rather than “from any” if possible.
e.g., if you aren’t going to be remotely connecting to your box form china (or Russia, or wherever) via SSH, then block their entire IP address space for SSH for example. Limit to the ISPs or Telcos you use.
Well, you might be able to pull in lists of known abused IPs and block everything from them but that’s an exercise in scripting…
2 Likes
Also, at the end of the day, if you’re connected to the internet, you will be port-scanned regularly.
Rather than trying to block scans (which isn’t feasible) - do your best to expose things only to where they are required to be exposed, and secure them as best you can.
If feasible, use an authenticated reverse proxy or even better a VPN service rather than exposing the service directly, as that way you’ve reduced the attack surface to your VPN server that you can more easily secure or control access to, rather than having every hole (both known and as yet not publicly disclosed but possibly in the wild) in every service you’re hosting exposed to the world.
Work, for example I don’t expose SSH to the world, I don’t expose any admin interface to the internet; the only way in for SSH is via VPN connection and then ssh key based auth.
Some things you need to expose (like mail if you host it) but limit exposure to those things that you can’t hide behind a VPN tunnel.
4 Likes
But if I straight up ban IPs that scan me I have a better idea of what’s going on.
Step by step I’m learning how to secure my applications beyond the integrated security that they already provide. I’m integrating more rules to mitigate DDoS and other attacks.
Check! VPN not possible since I’m gonna have some people on them and ask them to configure and keep safe the VPN key is too much for them (non- tech savy people).
That’s exactly what I’m already doing. Only the bare minimum needed is exposed. Everything else that can go through a reverse proxy with authentication is already setup that way.
Wasn’t there some legitimate service that at least scanned some ports of their clients to check for known intrusions? Amazon maybe?
I didn’t know there was something like that going on. Like white hat hacking type of deal?
Turns out I was only partially correct, it was Ebay: https://www.techradar.com/news/ebay-is-port-scanning-users-pcs
Article is fairly recent but they’ve been doing this for a long time already. Had to dig quite a bit deeper than a Techradar article to figure out what was going on first time I noticed it 
1 Like
Well looks like something very selfish to do, but I understand that big business need to protect themselves against elaborate forms of scamming and fraud.
Still an interesting read, thanks!