Hi, I've recently created a package for SSHGuard [1]. SSHGuard is a program to block brute-force attacks on SSH and other services, similar to fail2ban/etc.
Now, my issue is the following:
- SSHGuard is completely agnostic with respect to the firewall-backend it uses and the logs it reads. Accordingly, it ships with an example config file that does not set either backend or logreader, the user has to do that themselves. There are, however, commented example lines configuring iptables + journald. - Fedora, obviously, by default uses firewalld and journald.
What is the guideline for packaging software like this: 1) Leave it as upstream ships it. - user will have to configure the package before it becomes functional - no dependency on any non-essential packages 2) ship example config file as real config file, with upstream's example config activated - package works out-of-the-box - introduces additional, non-default dependency (iptables) 3) ship custom config file preconfigured for Fedora defaults - package works out-of-the-box - introduces dependency on default Fedora packages (firewalld)
Granted, option (2) is rather silly, but is (1) or (3) the correct way to go about configuring the package?
Best, Christopher
[1] https://copr.fedorainfracloud.org/coprs/lcts/sshguard/ [2] https://www.sshguard.net/
On Sat, Oct 06, 2018 at 12:54:30PM +0200, Christopher Engelhard wrote:
Hi, I've recently created a package for SSHGuard [1]. SSHGuard is a program to block brute-force attacks on SSH and other services, similar to fail2ban/etc.
Now, my issue is the following:
- SSHGuard is completely agnostic with respect to the firewall-backend
it uses and the logs it reads. Accordingly, it ships with an example config file that does not set either backend or logreader, the user has to do that themselves. There are, however, commented example lines configuring iptables + journald.
- Fedora, obviously, by default uses firewalld and journald.
What is the guideline for packaging software like this:
- Leave it as upstream ships it.
- user will have to configure the package before it becomes functional
- no dependency on any non-essential packages
- ship example config file as real config file, with upstream's example config activated
- package works out-of-the-box
- introduces additional, non-default dependency (iptables)
- ship custom config file preconfigured for Fedora defaults
- package works out-of-the-box
- introduces dependency on default Fedora packages (firewalld)
Granted, option (2) is rather silly, but is (1) or (3) the correct way to go about configuring the package?
Best, Christopher
[1] https://copr.fedorainfracloud.org/coprs/lcts/sshguard/ [2] https://www.sshguard.net/
TL;DR: I think option (3) would be the best.
IMHO (I'm still thinking about packaging stuff for Fedora, haven't even submitted a single package for review yet, although I have some ideas, so take all of this as coming from kind of an outsider looking in, albeit an outsider with some experience with other packaging systems), the point of all of the OS package collections and all the different distributions is to make software available for the users with several conditions satisfied: - the piece of software is adapted to match the way other pieces of software packaged in the same system will behave - all the other pieces of software that this one needs are already packaged and adapted in that way - the piece of software has been compiled/byte-compiled/installed so that the user does not have to bother to figure out how to install and run the build tools
Once upon a time, back in 1996, it seemed that the third point was the most important: packaged software saved you the trouble of 1. running around fetching all sorts of compilers and stuff, and 2. waiting around for them to do their job. Gradually, however, I came to the realization that the *main* reason I use packaged software has actually always been the way it all works together smoothly and seamlessly, the way all the configuration files are in the same directories, all the databases are in the same tree, all the startup scripts are enabled, disabled, or configured in the same way, etc. The way that I can install several packages, some of them related to some of the others, but some of them completely unrelated, and be more-or-less assured that all of them will work out of the box without the need for me to configure almost anything (except maybe enable some things, but that, too, is done in the same way for all of them).
And, yes, when in my work or leisure time I have to work with servers or personal laptops with different OSs and different Linux distributions installed, sometimes I do need a moment to remember just how things are done *here*; still, all in all, IMHO this is a minor annoyance as compared to the great benefits of consistency within a single OS/distribution/packaging system.
So, yeah, to finally come back to your question, IMHO it would be best for SSHGuard to work out of the box with Fedora's firewall package.
G'luck, Peter
Hi, Christopher. Thanks for asking this question. It's a good one.
On Saturday, 06 October 2018 at 12:54, Christopher Engelhard wrote:
Hi, I've recently created a package for SSHGuard [1]. SSHGuard is a program to block brute-force attacks on SSH and other services, similar to fail2ban/etc.
Now, my issue is the following:
- SSHGuard is completely agnostic with respect to the firewall-backend
it uses and the logs it reads. Accordingly, it ships with an example config file that does not set either backend or logreader, the user has to do that themselves. There are, however, commented example lines configuring iptables + journald.
- Fedora, obviously, by default uses firewalld and journald.
What is the guideline for packaging software like this:
- Leave it as upstream ships it.
- user will have to configure the package before it becomes functional
- no dependency on any non-essential packages
- ship example config file as real config file, with upstream's example config activated
- package works out-of-the-box
- introduces additional, non-default dependency (iptables)
Ship this configuration in a subpackage (sshguard-iptables). Use rich dependencies to have it auto-installed if iptables-services is installed.
- ship custom config file preconfigured for Fedora defaults
- package works out-of-the-box
- introduces dependency on default Fedora packages (firewalld)
Ship this configuration in a subpackage (sshguard-firewalld). Use rich dependencies to have it auto-installed if firewalld is installed.
Granted, option (2) is rather silly,
It's not silly if it's optional.
but is (1) or (3) the correct way to go about configuring the package?
(3) is the best option if you want to do as little work as possible but still create a seamless experience for the default case. With a little more work, you can make users of non-default configurations (like myself) happy(-ier).
PS. What's wrong with fail2ban?
Regards, Dominik
Hi Dominik,
On 10/8/18 12:39 AM, Dominik 'Rathann' Mierzejewski wrote:
Ship this configuration in a subpackage (sshguard-iptables). Use rich dependencies to have it auto-installed if iptables-services is installed.
Ship this configuration in a subpackage (sshguard-firewalld). Use rich dependencies to have it auto-installed if firewalld is installed.
That is a great idea, thank you. I'll do that.
PS. What's wrong with fail2ban?
Nothing, I just happen to have been using SSHGuard on my systems before recently shifting to Fedora, and if I'm going to be creating packages for my own use, I might as well do it properly and put them at least on COPR for others to benefit from.
(TL;DR: fail2ban can do almost anything you want it to do, but if you don't need that much flexibility, SSHGuard does the job just as well and is much more straightforward to use.)
More substantively, fail2ban is a lot more flexible in what it can match and how to treat matches, with it's different jails etc., plus you can write your own matching rules. However, due to that flexibility, it is rather more complex to configure & manage, even if you don't start writing your own matches, precisely due to the separate jails etc and multiple levels of local, per-jail and global config.
SSHGuard, on the other hand, does not offer any of that, matching rules are compiled in and there is one global jail for all offenders on all services. It is, however, extremely easy to configure and can work with pretty much any firewall and read from any log source you want it to. What is monitored is configured by what you give it to read (e.g. via journalctl -t/-u options), which I find a rather elegant way doing it.
Personally, I need none of the fine-grained control fail2ban offers, so I prefer SSHGuard's simplicity.
Best wishes, Christopher
Hi, one more question about the subpackage approach
On 10/8/18 12:39 AM, Dominik 'Rathann' Mierzejewski wrote:
- ship example config file as real config file, with upstream's example config activated
Ship this configuration in a subpackage (sshguard-iptables). Use rich dependencies to have it auto-installed if iptables-services is installed.
- ship custom config file preconfigured for Fedora defaults
Ship this configuration in a subpackage (sshguard-firewalld). Use rich dependencies to have it auto-installed if firewalld is installed.
This implies that the spec contains multiple /etc/sshguard.conf files. I can ship them as %doc sshguard.conf.<backend>, and then cp them to sshguard.conf during %post <subpackage>, but then no package would own that file, right?
I can of course create separate packages with separate spec files for the config, but can this also be made to work with subpackages?
Best, Christopher
On Thursday, 11 October 2018 at 09:42, Christopher Engelhard wrote:
Hi, one more question about the subpackage approach
On 10/8/18 12:39 AM, Dominik 'Rathann' Mierzejewski wrote:
- ship example config file as real config file, with upstream's example config activated
Ship this configuration in a subpackage (sshguard-iptables). Use rich dependencies to have it auto-installed if iptables-services is installed.
- ship custom config file preconfigured for Fedora defaults
Ship this configuration in a subpackage (sshguard-firewalld). Use rich dependencies to have it auto-installed if firewalld is installed.
This implies that the spec contains multiple /etc/sshguard.conf files. I can ship them as %doc sshguard.conf.<backend>, and then cp them to sshguard.conf during %post <subpackage>, but then no package would own that file, right?
You can use %ghost to own a file that is created in %post or at runtime. Also, there's no problem if two conflicting packages own the same file.
I can of course create separate packages with separate spec files for the config, but can this also be made to work with subpackages?
Take a look at the coreutils package for one way to do it from a single spec file.
Regards, Dominik
Am Do., 11. Okt. 2018 um 09:57 Uhr schrieb Dominik 'Rathann' Mierzejewski dominik@greysector.net:
On Thursday, 11 October 2018 at 09:42, Christopher Engelhard wrote:
This implies that the spec contains multiple /etc/sshguard.conf files. I can ship them as %doc sshguard.conf.<backend>, and then cp them to sshguard.conf during %post <subpackage>, but then no package would own that file, right?
You can use %ghost to own a file that is created in %post or at runtime. Also, there's no problem if two conflicting packages own the same file.
But be aware that packages might be installed omitting docs, and thus that copying step would fail.
Regards, Thomas
On Thu, Oct 11, 2018 at 3:43 AM Christopher Engelhard ce@lcts.de wrote:
Hi, one more question about the subpackage approach
On 10/8/18 12:39 AM, Dominik 'Rathann' Mierzejewski wrote:
- ship example config file as real config file, with upstream's example config activated
Ship this configuration in a subpackage (sshguard-iptables). Use rich dependencies to have it auto-installed if iptables-services is installed.
- ship custom config file preconfigured for Fedora defaults
Ship this configuration in a subpackage (sshguard-firewalld). Use rich dependencies to have it auto-installed if firewalld is installed.
This implies that the spec contains multiple /etc/sshguard.conf files. I can ship them as %doc sshguard.conf.<backend>, and then cp them to sshguard.conf during %post <subpackage>, but then no package would own that file, right?
I can of course create separate packages with separate spec files for the config, but can this also be made to work with subpackages?
You can use "RemovePathPostfixes" to make it so they install properly. This avoids the scriptlet messiness and should work as intended for everything.
There are a couple of examples I'm aware of, but one that's in Fedora that I know of is curl: https://src.fedoraproject.org/rpms/curl/blob/master/f/curl.spec
Hi,
On 10/16/18 9:51 PM, Neal Gompa wrote:
You can use "RemovePathPostfixes" to make it so they install properly.
That is an awesome feature that I didn't know about. I'll use that.
There are a couple of examples I'm aware of, but one that's in Fedora that I know of is curl: https://src.fedoraproject.org/rpms/curl/blob/master/f/curl.spec
Also used by coreutils as suggested by Dominik earlier.
Thank you all for your help, Christopher
I've incorporated the subpackages as you suggested, works flawlessly, thanks again.
I've also added an nftables backend, so now there is a subpackage for every firewall backend that both SSHGuard and Fedora support. The package now also builds for el6/7 (minus the subpackages, because RPM in CentOS/RHEL doesn't support suffix-stripping or boolean/weak dependencies yet), but I haven't tested those yet.
(For now, this version is in a testing copr repo [1] and in the testing branch of my git [2]).
One more question: with nftables and firewalld backends, sshguard does all the fw configuration on its own, for iptables the user has to manually configure some chains/rules. Is this something the package can do automatically on install/uninstall or is messing with another package's config (the firewall, no less) in this way a no go? For now, I'm just printing a message telling the user what to do, but it is a fairly harmless modification: It just creates a sshguard chain that everything gets passed through, all other modifications happen inside that chain, so flushing/deleting that chain should return the fw to its original state.
Best, Christopher
[1] https://copr.fedorainfracloud.org/coprs/lcts/sshguard-testing/ [2] https://gitlab.com/lcts/sshguard-rpm/tree/testing
packaging@lists.fedoraproject.org
-
Christopher Engelhard -
Dominik 'Rathann' Mierzejewski -
Neal Gompa -
Peter Pentchev -
Thomas Moschny