Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #198836 > unrolled thread

Fail2Ban Question: Can I do this without restarting the service?

Back to article view | Back to linux.debian.user

Contents

  Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-16 03:40 +0200
    Re: Fail2Ban Question: Can I do this without restarting the service? john doe <johndoe65534@mail.com> - 2018-08-16 08:40 +0200
      Re: Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-16 13:50 +0200
        Re: Fail2Ban Question: Can I do this without restarting the service? john doe <johndoe65534@mail.com> - 2018-08-16 16:00 +0200
          Re: Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-16 16:40 +0200
    Re: Fail2Ban Question: Can I do this without restarting the service? Dave Sherohman <dave@sherohman.org> - 2018-08-16 19:10 +0200
      Re: Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-16 20:10 +0200
        Re: Fail2Ban Question: Can I do this without restarting the service? Brian <ad44@cityscape.co.uk> - 2018-08-16 21:40 +0200
        Re: Fail2Ban Question: Can I do this without restarting the service? Dave Sherohman <dave@sherohman.org> - 2018-08-17 17:00 +0200
          Re: Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-17 19:00 +0200
            Re: Fail2Ban Question: Can I do this without restarting the service? john doe <johndoe65534@mail.com> - 2018-08-17 19:20 +0200
              Re: Fail2Ban Question: Can I do this without restarting the service? Brian <ad44@cityscape.co.uk> - 2018-08-17 19:40 +0200
                Re: Fail2Ban Question: Can I do this without restarting the service? john doe <johndoe65534@mail.com> - 2018-08-18 18:00 +0200
                  Re: Fail2Ban Question: Can I do this without restarting the service? Reco <recoverym4n@gmail.com> - 2018-08-18 19:30 +0200
                  Re: Fail2Ban Question: Can I do this without restarting the service? Brian <ad44@cityscape.co.uk> - 2018-08-18 20:10 +0200
              Re: Fail2Ban Question: Can I do this without restarting the service? Brian <ad44@cityscape.co.uk> - 2018-08-17 20:00 +0200
                Re: Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-17 20:40 +0200
              Re: Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-17 20:00 +0200
            Re: Fail2Ban Question: Can I do this without restarting the service? Brian <ad44@cityscape.co.uk> - 2018-08-17 20:10 +0200
            Re: Fail2Ban Question: Can I do this without restarting the service? Dave Sherohman <dave@sherohman.org> - 2018-08-17 23:00 +0200
              Re: Fail2Ban Question: Can I do this without restarting the service? cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-17 23:30 +0200
                Re: Fail2Ban Question: Can I do this without restarting the service? Dave Sherohman <dave@sherohman.org> - 2018-08-18 11:00 +0200

Page 1 of 2  [1] 2  Next page →

#198836 — Fail2Ban Question: Can I do this without restarting the service?

I have a list of IP addresses I want to ban and I put them in 
/etc/fail2ban/action.d/iptables-multiport.conf as so:

cat /etc/fail2ban/ip.blacklist.perm | while read IP; do iptables -I 
fail2ban-<name> 1 -s $IP -j DROP; done

(that was supposed to be all on one line, of course)

So, I have read that when you do things this way, you MUST restart 
fail2ban (sudo service fail2ban restart).

Is there a better way to do this? I have a cron job that gathers IP 
addresses that get more than 1,000 hits from the apache log file and 
that gets put in the ip.blacklist.perm file.

I know *nothing* about fail2ban. I just read of this technique via 
Google. But when using Google, I can't find another way to do this that 
doesn't require a restart of the service.

Any ideas on other ways to do this?

[toc] | [next] | [standalone]

#198846

On 8/16/2018 3:29 AM, cyaiplexys wrote:
> I have a list of IP addresses I want to ban and I put them in 
> /etc/fail2ban/action.d/iptables-multiport.conf as so:
> 
> cat /etc/fail2ban/ip.blacklist.perm | while read IP; do iptables -I 
> fail2ban-<name> 1 -s $IP -j DROP; done
> 
> (that was supposed to be all on one line, of course)
> 
> So, I have read that when you do things this way, you MUST restart 
> fail2ban (sudo service fail2ban restart).
> 
> Is there a better way to do this? I have a cron job that gathers IP 
> addresses that get more than 1,000 hits from the apache log file and 
> that gets put in the ip.blacklist.perm file.
> 
> I know *nothing* about fail2ban. I just read of this technique via 
> Google. But when using Google, I can't find another way to do this that 
> doesn't require a restart of the service.
> 
> Any ideas on other ways to do this?
> 

