Re: Fail2Ban Question: Can I do this without restarting the service?
On 08/17/2018 04:58 PM, Dave Sherohman wrote:
[Snipped some useful info]
I *never ever* use port 22 for ssh. I pick some random port that I know
isn't going to be used for anything else on the server and set ssh to use
that port instead. How do I set ufw to use the ssh port of my choosing?
In the ufw rule, just change "port 22" to whatever port you actually run
it on. The important thing, of course, is just that you don't block the
ssh port if you're doing this over ssh.
I more than likely would be sure I can log into ssh before blocking
anything else.
That's not going to be possible to determine. I and the other admin (who
also doesn't know about this stuff) both connect remotely via ssh and we
both have dynamic IPs that are set (and changed) periodically (and at times
we have no idea) by our ISP. Neither of us can afford a static IP to our
homes.
If you collect your DHCP-assigned addresses across a few changes, you
should be able to guess pretty accurately at the range of possible
addresses you might be assigned. Also, even with a single address, your
odds are pretty good if you just use the /24 CIDR block containing that
address, since most DHCP pools aren't going to be larger than that.
So, e.g., I'm currently at a hotel with IP address 83.244.xxx.85. I
could almost certainly give access to the hotel's entire range of
dynamically-assigned IP addresses by allowing access from
83.244.xxx.0/24.
While I don't travel, the co-admin travels a LOT and doesn't always stay
at hotels. Sometimes they are on the road, getting wifi other places,
etc. So again, probably not possible to even get a good range.
Can I do this too?
ufw deny 22/tcp # Deny connection to port 22 (ssh default port)
You could, but there's generally no point because all ports are denied
by default. You usually don't need to create specific deny rules unless
you have a port that you want to have open to the world, but then close
it for specific addresses, or if there's an IP address that you want to
allow access to all ports, except for a few specific ports.
But (unless I was mistaken) wasn't port 22 open by default for ssh? So
wouldn't I have to block it once I change and open the other ssh port?
ufw allow [new-ssh-port]/tcp # Allow connection to new chosen ssh port
This would work, and would allow every IP address in the world to
connect to your custom ssh port. (Which is not, IMO, a bad thing, but
your level of paranoia may vary.)
Well, seeing as how the co-admin needs to get in too, it may be
necessary. Who knows what IP they will have as they travel.
Thing is, the bots hitting the server aren't getting 404 errors. They are
trying to do php XSite injection on Wordpress sites and hitting actual web
sites (HTTP 202).
It just so happens I have a jail like that on a couple of my servers,
too. I have the filter in /etc/fail2ban/filter.d/http-get-dos.conf
[Snip very good info]
Thank you for this! That I think will come in very handy.
Based on what you've said so far, I expect you'll want to adjust the
maxretry/findtime/bantime values, but my experience has been that
banning offending IP addresses for 10 minutes generally seems to be
enough for them to give up and go bother someone else.
We have seen otherwise. Once the ban is lifted, they just resume
hammering the site. I think that it's a bot that is automatic and
doesn't check to see if it was banned or not. It'll just keep going at
whatever is in it's list ad-infinitum.
Banning for months at a time is unlikely to be necessary unless
> you're dealing with a targeted attack.
Seems like we just might be, actually. About 4 IPs keep on it no matter
what.
[Snipped more very useful info]
(though Ubuntu seems to do things differently for Debian but that's OK
since I would assume this stuff is the same for Debian and Ubuntu as
for fail2ban/ufw?)
I have limited experience with Ubuntu, but my impression is that their
differences (aside from release schedule) are primarily dealing with
end-user-focused applications. Networking and firewall management are
deep enough in the guts that I'm 99% sure they'll be the same in both
distros.
That's good to hear that Debian stuff I learn here will also be good in
case I need to make an Ubuntu server as well.
Reply to: