# Suritcata - SSLBL no logs **URL:** \ **Category:** Security\ **Created:** [8 March 2025 18:18 UTC](https://community.ipfire.org/t/suritcata-sslbl-no-logs/13747 "2025-03-08T18:18:51Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![smice-byte](https://community.ipfire.org/user_avatar/community.ipfire.org/smice-byte/32/8274_2.png) [@smice-byte](https://community.ipfire.org/u/smice-byte)\ **Post date:** [8 March 2025 18:18 UTC](https://community.ipfire.org/t/suritcata-sslbl-no-logs/13747/1 "2025-03-08T18:18:51Z")
grep -i “sslbl” /var/log/suricata/fast.log returns nothing. grep “DROP” /var/log/suricata/fast.log returns nothing [http://www.eicar.org/download/eicar.com](http://www.eicar.org/download/eicar.com) is not logged by ipfire curl [http://testmyids.com](http://testmyids.com) is not logged Rules set is updated Appears IPS is not fully functional ---
**Author:** ![dr\_techno](https://community.ipfire.org/user_avatar/community.ipfire.org/dr_techno/32/15388_2.png) [@dr\_techno](https://community.ipfire.org/u/dr_techno)\ **Post date:** [8 March 2025 19:55 UTC](https://community.ipfire.org/t/suritcata-sslbl-no-logs/13747/2 "2025-03-08T19:55:04Z")
as far as I know, the log file is turned off. So go into suricata.yaml and turn it on for yourself. But remember to clean the logs out periodically since there is no chron job scheduled to do so. ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [8 March 2025 20:24 UTC](https://community.ipfire.org/t/suritcata-sslbl-no-logs/13747/3 "2025-03-08T20:24:36Z")
> [@dr\_techno](#): > > as far as I know, the log file is turned off. The logging to the syslog messages file is turned off but the logging to the fastlog, which is what is shown in the Logs - IPS Logs menu option is turned on. So no you don’t need to turn on other logging. If you are not seeing any logged attempts from the SSLBL rules then it is likely that you have the “Drop packets from and to hostile networks (listed at Spamhaus DROP, etc.)” option in the Firewall - Firewall Options menu turned on. All C&C communications, both inwards and outwards will get blocked by that option first and there will be, hopefully, nothing for the SSLBL rules to react to. If you have that option turned on then you can look at the Logs - Firewall Logs menu option and look in the list for DROP\_HOSTILE. If you select the Export button then after a while, depending how many log entries you have, you will see a text list of all then log entries and you can then search it for DROP\_HOSTILE. I have the “Drop packets from and to hostile networks” turned on for my systems and for new installs it is turned on by default since CU164. I never saw any logging from the SSLBL rules. I left them in for some time but they stayed empty because everything was being dropped before it even got to the IPS, so I removed the SSLBL rules from my suricata configuration. Similarly, in the IP Block Lists I no longer have the SPAMHAUS\_DROP list enabled as it covers the same ground as the “Drop packets from and to hostile networks” option. The source is the same in both cases. So I found a 0% hit rate for the SPAMHAUS\_DROP ip list so all those C&C IP’s were being dropped at the earliest stage possible. ---
**Author:** ![smice-byte](https://community.ipfire.org/user_avatar/community.ipfire.org/smice-byte/32/8274_2.png) [@smice-byte](https://community.ipfire.org/u/smice-byte)\ **Post date:** [8 March 2025 21:16 UTC](https://community.ipfire.org/t/suritcata-sslbl-no-logs/13747/4 "2025-03-08T21:16:17Z")
However, that might not explain why browser can still access [http://www.eicar.org/download/eicar.com](http://www.eicar.org/download/eicar.com) curl [http://testmyids.com](http://testmyids.com)