You would need to add a logging rule before the DROP rule, as per default it’s not logged.

iptables -I MAILCOW 1 -m set --match-set abuseipdb_blacklist_v4 src -j LOG --log-prefix "MAILCOW-DROP: " --log-level 4
ip6tables -I MAILCOW 1 -m set --match-set abuseipdb_blacklist_v6 src -j LOG --log-prefix "MAILCOW-DROP: " --log-level 4

    DocFraggle Thanks for that . It didn’t like the ip6tables line but I am just learning to deal with this iptables stuff.
    I now see this but where is the log located.
    I tried to do a journalctl -k but didn’t see anything log related.

    Chain MAILCOW (2 references)
    target     prot opt source               destination
    LOG        all  --  0.0.0.0/0            0.0.0.0/0            match-set abuseipdb_blacklist_v4 src LOG flags 0 level 4 prefix "MAILCOW-DROP: "
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            match-set abuseipdb_blacklist_v4 src
    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 3306,6379,8983,12345
    

    Yes, journalctl. But it only logs something if one of the IPs from AbuseIPDB tries to connect

      DocFraggle I am now seeing this

      [demo@mail ~]$ journalctl -k --grep="mail" -f
      Mar 26 15:05:26 mail kernel: MAILCOW-DROP: IN=enp0s31f6 OUT= MAC=48:4d:7e:d8:ec:18:d8:0d:17:3f:ba:20:08:00 SRC=185.200.118.46 DST=192.168.68.21 LEN=1378 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=50337 DPT=443 LEN=1358
      Mar 26 15:05:26 mail kernel: MAILCOW-DROP: IN=enp0s31f6 OUT= MAC=48:4d:7e:d8:ec:18:d8:0d:17:3f:ba:20:08:00 SRC=185.200.118.46 DST=192.168.68.21 LEN=1378 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=50337 DPT=443 LEN=1358
      Mar 27 03:18:30 mail kernel: MAILCOW-DROP: IN=enp0s31f6 OUT= MAC=48:4d:7e:d8:ec:18:d8:0d:17:3f:ba:20:08:00 SRC=185.200.118.46 DST=192.168.68.21 LEN=1378 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=42024 DPT=443 LEN=1358
      Mar 27 03:18:30 mail kernel: MAILCOW-DROP: IN=enp0s31f6 OUT= MAC=48:4d:7e:d8:ec:18:d8:0d:17:3f:ba:20:08:00 SRC=185.200.118.46 DST=192.168.68.21 LEN=1378 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=42024 DPT=443 LEN=1358
      

      So the log is working. Thanks for the help.

      You have to make sure that the LOG rule is above the DROP rule. If I have the time I will add a logging switch to the script to do that automatically

        DocFraggle Looks like I have it in there twice but it is above the DROP rule.

        Chain MAILCOW (2 references)
        target     prot opt source               destination
        LOG        all  --  0.0.0.0/0            0.0.0.0/0            match-set abuseipdb_blacklist_v4 src LOG flags 0 level 4 prefix "MAILCOW-DROP: "
        LOG        all  --  0.0.0.0/0            0.0.0.0/0            match-set abuseipdb_blacklist_v4 src LOG flags 0 level 4 prefix "MAILCOW-DROP: "
        DROP       all  --  0.0.0.0/0            0.0.0.0/0            match-set abuseipdb_blacklist_v4 src
        DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 3306,6379,8983,12345
        
        • DocFraggle

          • Community Hero
          Moolevel 274

        OK, v2.2 erstellt jetzt zusätzlich LOG Rules wenn man das Script mit --enable-log laufen lässt. Die Logs sieht man dann im journalctl/syslog, je nach System.

        English: v2.2 takes care of creating LOG rules automatically if you run the script with --enable-log. View logs with journalctl/syslog, depending on the system.

        DocFraggle/mailcow-scriptsblob/v2.2/abuseipdb.sh

        Viel Spass!

        Soo, bin heute von deiner Version 1 auf die Version 2 umgestiegen. Vielen Dank noch einmal für deine Arbeit.
        Finde es klasse, dass die Mailcow API nun nicht mehr gebraucht wird. Damit konnte ich die API nun wieder ganz deaktivieren! 🙂

          pscriptos Should the results in the LOG look like this:

          [demo@mail iptables]$ journalctl -k --grep="MAILCOW" -f
          Mar 29 18:27:43 mail kernel: MAILCOW-DROP: IN=enp0s31f6 OUT= MAC=48:4d:7e:d8:ec:18:d8:0d:17:3f:ba:20:08:00 SRC=148.113.214.202 DST=192.168.68.21 LEN=151 TOS=0x00 PREC=0x00 TTL=47 ID=0 PROTO=TCP SPT=40128 DPT=25 WINDOW=502 RES=0x00 ACK PSH URGP=0
          

          @DocFraggle vielen Dank. Ich hab nun das Logging mal eingeschalten und das ist schon heftig was da geblockt wird. Bei mir läuft ja zusätzlich noch Crowdsec und trotzdem blockt der Mailcow Fail2ban auch noch reichlich. Die Welt ist böse.

            @DocFraggle What happened to this code:

            # Add your own personal blacklist to this file in vaild CIDR notation
            # i.e. 1.2.3.4/32
            #      5.6.7.0/24
            #      2001:db8:abcd:1234::1/64  
            
            PERSONAL_BLACKLIST_FILE="/path/to/your/blacklist.txt"
            

            Do we not need this anymore?
            I would like to add ip’s not included in the abuse list.
            Do I just add them to the netfilter blacklist?
            Thanks

              maybl8 Do I just add them to the netfilter blacklist?

              Yes, just use the “Blacklisted networks/hosts” text-field on the Fail2Ban page as you did before.

              Ganzjahresgriller […] Bei mir läuft ja zusätzlich noch Crowdsec und trotzdem blockt der Mailcow Fail2ban auch noch reichlich. Die Welt ist böse.

              Da bei mir auch noch Crowdsec läuft und ständig Diverse versuche von den Bösen meldet, habe ich mir das mal zunutze gemacht und unterstütze jetzt dadurch aktiv AbuseIPdb.

              Die ganzeen IPs händisch zu melden wäre etwas mühsam gewesen, ich wollte was automatisches, so wie in dem Fail2Ban Beispiel.
              Da ich aber in der Konfiguration von mailcow dafür nicht rumfummln wollte (was wahrscheinlich bei einem update wieder überschrieben wird), musste da was anders her. Etwas gegoogelt und einwenig später schon was praktisches für Crowdsec gefunden gehabt. Dazu wird das http Plugin von Crowdsec verwendet. So werden jetzt die ganzen Versuche von den bösen Jungs & Mädels Automatisch an AbuseIPdb von Crowdsec über das http Plugin gemeldet. Durch das aktive melden von IPs, bekommt man auch noch einen Bonus bei AbuseIPdb und darf die Datenbank mehr als 5 mal am Tag updaten. Also eine win win Situation. 😃

              • DocFraggle

                • Community Hero
                Moolevel 274
              • Edited

              Die aktuell von Fail2Ban gesperrten IPs bekommt man über die API, das hatte ich vor der “ipset” Umstellung mal im Script

              echo "Get current Fail2Ban config, extract active_bans IPs and add them to the blacklist file"
              curl -s --header "Content-Type: application/json" \
                   --header "X-API-Key: $MAILCOW_API_KEY" \
                    "https://${MAILSERVER_FQDN}/api/v1/get/fail2ban" |\
                    jq -r 'if .active_bans | length > 0 then .active_bans[].ip else "" end'

              Wäre also auch eine Möglichkeit das dann via Script an AbuseIPDB zu melden.
              Wo genau hängt denn bei Dir jetzt ein http Plugin drin?

                I don’t think my cron job is working .
                I have this in cron:

                0 */5 * * * /etc/iptables/abuseipdb.sh
                

                I started it yesterday and looked at abuseipdb this morning. It shows this:

                Your APIv2 Daily Request Limits
                Endpoint	Usage / Daily Limit	Utilization Rate
                blacklist	0 / 5	0%
                bulk-report	0 / 5	0%
                check	0 / 1,000	0%
                check-block	0 / 100	0%
                clear-address	0 / 5	0%
                report	0 / 1,000	0%
                reports	0 / 100	0%
                

                Is there a way to know it is trying to run?
                Would that be shown in the journalctl?
                Thanks

                It looks like you are not retrieving data from AbuseIPDB and yes you can see everything in the journal. What is happening if you start the script manually?

                  Ganzjahresgriller

                  [demo@mail mailcow-dockerized]$ sudo ./abuseipdb.sh
                  [sudo] password for demo:
                  Retrieve IPs from AbuseIPDB
                  Ensure the ipsets exist
                  Flush existing ipset entries
                  Process each IP and add it to the appropriate ipset
                  Ensure iptables/ip6tables rules exist at the top
                  ip6tables: No chain/target/match by that name.
                  ip6tables: No chain/target/match by that name.
                  
                  
                  All done, have fun.
                  
                  Check your current iplist entries with 'ipset list | less'
                  
                  Your APIv2 Daily Request Limits
                  Endpoint	Usage / Daily Limit	Utilization Rate
                  blacklist	1 / 5	20%
                  bulk-report	0 / 5	0%
                  check	0 / 1,000	0%
                  check-block	0 / 100	0%
                  clear-address	0 / 5	0%
                  report	0 / 1,000	0%
                  reports	0 / 100	0%
                  Notify me when I exhaust my daily API limit for an endpoint.