I would use ipset.
Googling "fail2ban ipset" gives some interesting stuff.

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#198857

On 08/16/2018 02:36 AM, john doe wrote:
> On 8/16/2018 3:29 AM, cyaiplexys wrote:
>> I have a list of IP addresses I want to ban and I put them in 
>> /etc/fail2ban/action.d/iptables-multiport.conf as so:
>>
>> cat /etc/fail2ban/ip.blacklist.perm | while read IP; do iptables -I 
>> fail2ban-<name> 1 -s $IP -j DROP; done
>>
>> (that was supposed to be all on one line, of course)
>>
>> So, I have read that when you do things this way, you MUST restart 
>> fail2ban (sudo service fail2ban restart).
>>
>> Is there a better way to do this? I have a cron job that gathers IP 
>> addresses that get more than 1,000 hits from the apache log file and 
>> that gets put in the ip.blacklist.perm file.
>>
>> I know *nothing* about fail2ban. I just read of this technique via 
>> Google. But when using Google, I can't find another way to do this 
>> that doesn't require a restart of the service.
>>
>> Any ideas on other ways to do this?
>>
> 
> I would use ipset.
> Googling "fail2ban ipset" gives some interesting stuff.
> 

Thank you for the magic search term. :) I tried it and found at least 3 
articles I bookmarked for reading.

[toc] | [prev] | [next] | [standalone]

#198860

On 8/16/2018 1:45 PM, cyaiplexys wrote:
> On 08/16/2018 02:36 AM, john doe wrote:
>> On 8/16/2018 3:29 AM, cyaiplexys wrote:
>>> I have a list of IP addresses I want to ban and I put them in 
>>> /etc/fail2ban/action.d/iptables-multiport.conf as so:
>>>
>>> cat /etc/fail2ban/ip.blacklist.perm | while read IP; do iptables -I 
>>> fail2ban-<name> 1 -s $IP -j DROP; done
>>>
>>> (that was supposed to be all on one line, of course)
>>>
>>> So, I have read that when you do things this way, you MUST restart 
>>> fail2ban (sudo service fail2ban restart).
>>>
>>> Is there a better way to do this? I have a cron job that gathers IP 
>>> addresses that get more than 1,000 hits from the apache log file and 
>>> that gets put in the ip.blacklist.perm file.
>>>
>>> I know *nothing* about fail2ban. I just read of this technique via 
>>> Google. But when using Google, I can't find another way to do this 
>>> that doesn't require a restart of the service.
>>>
>>> Any ideas on other ways to do this?
>>>
>>
>> I would use ipset.
>> Googling "fail2ban ipset" gives some interesting stuff.
>>
> 
> Thank you for the magic search term. :) I tried it and found at least 3 
> articles I bookmarked for reading.
> 
To query the status and start/stop/restart the service fail2ban, 
beginning with Debian 8 you would use 'systemd':
$ systemctl status/start/restart/stop fail2ban


Also increasing log verbosity when setting up fail2ban might not hurt.

https://www.digitalocean.com/community/tutorials/how-to-protect-an-apache-server-with-fail2ban-on-ubuntu-14-04

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#198863

