Services should be configurable
Issue #80
open
The new SSHGuard service introduced in commit 948727c may cause trouble on non-systemd journaled systems when pointing SSHGuard to the syslog. There isn’t really anything we can do about this other than change the log target to a custom file, or more appropriately – make services configurable and start disabling services by default.
Comments (21)
-
-
reporter
That is indeed the issue. However, I don't believe that any of the current services rely on reading the syslog. So it's not yet a problem.
-
Well, usually syslog output is configured to go into a file (e.g. the "auth.info;authpriv.info /var/log/auth.log" line in my syslog.conf). SSHGuard would be configured to logtail from auth.log, which is also where SSHGuard's output is going.
-
reporter
-
reporter
Oh, this is easier than I thought it would be. Pending a fully configurable and modular parser system (version 3.0?), this will do:
1) Parse configurable list of enabled services, map them to service numbers
2) Check parsed_attack.service against list of enabled services (or maybe list of disable services?)
3)
continue;if service shouldn’t be handled4) Disable the SSHGUARD and CLF_PROBES by default, enable everything else. They’ll still be parsed, but not acted upon (or even logged) by the blocker.
-
Sounds like a good approach to me.
-
reporter
I can knock this out in a couple of minutes if services can be configured by their weird internal service number. That being said, intuitive human readable names are more user friendly than arbitrary numbers.
Mapping internal numbers to strings would add unwanted complexity. I can’t see that there would be any particular reason why the services are defined as numbers instead of strings.
-
reporter
Another approach — which is quite a bit easier, more maintainable, and more flexible — is to offer a configurable log source (identified by the syslog banner) filtering system. This isn’t needed for os_log and ssytemd journal which provide good tools for this already.
It could be as simple as (simplified pseudo-code)
for each $DISABLED_SERVICE as SERVICE; do grep -v $SERVICEor the other way around by only excluding every service not in a list of allowed services. -
reporter
The real question is: which would yield the best performance? Letting the lexer do most of the filtering, and then filter out the unwanted matches; or filtering out things prior to feeding it to the lexer.
-
I agree we should have services represented internally as strings.
I don't think SSHGuard deals with enough data that it's performance constrained. I think it's fine to run everything through sshg-parser and then just filter out the services wanted after.
-
reporter
- removed milestone
-
Hi,
I just working on this feature this since few days. As i am a beginner in C langage, it spend me a lot of time to do lots of simple things. Normaly i have a patch that works for that, but there is still some leaks in the code that i want to fix.
It will also change services numbers into friendly names in the log string (without the preffix 'SERVICES_' behind).
I should be able to submit it until the end of the week, i hope.
But, we are all agree that as far as sshguard is provide to parse all the logs strings given by the LOGREADER, this feature will never be an optimisation for performances ; all the logs strings are still parsed.
This feature will only be able to hit or not hit an attack, in regard of the attacked service. The offender will be reported and blocked, as he is actually, but only if the service is "monitored".
It seems to be what we need in this issue/feature ticket.
-
Sounds good to me. Feel free to reach out if you run into issues, or if you have questions about how we might want to do particular things in SSHGuard.
-
Hi Kevin,
I just done this commit : https://bitbucket.org/JoshuaSign/sshguard/commits/e46dd9acbb5cb110d5adc4efb7a1215ef4039ed2
Can you check and give me feedback about it ?
Don't forget : i am a very beginner in C langage. Friends read this code and help me to do it safe. I test it and it works good.
-
Thank you for your contribution, and in particular, the updates to the documentation. I've been a bit busy lately, so it will be a bit longer before I have time to do a proper review.
One thought is to represent the services internally with strings, rather than use the conversion macros you have in SERVICES_TABLE, TABLE_DEFINITION, and SMART_DECLARE_ENUM. Then, to identify the service, just compare the strings. If we represent internally with strings, then there might not be a need for the enum. What do you think?
-
Hi Kevin,
I'am not really sure to understand what you mean by "to identify the service, just compare the strings".
imho i don't think this is a good thing to use strings in C langage... but i am novice. My goal was to add features in sshguard without whole code review, because it works good and it is the fastest way to do the job (for sshguard and for us). As far as X-Macros are pre-processed, they normaly can't slower sshguard, isn't ?
Maybe using a struct for services sould be a better solution, but i don't practice structd for now. It will make possible to friendly name services in logs, and use them in the code. But for now, it is maybe lot of works, for less benefits.
This week, even if i was sick (flu), i finaly make a version with features we talk about. I give you a screen of exemple logs.
It just work since today. Testing on FreeBSD and Debian Linux. I will push it as soon as possible, i hope you'll like this and maybe you'll use some part in a future sshguard version.
For my personnal usage it is near the best... i just would like to add an option that save and reload current offenders list when sshguard restarts.
-
Sorry, I've been busy, too. But don't worry, I haven't forgotten about your patch!
There is an option to remember attacks between restarts of SSHGuard. That currently lives in the sqlite branch, and requires sqlite. You're free to give that a shot.
-
yes, i ever take a look at this branch. It is a good idea, and for developement it is fun to do it. but i'am afraid that using sqlitedb will slow sshguard... many io on hard drive to perform checks and others... usage maybe for honey pot or others projects, imho.
As You can see, i am obsessed (obviously too much) by performances. I am using sshguard as a end user (with many pfSense). In this conditions end users needs safe application, flexibility and performances. Thats why i would like sshguard to be the fastest and lightest as possible to do the job. Because servers must keep ressources for users services (openvpn, ftp, ssh, http, etc...) and not for managing lists of attackers (the less possible).
i notice that there is a minimum of 40 entries in my blocklist on most of servers. And after a restart it took 1h an 30 minute to get again 30 entries en the blocklist (not new ones, the sames than before). Even if we dont need to reload attackers when we restart sshguard, this could be done on exit and start of sshguard service and avoid some unwanted flow after a service restart. (or when server restart after a power supply shutdown, because who need to restart a service ?) ;-) This can be achived without slowing sshguard current process, it will just slow the start and stop of the service, which is acceptable.
sshguard is a really good work, a simple and amazing project, i hope it will always be fast and fexible... and free ;-)
-
Hi Kevin,
Please take a look a this : https://bitbucket.org/JoshuaSign/sshguard/branch/sshguard_featured
it should be usefull.
regards
-
- changed status to open
-
- removed version
Removing version: 2.0 (automated comment)
- Log in to comment
What exactly is the issue here? Is it that SSHGuard will see its own "Attack from..." messages and block again in a loop?
If that's the issue I'd suggest moving the work to a separate branch and back the change out of master while we fix it.