1. sshguard Avatar sshguard
  2. sshguard
  3. sshguard
  4. Issues

Feature : block by services

Issue #109 new
JoshuaSign created an issue

Hi,

I would like to puprose a new feature for sshguard : block only on the service attacked.

This could be very usefull for many cases.

I have made some test, and it is really easy to get it working.

I just add an optional mode in the conf file :

  • default mode : block all services

  • service mode : block service by service

I will be able to submit a PR for that if it could be a new feature for sshguard.

Regards.

Josh_

Comments (9)

  2. Kevin Zheng

    How did you get this working? SSHGuard will add a block in a firewall table for whole addresses, not ports.

  3. JoshuaSign reporter

    this is because SSHGuard only track the sshg_address,

    but if we change it to track attack_t, it is really really easy to track the adresse and/or the service.

    Exemple of case : As it, if server A is connected to server B to provide services like OpenVPN, FTP, EXIM, SSH, etc... If the support team open ssh from A to B and fail password, all services are not blocked at the same time.

    This patch works to me : https://redmine.pfsense.org/attachments/download/2690/sshguad_by_service_filtering.patch ( i purpose it to pfSense because they miss something in their system).

    But the one i can submit here is a little better.

  4. Kevin Zheng

    I see. Could you show your changes in sshg-fw-*? fw_block and fw_release would need to be modified for all firewalls, but that might make it a worthwhile option to add.

  5. JoshuaSign reporter

    you talk about BACKENDS ?

    If so, we need to do better example for this, i haven't for now. But the user need to personalize them, obv.

    But, if we provide a backend that create 1 rule by service, it works good, isn't ?

  6. JoshuaSign reporter

    for later use, we can add option to group services in regard of a rule... i think about it since few days, but i dont know how is the best we can do....

  7. JoshuaSign reporter

    Hi Kevin,

    I just finish a version wich is working and need to be tested more : https://bitbucket.org/JoshuaSign/sshguard/commits/0a769bec804e2bbebe3cdd8aece1cac91d3af5bf?at=sshguard_featured

    As i need some feature we talk about, and others, i finaly add all of them in this.

    The mains changes :

    • add SERVICES_MONITORING variable in config to set a list of services to monitor.

    • add SERVICES_DISTINCT variable in config to block/release attacker ip service by service.

    • add OFFENDERS_FILE variable in config to save an reload offenders list when sshguard stop/start

    • add FORGIVE_TIME variable in config to purge offenders list and dont keep them forever.

    • add DEBUG variable in config (more friendly to use)

    • using services names instead of numbers for end user for config, logs and firewall (using x-macros)

    • changes in sshg-fw-iptables.sh and sshg-fw-pf.sh to be able to work with "services distinct" mode

    Others little changes :

    • change LOGREADER example command line with a better default path for journalctl and -n0 to avoid older attack hit on sshguard restarts

    • remove iptables prestart from examples/sshguard.service

    • add log string when realease an attacker

    • add PFSENSE signature with a better regexp than the first : tested ok

    • and sshg-fw-pfsense_2.4.4.sh example because it is fully tested and works good

    • fix FILENAME regexp from attack_scanner.l : add the underscore '_' into charset list

    TODO :

    • sandbox is disabled because we need to fix how to deal with files in sandboxed env. eg: when pid file must be unlinked or offenders list saved.

    • need changes for others firewalls scripts and the /etc/hosts.allow mode (or maybe remove this feature, somebody really use it?)

    • need to add version in sshg-blocker (the version is only in the bash script).

    • try to upgrade to simclist 1.5 or 1.6 (better performances improvements).

    • certainly many others things...

    I use a new version number to differenciate versions in my tests.

    Maybe i do some horrbles mistakes in the code, or most probably novice errors, so be carefull about it.

    This code works like a charm on Linux Debian 9 and pfSense 2.4.4_2 on FreeBSD 11.2-RELEASE-p6.

    I hope you'll can use at least a parts of it.

    Josh_

  9. JoshuaSign reporter

    Hi,

    For information, i just add a commit for multiple detection fix and others minors fixes

    https://bitbucket.org/JoshuaSign/sshguard/commits/93cbef4b667f8b8872b7678ec4ab29a021afbd6a

    CHANGES :

    • move witelist detection after the service monitoring detection

    • better service name loging string construction for attack detection

    • switch LOG_INFO to LOG_DEBUG for "host in whitelist" and "attack on not monitored service" messages

    • fix multiple detections for the same attack by considering "a same attack" is withing the same second.

    Duplicate detections problem : 

    Mar 3 00:43:30  sshguard    77997    Blocking "36.66.203.23/32" for 300 secs on service SSH (3 attacks in 0 secs, after 1 abuses over 0 secs.)