On 08/16/2018 09:52 AM, john doe wrote:
> On 8/16/2018 1:45 PM, cyaiplexys wrote:
>> On 08/16/2018 02:36 AM, john doe wrote:
>>> On 8/16/2018 3:29 AM, cyaiplexys wrote:
>>>> I have a list of IP addresses I want to ban and I put them in 
>>>> /etc/fail2ban/action.d/iptables-multiport.conf as so:
>>>>
>>>> cat /etc/fail2ban/ip.blacklist.perm | while read IP; do iptables -I 
>>>> fail2ban-<name> 1 -s $IP -j DROP; done
>>>>
>>>> (that was supposed to be all on one line, of course)
>>>>
>>>> So, I have read that when you do things this way, you MUST restart 
>>>> fail2ban (sudo service fail2ban restart).
>>>>
>>>> Is there a better way to do this? I have a cron job that gathers IP 
>>>> addresses that get more than 1,000 hits from the apache log file and 
>>>> that gets put in the ip.blacklist.perm file.
>>>>
>>>> I know *nothing* about fail2ban. I just read of this technique via 
>>>> Google. But when using Google, I can't find another way to do this 
>>>> that doesn't require a restart of the service.
>>>>
>>>> Any ideas on other ways to do this?
>>>>
>>>
>>> I would use ipset.
>>> Googling "fail2ban ipset" gives some interesting stuff.
>>>
>>
>> Thank you for the magic search term. :) I tried it and found at least 
>> 3 articles I bookmarked for reading.
>>
> To query the status and start/stop/restart the service fail2ban, 
> beginning with Debian 8 you would use 'systemd':
> $ systemctl status/start/restart/stop fail2ban
> 
> 
> Also increasing log verbosity when setting up fail2ban might not hurt.
> 
> https://www.digitalocean.com/community/tutorials/how-to-protect-an-apache-server-with-fail2ban-on-ubuntu-14-04 
> 

The problem is, I want to update things *without* having to restart the 
fail2ban service for ever time I make a change. (I already know now to 
start/stop/restart).

[toc] | [prev] | [next] | [standalone]

#198878

On Wed, Aug 15, 2018 at 09:29:58PM -0400, cyaiplexys wrote:
> Is there a better way to do this? I have a cron job that gathers IP
> addresses that get more than 1,000 hits from the apache log file and that
> gets put in the ip.blacklist.perm file.

If (as the filename implies) you want to block these addresses
permanently, then why are you using a tool designed to manage blocks
dynamically (fail2ban)?  Just use your preferred firewall management
tool to add a rule to block them outside of fail2ban.

For example, I manage my firewalls with ufw, so I would use 'ufw deny
from $IP_ADDR'.  It takes effect instantly, with no need to restart
anything, and will be persistent across reboots.

If you don't actually want them to be permanent, then you could instead
create a fail2ban jail which detects IP addresses which have generated
1000 incoming requests to ports 80/443 within the last 60 minutes (or
whatever timeframe your log analysis script looks at) and bans them for
a week (or however long you like), without needing to wait for the log
analysis script to run first.  And you can also whitelist certain IPs in
the jail config, if there are internal service monitoring machines or
whatever which legitimately generate levels of traffic which would
normally trigger a ban.

-- 
Dave Sherohman

[toc] | [prev] | [next] | [standalone]

#198882

On 08/16/2018 01:00 PM, Dave Sherohman wrote:
> On Wed, Aug 15, 2018 at 09:29:58PM -0400, cyaiplexys wrote:
>> Is there a better way to do this? I have a cron job that gathers IP
>> addresses that get more than 1,000 hits from the apache log file and that
>> gets put in the ip.blacklist.perm file.
> 
> If (as the filename implies) you want to block these addresses
> permanently, then why are you using a tool designed to manage blocks
> dynamically (fail2ban)?  Just use your preferred firewall management
> tool to add a rule to block them outside of fail2ban.
> 
> For example, I manage my firewalls with ufw, so I would use 'ufw deny
> from $IP_ADDR'.  It takes effect instantly, with no need to restart
> anything, and will be persistent across reboots.
> 
> If you don't actually want them to be permanent, then you could instead
> create a fail2ban jail which detects IP addresses which have generated
> 1000 incoming requests to ports 80/443 within the last 60 minutes (or
> whatever timeframe your log analysis script looks at) and bans them for
> a week (or however long you like), without needing to wait for the log
> analysis script to run first.  And you can also whitelist certain IPs in
> the jail config, if there are internal service monitoring machines or
> whatever which legitimately generate levels of traffic which would
> normally trigger a ban.
> 

See, that all is way over my head. I don't understand this stuff as I'm 
pretty much a total beginner in this. Does Debian and Debian based 
systems have the firewall installed and running by default? Are there 
tutorials on how this stuff works?

