I want to install denyhosts, but I currently am using stock f21 install (without rsyslogd). Will this work?
On Sat, Mar 28, 2015 at 01:47:25PM -0400, Neal Becker wrote:
I want to install denyhosts, but I currently am using stock f21 install (without rsyslogd). Will this work?
I don't think so, no. However, you might look at switching to fail2ban, which can.
On 03/28/2015 02:01 PM, Patrick O'Callaghan wrote:
On Sat, 2015-03-28 at 13:47 -0400, Neal Becker wrote:
I want to install denyhosts, but I currently am using stock f21 install (without rsyslogd). Will this work?
Just install rsyslog with yum. It will run via systemd and denyhosts works fine.
If denyhosts needs rsyslogd, shouldn't it be a dependency?
Hi
On Sat, Mar 28, 2015 at 5:14 PM, Joe Zeff wrote:
If denyhosts needs rsyslogd, shouldn't it be a dependency?
It doesn't need rsyslogd specifically. A virtual dependency on syslog with multiple providers including rsyslogd and syslog-ng might be a possible solution. However denyhosts itself is pretty outdated and everyone should switch over to fail2ban anyway.
Rahul
On Sat, 2015-03-28 at 23:22 -0400, Rahul Sundaram wrote:
Hi
On Sat, Mar 28, 2015 at 5:14 PM, Joe Zeff wrote:
If denyhosts needs rsyslogd, shouldn't it be a dependency?
It doesn't need rsyslogd specifically. A virtual dependency on syslog with multiple providers including rsyslogd and syslog-ng might be a possible solution. However denyhosts itself is pretty outdated and everyone should switch over to fail2ban anyway.
I just did so, but I found fail2ban significantly harder to configure, largely because there's no explicit documentation on what the default configuration is on install. You have to read the config files and figure it out from the man pages, which suffer from the same fault as many such pages, i.e. they are written for people who already know how it all works and just need a reminder. One example: the term 'jail' is used without ever being defined, and in a way inconsistent with other uses in Linux such as 'root jail'.
In the end I just had to add a simple jail.local file, but it took a while to discover that.
Denyhosts was much easier IIRC.
poc
On 29.03.2015 18:53, Patrick O'Callaghan wrote:
On Sat, 2015-03-28 at 23:22 -0400, Rahul Sundaram wrote:
Hi
On Sat, Mar 28, 2015 at 5:14 PM, Joe Zeff wrote:
If denyhosts needs rsyslogd, shouldn't it be a dependency?
It doesn't need rsyslogd specifically. A virtual dependency on syslog with multiple providers including rsyslogd and syslog-ng might be a possible solution. However denyhosts itself is pretty outdated and everyone should switch over to fail2ban anyway.
I just did so, but I found fail2ban significantly harder to configure, largely because there's no explicit documentation on what the default configuration is on install. You have to read the config files and figure it out from the man pages, which suffer from the same fault as many such pages, i.e. they are written for people who already know how it all works and just need a reminder. One example: the term 'jail' is used without ever being defined, and in a way inconsistent with other uses in Linux such as 'root jail'.
In the end I just had to add a simple jail.local file, but it took a while to discover that.
Denyhosts was much easier IIRC.
poc
Once you're done, make the instructions in the form of a examples, put it in a patch and send upstream. If upstream doesn't pull propose to downstream. If downstream doesn't pull, make a note here on the list.
On Sun, Mar 29, 2015 at 07:26:08PM +0200, poma wrote:
largely because there's no explicit documentation on what the default configuration is on install. You have to read the config files and figure it out from the man pages, which suffer from the same fault as many such pages, i.e. they are written for people who already know how it all works and just need a reminder. One example: the term 'jail' is used without ever being defined, and in a way inconsistent with other uses in Linux such as 'root jail'. In the end I just had to add a simple jail.local file, but it took a while to discover that. Denyhosts was much easier IIRC.
Once you're done, make the instructions in the form of a examples, put it in a patch and send upstream. If upstream doesn't pull propose to downstream. If downstream doesn't pull, make a note here on the list.
Yeah, this would be really helpful. Or even a blog post, or something on Ask Fedora or Unix & Linux Stackexchange. Another suggestion would be to file a Fedora bug to include a simple "README.fedora" explaining the default config as shipped + a simple quickstart.
On Mon, 2015-03-30 at 08:45 -0400, Matthew Miller wrote:
On Sun, Mar 29, 2015 at 07:26:08PM +0200, poma wrote:
largely because there's no explicit documentation on what the default configuration is on install. You have to read the config files and figure it out from the man pages, which suffer from the same fault as many such pages, i.e. they are written for people who already know how it all works and just need a reminder. One example: the term 'jail' is used without ever being defined, and in a way inconsistent with other uses in Linux such as 'root jail'. In the end I just had to add a simple jail.local file, but it took a while to discover that. Denyhosts was much easier IIRC.
Once you're done, make the instructions in the form of a examples, put it in a patch and send upstream. If upstream doesn't pull propose to downstream. If downstream doesn't pull, make a note here on the list.
Yeah, this would be really helpful. Or even a blog post, or something on Ask Fedora or Unix & Linux Stackexchange. Another suggestion would be to file a Fedora bug to include a simple "README.fedora" explaining the default config as shipped + a simple quickstart.
I'll consider it, but my point is really about the documentation. The specific (very simple) change I had to make is already mentioned as a comment in one of the config files. My problem was in understanding the terminology so I knew what to do. In no way do I claim to have understood more than the minimum required for my specific needs (which were to monitor possible intrusions via ssh). As regards the rest, as far as I can tell the default config doesn't actually block anything at all, but I could be completely wrong.
poc