Interessantes Thema. Ich habe mich ein wenig mit den Firehol-Listen beschäftigt.Folgendes habe ich zum Testen eingerichtet.Firewall: Settings: Advanced: "Firewall Maximum Table Entries" auf 1'000'000 erhöht.Auf dem WAN-Interface "Block private networks" und "Block bogon networks" deaktiviert, weil die sind in in der Liste firehol_level1 enthalten.Auf dem LAN-Interface die bestehenden Regeln geprüft, damit mich firehol_level1 nicht aussperrt (enthält die privaten Netze).Separate Aliase und Regeln je Blocklist erstellt, damit ich sehe welche Webseite durch welche Liste geblockt wird (unter Advanced Options: Set local tag einen Namen vergeben).Blockregeln WAN eingehend gem. Anhang "1 - Blocklists WAN.PNG"LAN ausgehend dasselbe, gem. Anhang "2 - Blocklists LAN.PNG"Zum Testen habe ich mein Monitoringtool mit 190 Webseiten bemüht (ca. 180 unterschiedliche Domains). Mit dem Ergebnis, dass ich die Liste firehol_webserver ausgehend sofort wieder deaktiviert habe. Diese Liste hat zu viele Seiten gesperrt, darunter duckduckgo.com. Ansonsten wird aktuell von diesen 180 Webseiten eine durch firehol_level1 und eine durch firehol_level4 gesperrt.Eingehend sind alle Listen aktiv. Im Firewall-Log sieht man sofort nach der Aktivierung das Ergebnis, siehe Anhang "3 - Block results WAN.PNG".Anschliessend habe ich meine Familie auf dieses Setting losgelassen. Bis jetzt sind noch keine Klagen eingegangen, allerdings ist das erst seit ein paar Tagen am Laufen.Aufgetauchte Fragen und Erkenntnisse:1. Welche Blocklists soll man wie verwenden?Die Beschreibungen zu den Listen und deren Verwendungszweck sind nicht gerade ausufernd. Am besten ist firehol_level1 beschrieben:https://iplists.firehol.org/?ipset=firehol_level1https://github.com/firehol/blocklist-ipsets#which-ones-to-useIn den Kommentaren der Listen ist eine kurze Beschreibung enthalten:# firehol_webclient# An IP blacklist made from blocklists that track IPs that a # web client should never talk to. This list is to be used on # top of firehol_level1. (includes: ransomware_online # sslbl_aggressive cybercrime dyndns_ponmocup # maxmind_proxy_fraud)# firehol_webserver# A web server IP blacklist made from blocklists that track # IPs that should never be used by your web users. (This list # includes IPs that are servers hosting malware, bots, etc or # users having a long criminal history. This list is to be # used on top of firehol_level1, firehol_level2, # firehol_level3 and possibly firehol_proxies or # firehol_anonymous). (includes: maxmind_proxy_fraud myip # pushing_inertia_blocklist stopforumspam_toxic)# firehol_abusers_30d# An ipset made from blocklists that track abusers in the # last 30 days. (includes: cleantalk_new_30d # cleantalk_updated_30d php_commenters_30d php_dictionary_30d # php_harvesters_30d php_spammers_30d stopforumspam sblam)# firehol_level1# A firewall blacklist composed from IP lists, providing # maximum protection with minimum false positives. Suitable # for basic protection on all internet facing servers, # routers and firewalls. (includes: bambenek_c2 dshield feodo # fullbogons spamhaus_drop spamhaus_edrop sslbl zeus_badips # ransomware_rw)# firehol_level2# An ipset made from blocklists that track attacks, during # about the last 48 hours. (includes: blocklist_de dshield_1d # greensnow)# firehol_level3# An ipset made from blocklists that track attacks, spyware, # viruses. It includes IPs than have been reported or # detected in the last 30 days. (includes: bruteforceblocker # ciarmy dshield_30d dshield_top_1000 malc0de # maxmind_proxy_fraud myip shunlist snort_ipfilter # sslbl_aggressive talosintel_ipfilter zeus vxvault)# firehol_level4# An ipset made from blocklists that track attacks, but may # include a large number of false positives. (includes: # blocklist_net_ua botscout_30d cruzit_web_attacks cybercrime # haley_ssh iblocklist_hijacked iblocklist_spyware # iblocklist_webexploit ipblacklistcloud_top iw_wormlist # malwaredomainlist)Es gäbe auch noch die Liste firehol_abusers_1d, aber die scheint in firehol_abusers_30d enthalten zu sein. Abgesehen davon scheinen sich die Listen nicht gross zu überschneiden, ich habe es aber nicht geprüft.Mir ist nicht klar, ob die einzelnen Kompilationen speziell für die ein- UND/ODER ausgehende Filterung entwickelt wurden. Hier schreibt jemand z. B. "firehol_level1 beinhaltet die Bogons, welche nicht zum Blockieren des ausgehenden Verkehrs verwendet werden sollten.":https://forum.netgate.com/topic/121452/solved-exception-for-192-168-0-0-addressesWeiss jemand wieso nicht?Nichts desto trotz tendiere ich momentan dazu alle Firehol-Listen eingehend und ausgehend zu verwenden, nach dem Motto lieber zu viel statt zu wenig. Oder blickt da jemand von euch besser durch und kann Gründe nennen wieso man das nicht machen sollte?Die einzige Ausnahme scheint mir die Liste firehol_webserver zu sein. Die ist meiner Meinung nach wie bereits erwähnt für abgehende Filterung unbrauchbar. Gerade nochmals getestet, ist aktuell immer noch so: 19 der 180 Seiten sowie duckduckgo.com werden geblockt. Und nein, meine Testseiten sind nicht dubios oder verdächtig oder so. :-)Ich frage mich, ob firehol_level4 für ein Netzwerk mit vielen Benutzern empfehlenswert wäre, von wegen "but may include a large number of false positives".@jinn und @mimugmail: spamhaus_drop und spamhaus_edrop sind meines Wissens in firehol_level1 enthalten.2. Wie häufig soll man die Blocklists aktualisieren und von wo soll man sie beziehenGrundsätzlich wäre es schön, wenn man direkt auf der Sense das Script update-ipsets.sh der Software FireHOL verwenden könnte wie hier beschrieben:https://github.com/firehol/blocklist-ipsets#using-them-in-fireholhttps://github.com/firehol/blocklist-ipsets/wikiDamit könnte man quasi eine Echtzeitaktualisierung der Listen realisieren: Sobald eine der Quellen aktualisiert wurde, und nur dann, wird die entsprechende Liste neu generiert.Im Wiki steht explizit (wieso auch immer): "IMPORTANT. You should not use the ipsets in this repo in production systems. YOU SHOULD ALWAYS DOWNLOAD THE IP LISTS DIRECTLY FROM THEIR MAINTAINERS."Aber da FireHOL nicht auf BSD läuft fällt diese Variante leider weg. Vielleicht hat ja mal jemand Lust das besagte Script aus FireHOL für BSD zu portieren.Ich werde künftig vermutlich FireHOL in einer Linux-VM installieren und die Senses die Listen von dort holen lassen.Bis dann müssen die Listen aus dem Github repo herhalten. Diese werden gem. README.md seit kurzem nur noch täglich aktualisiert: "Due to the amount of data and the frequency of the updates on this repo, github has requested to limit the number of updates. The site https://iplists.firehol.org has direct links to all the files in this repo. This repo is now updated once per day."Also kann man es mit der Aktualisierungsrate gemütlich nehmen, die Server werden es danken.Spamhaus bietet eine IPv6-Blocklist an, diese ist nicht in dern Firehol-Listen enthalten:https://www.spamhaus.org/drop/dropv6.txtDiese sollte man nicht mehr als stündlich aktualisieren:https://www.spamhaus.org/faq/section/DROP%20FAQ#2183. Wie verhalten sich Aliase vom Typ "URL Table" im Fehlerfall?Was passiert, wenn die Quelle zum Zeitpunkt der Aktualisierung nicht erreichbar ist? Hoffentlich endet das nicht in einer leeren Tabelle. Perfekt wäre natürlich eine Benachrichtigung durch die Sense.Man kommt wohl um ein Monitoring der Quellen nicht drumherum, wenn man nicht eines Tages mit leeren oder veralteten Tabellen dastehen will.Ich würde mich freuen eure Meinung zu meinem Setting/meinen Gedanken zu hören.Happy blocking.