I hvae no idea how to jail or whatever in fail2ban. Sounds that's what I 
want to do. Detect IP addresses hitting the server 1000 times in an hour 
and then ban those for a good long while (week sounds good). I have no 
clue how to do that. Also don't know how to whitelist.

I've googled. But the articles I've read were so confusing I had no idea 
where to start or what to do.

I wish there was an easy tutorial for doing these things.

[toc] | [prev] | [next] | [standalone]

#198891

On Thu 16 Aug 2018 at 14:07:02 -0400, cyaiplexys wrote:

> On 08/16/2018 01:00 PM, Dave Sherohman wrote:
> > On Wed, Aug 15, 2018 at 09:29:58PM -0400, cyaiplexys wrote:
> > > Is there a better way to do this? I have a cron job that gathers IP
> > > addresses that get more than 1,000 hits from the apache log file and that
> > > gets put in the ip.blacklist.perm file.
> > 
> > If (as the filename implies) you want to block these addresses
> > permanently, then why are you using a tool designed to manage blocks
> > dynamically (fail2ban)?  Just use your preferred firewall management
> > tool to add a rule to block them outside of fail2ban.
> > 
> > For example, I manage my firewalls with ufw, so I would use 'ufw deny
> > from $IP_ADDR'.  It takes effect instantly, with no need to restart
> > anything, and will be persistent across reboots.
> > 
> > If you don't actually want them to be permanent, then you could instead
> > create a fail2ban jail which detects IP addresses which have generated
> > 1000 incoming requests to ports 80/443 within the last 60 minutes (or
> > whatever timeframe your log analysis script looks at) and bans them for
> > a week (or however long you like), without needing to wait for the log
> > analysis script to run first.  And you can also whitelist certain IPs in
> > the jail config, if there are internal service monitoring machines or
> > whatever which legitimately generate levels of traffic which would
> > normally trigger a ban.
> > 
> 
> See, that all is way over my head. I don't understand this stuff as I'm
> pretty much a total beginner in this. Does Debian and Debian based systems
> have the firewall installed and running by default? Are there tutorials on

Debian? No.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#198941

On Thu, Aug 16, 2018 at 02:07:02PM -0400, cyaiplexys wrote:
> See, that all is way over my head. I don't understand this stuff as I'm
> pretty much a total beginner in this.

OK, fair enough.  Let's see what help I can offer.

> Does Debian and Debian based systems have the firewall installed and
> running by default?

No.  For general-purpose firewalling, I would suggest installing ufw
(`sudo apt-get install ufw`), as it's much simpler to manage than using
iptables (the underlying firewall control scheme used by both ufw and
fail2ban to communicate with the kernel) directly.

After installing ufw, the following commands should get you started (all
of them need to be run with sudo or from a root shell):

ufw allow to any port 22 from [your IP address] proto tcp
(If you're using ssh to connect to the server, you *must* do this one
before enabling the firewall, or else you'll lock yourself out.  If you
need to connect with ssh from multiple addresses, you can either run it
multiple times with different addresses, or specify a network in CIDR
notation.)

ufw enable
(Starts the firewall.)

ufw logging off
(...because it will otherwise flood your logs with reports of pretty
much every packet recieved on the network interface.)

ufw allow 80,443/tcp
(Opens port 80 (http) and 443 (https) for connections from anywhere on
the internet.)

Repeat the last one with the appropriate port numbers for any other
service that you want to make publicly available.

> I hvae no idea how to jail or whatever in fail2ban. Sounds that's what I
> want to do. Detect IP addresses hitting the server 1000 times in an hour and
> then ban those for a good long while (week sounds good).

That's pretty much exactly what fail2ban is intended to do.  A "jail" is
just fail2ban's term for a rule for what activities aren't allowed and
how to handle IP addresses which break the rule.

Unfortunately, adding a custom jail requires changes to multiple files,
but I can at least give you specific details on how to create this
particular one.  Again, these files need to be created or edited using
sudo or from a root shell.

First, you need to create a filter definition.  Create the file
/etc/fail2ban/filter.d/apache-missing-local.conf containing:

---
[Definition]
failregex = <HOST> [^ ]+ [^ ]+ \[[^]]+\] "[^"]+" 40[04] [0-9]+
---