Mar 3 00:43:30  sshguard    77997    Attack from "36.66.203.23" on service SSH with danger 10.             // DUPLICATE DETECTION
Mar 3 00:43:30  sshd        88039    Disconnected from invalid user jm 36.66.203.23 port 57458 [preauth]
Mar 3 00:43:30  sshd        88039    Received disconnect from 36.66.203.23 port 57458:11: Bye Bye [preauth]
Mar 3 00:43:30  sshguard    77997    Attack from "36.66.203.23" on service SSH with danger 10.             // DUPLICATE DETECTION
Mar 3 00:43:30  sshd        88039    Failed password for invalid user jm from 36.66.203.23 port 57458 ssh2
Mar 3 00:43:30  sshguard    77997    Attack from "36.66.203.23" on service SSH with danger 10.             // GOOD DETECTION
Mar 3 00:43:30  sshd        88039    Invalid user jm from 36.66.203.23 port 57458

    After this fix it looks better :

    Mar 3 00:44:24  sshd        98353    Fssh_packet_write_wait: Connection from invalid user sg 103.82.101.44 port 41729: Permission denied [preauth]
Mar 3 00:44:24  sshd        98353    Failed password for invalid user sg from 103.82.101.44 port 41729 ssh2
Mar 3 00:44:24  sshd        98353    user NOUSER login class [preauth]
Mar 3 00:44:24  sshguard    38265    Blocking "103.82.101.44/32" for 120 secs on service SSH (2 attacks in 446 secs, after 1 abuses over 446 secs.)
Mar 3 00:44:24  sshguard    38265    Attack from "103.82.101.44" on service SSH with danger 10.   // GOOD DETECTION
Mar 3 00:44:24  sshd        98353    Invalid user sg from 103.82.101.44 port 41729
Mar 3 00:36:58  sshd        60741    Disconnected from invalid user aq 103.82.101.44 port 43036 [preauth]
Mar 3 00:36:58  sshd        60741    Received disconnect from 103.82.101.44 port 43036:11: Bye Bye [preauth]
Mar 3 00:36:58  sshd        60741    Failed password for invalid user aq from 103.82.101.44 port 43036 ssh2
Mar 3 00:36:58  sshd        60741    user NOUSER login class [preauth]
Mar 3 00:36:58  sshguard    38265    Attack from "103.82.101.44" on service SSH with danger 10.    // GOOD DETECTION
Mar 3 00:36:58  sshd        60741    Invalid user aq from 103.82.101.44 port 43036

    NOTE :

    I read the https://bitbucket.org/sshguard/sshguard/issues/77/false-positive-in-connection-closed issue and i'm not agree with Sam. If someone is probing my server, he should be considered as an offender, otherwise i must add him to whitelist. Note that many signatures that sshguard detects are only probes. Sam Darwin's problem sound like a personnal disign problem, he should whitelist the host, imho.

    Also, if you need to probe ssh service, the bot that probes should login in to be sure that ssh works, and avoid the problem of attack detection.

    But Sam's issue 77 it is not a duplicate of :

    TODO :

    • make log verbosity more configurable

    • make attack dangerousness configurable

    Regards.

    Josh_

  10. Log in to comment
Assignee
–
Type
proposal
Priority
trivial
Status
new
Component
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!