Lines matching the failregex (an apache log line for a 404 error) count
as "failures".

Next, you need to define a jail which uses that filter.  Create the file
/etc/fail2ban/jail.local (or edit it if it exists, but I don't think it
exists by default) and add:

---
[apache-missing-local]
enabled  = true
port     = http,https
filter   = apache-missing-local
logpath  = /var/log/apache2/*access*.log
maxretry = 1000
findtime = 3600
bantime  = 604800
ignoreip = 127.0.0.1
---

'port' is the list of ports to block when an address is put in the jail.
'logpath' is the list of logfiles to monitor for offending entries (in
this case, all log files in /var/log/apache2 with "access" in their
names).  'maxretry' is the number of times an address can break the rule
before getting jailed.  'findtime' is how long (in seconds, 3600 = 1
hour) the retries are remembered.  And 'bantime' is how long (in
seconds again, 604800 = 1 week) the address should remain jailed before
it is released and allowed to access your service again.  'ignoreip' is
a list of IP addresses which should never be blocked.

After setting up these files, you can either restart fail2ban or run
`sudo fail2ban-client reload` to activate the new jail.

> I wish there was an easy tutorial for doing these things.

It would be nice, yes.  I've figured out everything in this mail by
reading man pages and examining the existing config files.  Good
tutorials would have made that a lot easier.

-- 
Dave Sherohman

[toc] | [prev] | [next] | [standalone]

#198945

On 08/17/2018 10:55 AM, Dave Sherohman wrote:
> On Thu, Aug 16, 2018 at 02:07:02PM -0400, cyaiplexys wrote:
>> See, that all is way over my head. I don't understand this stuff as I'm
>> pretty much a total beginner in this.
> 
> OK, fair enough.  Let's see what help I can offer.

Greatly appreciated. :)

>> Does Debian and Debian based systems have the firewall installed and
>> running by default?
> 
> No.  For general-purpose firewalling, I would suggest installing ufw
> (`sudo apt-get install ufw`), as it's much simpler to manage than using
> iptables (the underlying firewall control scheme used by both ufw and
> fail2ban to communicate with the kernel) directly.
> 
> After installing ufw, the following commands should get you started (all
> of them need to be run with sudo or from a root shell):

If I'm following you so far, ufw is a firewall like iptables? Or a 
replacement for iptables?

> ufw allow to any port 22 from [your IP address] proto tcp
> (If you're using ssh to connect to the server, you *must* do this one
> before enabling the firewall, or else you'll lock yourself out. 

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?

 > If you need to connect with ssh from multiple addresses, you can
 > either run it multiple times with different addresses, or specify a
 > network in CIDR notation.)

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.

> ufw enable
> (Starts the firewall.)
> 
> ufw logging off
> (...because it will otherwise flood your logs with reports of pretty
> much every packet recieved on the network interface.)
> 
> ufw allow 80,443/tcp
> (Opens port 80 (http) and 443 (https) for connections from anywhere on
> the internet.)
 > Repeat the last one with the appropriate port numbers for any other
 > service that you want to make publicly available.

Can I do this too?

ufw deny 22/tcp # Deny connection to port 22 (ssh default port)
ufw allow [new-ssh-port]/tcp # Allow connection to new chosen ssh port

>> I hvae no idea how to jail or whatever in fail2ban. Sounds that's what I
>> want to do. Detect IP addresses hitting the server 1000 times in an hour and
>> then ban those for a good long while (week sounds good).
> 
> That's pretty much exactly what fail2ban is intended to do.  A "jail" is
> just fail2ban's term for a rule for what activities aren't allowed and
> how to handle IP addresses which break the rule.
> 
> Unfortunately, adding a custom jail requires changes to multiple files,
> but I can at least give you specific details on how to create this
> particular one.  Again, these files need to be created or edited using
> sudo or from a root shell.
> 
> First, you need to create a filter definition.  Create the file
> /etc/fail2ban/filter.d/apache-missing-local.conf containing:
> 
> ---
> [Definition]
> failregex = <HOST> [^ ]+ [^ ]+ \[[^]]+\] "[^"]+" 40[04] [0-9]+
> ---
> 
> Lines matching the failregex (an apache log line for a 404 error) count
> as "failures".

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).

> Next, you need to define a jail which uses that filter.  Create the file
> /etc/fail2ban/jail.local (or edit it if it exists, but I don't think it
> exists by default) and add:
>
> ---
> [apache-missing-local]
> enabled  = true
> port     = http,https
> filter   = apache-missing-local
> logpath  = /var/log/apache2/*access*.log
> maxretry = 1000
> findtime = 3600
> bantime  = 604800
> ignoreip = 127.0.0.1
> ---

Aha! THIS makes sense to me now! :)

> 'port' is the list of ports to block when an address is put in the jail.
> 'logpath' is the list of logfiles to monitor for offending entries (in
> this case, all log files in /var/log/apache2 with "access" in their
> names).  'maxretry' is the number of times an address can break the rule
> before getting jailed.  'findtime' is how long (in seconds, 3600 = 1
> hour) the retries are remembered.  And 'bantime' is how long (in
> seconds again, 604800 = 1 week) the address should remain jailed before
> it is released and allowed to access your service again.

That I will need to be like a larger amount, like several months? 
*reaching for my calculator*.

> 'ignoreip' is a list of IP addresses which should never be blocked.

Can I separate a list with commas like done for port?

> After setting up these files, you can either restart fail2ban or run
> `sudo fail2ban-client reload` to activate the new jail.

When using 'reload', does that just ensure changes take effect *without* 
restarting fail2bain service, right?

>> I wish there was an easy tutorial for doing these things.
> 
> It would be nice, yes.  I've figured out everything in this mail by
> reading man pages and examining the existing config files.  Good
> tutorials would have made that a lot easier.

You are very talented if you can make sense of man pages. I digress. I 
have used Linux since Slackware 1.0 (been through Red Had, 
Mandriva/Manjaro, Mint, SolydX/K, and now sticking with Debian but also 
use Ubuntu servers from time to time (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 am trying to get 
something going with Debian too, though so I do need the Debian way to 
do things as well.

Thank you for all the info and helping me out. I now think I am 'getting 
it' (please feel free to correct my errors so I make sure I'm on the 
right track).

[toc] | [prev] | [next] | [standalone]

#198946

On 8/17/2018 6:50 PM, cyaiplexys wrote:
> On 08/17/2018 10:55 AM, Dave Sherohman wrote:
>> On Thu, Aug 16, 2018 at 02:07:02PM -0400, cyaiplexys wrote:
>>> See, that all is way over my head. I don't understand this stuff as I'm
>>> pretty much a total beginner in this.
>>
>> OK, fair enough.  Let's see what help I can offer.
> 
> Greatly appreciated. :)
> 
>>> Does Debian and Debian based systems have the firewall installed and
>>> running by default?
>>
>> No.  For general-purpose firewalling, I would suggest installing ufw
>> (`sudo apt-get install ufw`), as it's much simpler to manage than using
>> iptables (the underlying firewall control scheme used by both ufw and
>> fail2ban to communicate with the kernel) directly.
>>
>> After installing ufw, the following commands should get you started (all
>> of them need to be run with sudo or from a root shell):
> 
> If I'm following you so far, ufw is a firewall like iptables? Or a 
> replacement for iptables?
> 

No -- ufw is a "front end" to iptables.
Ufw is easy to configure and will translate to a format understood by 
iptables.

In other words, "iptables" is the firewall and UFW, Shorewall ... allows 
you to control that wall between you and the internet.

Also, a server without firewall capibility should never be facing internet.

>> ufw allow to any port 22 from [your IP address] proto tcp
>> (If you're using ssh to connect to the server, you *must* do this one
>> before enabling the firewall, or else you'll lock yourself out. 
> 
> 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 following line change 22 to the port of your liking.

ufw allow to any port 22 from [your IP address] proto tcp

Also, port numbers are codified.
I would suggest you to stick with that codification.

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

>  > If you need to connect with ssh from multiple addresses, you can
>  > either run it multiple times with different addresses, or specify a
>  > network in CIDR notation.)
> 
> 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. >> ufw enable
>> (Starts the firewall.)
>>
>> ufw logging off
>> (...because it will otherwise flood your logs with reports of pretty
>> much every packet recieved on the network interface.)
>>
>> ufw allow 80,443/tcp
>> (Opens port 80 (http) and 443 (https) for connections from anywhere on
>> the internet.)
>  > Repeat the last one with the appropriate port numbers for any other
>  > service that you want to make publicly available.
> 
> Can I do this too?
> 
> ufw deny 22/tcp # Deny connection to port 22 (ssh default port)
> ufw allow [new-ssh-port]/tcp # Allow connection to new chosen ssh port
> 

In general, Any ports that are not opend are closed!

Note that I don't know ufw or iptables per say.

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#198947

On Fri 17 Aug 2018 at 19:16:07 +0200, john doe wrote:

> Also, a server without firewall capibility should never be facing internet.

Why? "never" seems a little strong. Mine does; what's the problem?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#198977

On 8/17/2018 7:35 PM, Brian wrote:
> On Fri 17 Aug 2018 at 19:16:07 +0200, john doe wrote:
> 
>> Also, a server without firewall capibility should never be facing internet.
> 
> Why? "never" seems a little strong. Mine does; what's the problem?
> 

Given the fact that the OP want's to use fail2ban and has at least two 
services running on his public host (apache, ssh) it was a reasonable 
guess to stress out that a firewall is a must in his situation.

I can not talk about your server configuration because I don't know 
anything about it! :)

In general, the requirements for firewalling a public host depends on 
the environment and other factors.
Googling this topick will show that there is no formal answer.

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#198980

	Hi.

On Sat, Aug 18, 2018 at 05:55:50PM +0200, john doe wrote:
> On 8/17/2018 7:35 PM, Brian wrote:
> > On Fri 17 Aug 2018 at 19:16:07 +0200, john doe wrote:
> > 
> > > Also, a server without firewall capibility should never be facing internet.
> > 
> > Why? "never" seems a little strong. Mine does; what's the problem?
> > 
> 
> Given the fact that the OP want's to use fail2ban and has at least two
> services running on his public host (apache, ssh) it was a reasonable guess
> to stress out that a firewall is a must in his situation.
> 
> I can not talk about your server configuration because I don't know anything
> about it! :)
> 
> In general, the requirements for firewalling a public host depends on the
> environment and other factors.
> Googling this topick will show that there is no formal answer.

There is. Google for "TCP RST flood".

Reco

[toc] | [prev] | [next] | [standalone]

#198986

On Sat 18 Aug 2018 at 17:55:50 +0200, john doe wrote:

> On 8/17/2018 7:35 PM, Brian wrote:
> > On Fri 17 Aug 2018 at 19:16:07 +0200, john doe wrote:
> > 
> > > Also, a server without firewall capibility should never be facing internet.
> > 
> > Why? "never" seems a little strong. Mine does; what's the problem?
> > 
> 
> Given the fact that the OP want's to use fail2ban and has at least two
> services running on his public host (apache, ssh) it was a reasonable guess
> to stress out that a firewall is a must in his situation.

There it is again - "must".
> 
> I can not talk about your server configuration because I don't know anything
> about it! :)

exim on port 25; openssh-server on port 22. Never used netfilter.

> In general, the requirements for firewalling a public host depends on the
> environment and other factors.
> Googling this topick will show that there is no formal answer.

The penultimate sentence more or less accords with my view too. In other
words - there is no "must" about it.

--  
Brian.

[toc] | [prev] | [next] | [standalone]

#198949

On Fri 17 Aug 2018 at 13:56:03 -0400, cyaiplexys wrote:

> So do I have to sudo apt-get iptables or is that already installed?

dpkg -l iptables

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#198952

On 08/17/2018 01:59 PM, Brian wrote:
> On Fri 17 Aug 2018 at 13:56:03 -0400, cyaiplexys wrote:
> 
>> So do I have to sudo apt-get iptables or is that already installed?
> 
> dpkg -l iptables

Looks like it's in there:

$ dpkg -l iptables
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name               Version        Architecture   Description
+++-==================-==============-==============-=========================================
ii  iptables           1.6.0+snapshot amd64          administration 
tools for packet filtering

Debian 9.5 Stretch.

[toc] | [prev] | [next] | [standalone]

#198950

On 08/17/2018 01:16 PM, john doe wrote:
> On 8/17/2018 6:50 PM, cyaiplexys wrote:
>> On 08/17/2018 10:55 AM, Dave Sherohman wrote:
>>> On Thu, Aug 16, 2018 at 02:07:02PM -0400, cyaiplexys wrote:
>>>> See, that all is way over my head. I don't understand this stuff as I'm
>>>> pretty much a total beginner in this.
>>>
>>> OK, fair enough.  Let's see what help I can offer.
>>
>> Greatly appreciated. :)
>>
>>>> Does Debian and Debian based systems have the firewall installed and
>>>> running by default?
>>>
>>> No.  For general-purpose firewalling, I would suggest installing ufw
>>> (`sudo apt-get install ufw`), as it's much simpler to manage than using
>>> iptables (the underlying firewall control scheme used by both ufw and
>>> fail2ban to communicate with the kernel) directly.
>>>
>>> After installing ufw, the following commands should get you started (all
>>> of them need to be run with sudo or from a root shell):
>>
>> If I'm following you so far, ufw is a firewall like iptables? Or a 
>> replacement for iptables?
>>
> 
> No -- ufw is a "front end" to iptables.
> Ufw is easy to configure and will translate to a format understood by 
> iptables.
> 
> In other words, "iptables" is the firewall and UFW, Shorewall ... allows 
> you to control that wall between you and the internet.
> 
> Also, a server without firewall capibility should never be facing internet.

So do I have to sudo apt-get iptables or is that already installed?

[other very useful stuff snipped...]

[toc] | [prev] | [next] | [standalone]

#198951

On Fri 17 Aug 2018 at 12:50:16 -0400, cyaiplexys wrote:

> 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?

Not a bad tactic; can keep the logs clean. Doesn't do much for security,
of course.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#198961

On Fri, Aug 17, 2018 at 12:50:16PM -0400, cyaiplexys wrote:
> If I'm following you so far, ufw is a firewall like iptables? Or a
> replacement for iptables?

ufw is a more user-friendly front end for managing iptables rules.
Under the hood, it's still iptables doing the actual firewalling.
(After ufw is activated, you can use iptables -L to see the rules
created by both ufw and fail2ban if you're curious.  But be warned, they
will be voluminous and may become rather complex, since they're not
meant for human consumption.)

> >ufw allow to any port 22 from [your IP address] proto tcp
> >(If you're using ssh to connect to the server, you *must* do this one
> >before enabling the firewall, or else you'll lock yourself out.
> 
> 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.

> > If you need to connect with ssh from multiple addresses, you can
> > either run it multiple times with different addresses, or specify a
> > network in CIDR notation.)
> 
> 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.

> 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.

> 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.)

> 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

---
[Definition]
failregex = ^<HOST> -.*\"(GET|POST).*
ignoreregex = ^ -.*^<HOST> -.*\"(GET|POST).*Googlebot
---

This will match all GET and POST requests (even though the filter name
just says "get"... I forgot to change the name when I added POSTs),
unless they're coming from a Googlebot user agent (because it's a public
server with several hundred thousand pages which we do want indexed).

The corresponding jail definition is:

---
[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/apache*/*access.log
maxretry = 600
findtime = 300
bantime = 600
ignoreip = 10.0.0.0/8
---

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.  Banning for
months at a time is unlikely to be necessary unless you're dealing with
a targeted attack.

> >'ignoreip' is a list of IP addresses which should never be blocked.
> 
> Can I separate a list with commas like done for port?

fail2ban uses space-separated lists rather than comma-separated.  Aside
from that, though, yes, you can list as many addresses as you like.
e.g.,

ignoreip = 8.8.8.8 127.0.0.1

> >After setting up these files, you can either restart fail2ban or run
> >`sudo fail2ban-client reload` to activate the new jail.
> 
> When using 'reload', does that just ensure changes take effect *without*
> restarting fail2bain service, right?

Correct

> (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.


-- 
Dave Sherohman

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web