Tons sshguard log entries and its not enabled
-
@ebcdic Where can you turn off logging of the default deny rule??
-
In Status > System Logs > Settings. Uncheck 'Log firewall default blocks'.
-
@stephenw10 Thanks, got it. Yes, I am also seeing the MANY SSHGuard starting and stopping in the log. I'll try disabling the default deny rule logging...would be an easy fix.
-
@jeff3820 said in Tons sshguard log entries and its not enabled:
I'll try disabling the default deny rule logging...would be an easy fix.
That seems a bit over the top - because I get a log entry every time my log rotations - I just won't log anything hitting my firewall that is blocked..
A bit a drastic fix for what is some log spam... Like that damn fly - let me hit him with this 20 lb sledge hammer..
Wouldn't it be simpler to just up the log size so they don't rotate as often?
-
I reverted back to 2.6.0 and I am not seeing those entries as often, in the last 2 days I have only seen it 3 times.
I did a fresh install to move back to 2.6.0 using a 22.01 config.xml backup and switched to the ZFS file system using 2 disks in mirroring mode. It went without issue. i'd love to use the ZFS widget but for now i'm staying put on 2.6.0 until some sort of clarity is officially released concerning the EULA and home use.
Not hopping on the Reddit clusterfud but don't want updates to stop or usage of packages to stop at the end of a year or at some point like I have been hearing.
Dell Poweredge r210 II, Intel(R) Xeon(R) CPU E31240 @ 3.30GHz RAM: 16GB
Dell Enterprise HHD x1 500gb (ZFS)
Pfsense: 2.7.1(amd64)
Installed Pkg's: Cron, System_Patches. -
@johnpoz What log size would you recommend? 1024000? 2048000?
-
@troysjanda after bumping my log to 1024K and turning off logging of all my dns queries and replies I saw 3 entries on the 19th..
Which I don't see how that could be even considered an issue.. 300 ok, bit of a log spam problem - 30 ok seems a bit excessive in a 24 hour period.. But 3.. Shoot HAproxy is way noisy that in its logs ;)
I had that at informational - just turned that down as well to error ;)
-
@jeff3820 said in Tons sshguard log entries and its not enabled:
1024000
this is what I have set mine to and currently all logs are utilizing 104K
-
@troysjanda Is this under DNS Resolver log settings??
<<turning off logging of all my dns queries and replies>>
-
@jeff3820 that was a manual setting you have to do in the custom box... I had turned it on for troubleshooting something for someone to show them, etc. And had forgotten to turn it back off.
I have also now taken a look at all my other log settings, openvpn had been set higher than default as well.. And haproxy was set pretty high.. Turning down logs to not be so spammy and upping the size before rotation should drastically reduce how many times the logs rotate and create that sshguard entry that your logs rotated, etc.
Currently I could see that dhcp server and noise on the firewall most likely would be the logs that normally have to rotate.. If you get a lot of noise on your wan from the default deny, or you have a lot of clients renewing dhcp.. You could prob up your lease time to lower the amount of those entries so clients don't renew as often..
If you continue to high a really high number of those sshguard entries... Look in your log directory and determine which log(s) are doing a lot of rotating - possible lower the amount of logging they do, or increase the log rotation size even higher..
If you do see lots and lots of noise on your wan - sure you could turn off logging of the default deny. But I would prob put something in its place to see what is hitting your wan. I log for example only syn and common udp ports.. Because yes the internet can be a noisy place - and while I want to see actual directed traffic to my wan - I really don't care much about some UDP noise to some random port, or non syn traffic..
-
@jeff3820 said in Tons sshguard log entries and its not enabled:
@troysjanda Is this under DNS Resolver log settings??
<<turning off logging of all my dns queries and replies>>
under ServicesDNS/ Resolver/AdvancedSettings set log level to 1 basic this is what I did and increased the size of logs in my previous comment
-
@johnpoz said in Tons sshguard log entries and its not enabled:
I log for example only syn and common udp ports
Can you provide the rules you use for this, im very new to rule writing.
-
An interesting observation...I have 2 weatherstations that are renewing their DHCP leases every MINUTE. Is there a way to not log those devices? I had them on a static IP but just took them off to see if that was an issue:
Feb 20 18:03:48 dhcpd 96898 DHCPACK on 192.168.40.63 to 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:48 dhcpd 96898 DHCPREQUEST for 192.168.40.63 (192.168.40.1) from 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:48 dhcpd 96898 reuse_lease: lease age 161 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.40.63
Feb 20 18:03:48 dhcpd 96898 DHCPOFFER on 192.168.40.63 to 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:48 dhcpd 96898 DHCPDISCOVER from 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:48 dhcpd 96898 reuse_lease: lease age 161 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.40.63
Feb 20 18:03:48 dhcpd 96898 DHCPACK on 192.168.40.64 to 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40
Feb 20 18:03:48 dhcpd 96898 DHCPREQUEST for 192.168.40.64 (192.168.40.1) from 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40
Feb 20 18:03:48 dhcpd 96898 reuse_lease: lease age 159 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.40.64
Feb 20 18:03:48 dhcpd 96898 DHCPOFFER on 192.168.40.64 to 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40
Feb 20 18:03:48 dhcpd 96898 DHCPDISCOVER from 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40
Feb 20 18:03:48 dhcpd 96898 reuse_lease: lease age 159 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.40.64
Feb 20 18:03:11 dhcpd 96898 DHCPACK on 192.168.40.63 to 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:11 dhcpd 96898 DHCPREQUEST for 192.168.40.63 (192.168.40.1) from 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:11 dhcpd 96898 reuse_lease: lease age 124 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.40.63
Feb 20 18:03:11 dhcpd 96898 DHCPOFFER on 192.168.40.63 to 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:11 dhcpd 96898 DHCPDISCOVER from 60:01:94:32:db:92 (ESP_32DB92) via em1.40
Feb 20 18:03:11 dhcpd 96898 reuse_lease: lease age 124 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.40.63
Feb 20 18:03:11 dhcpd 96898 DHCPACK on 192.168.40.64 to 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40
Feb 20 18:03:11 dhcpd 96898 DHCPREQUEST for 192.168.40.64 (192.168.40.1) from 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40
Feb 20 18:03:11 dhcpd 96898 reuse_lease: lease age 122 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.40.64
Feb 20 18:03:11 dhcpd 96898 DHCPOFFER on 192.168.40.64 to 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40
Feb 20 18:03:11 dhcpd 96898 DHCPDISCOVER from 2c:3a:e8:38:af:53 (ESP_38AF53) via em1.40 -
id either extend the lease times or give them static ips, But I am a novice. Still learning myself
-
@johnpoz I upped the log size and I’ll monitor for now. I did isolate another logging issue that is specific to ESP WiFi/networking chips used in IOT devices. I have 2 WiFi weather stations in the house that are connected to my IOT VLAN. These devices that use the ESP chips and are so dumb that they don’t handle DHCP in the traditional manner. Regardless of when the DHCP server tells the client to renew their IP address, these clients renew their IP address EVERY MINUTE…and I have 2 of them. These devices are so crappy they get dropped by my Unifi access points after 1-2 hours. I use an old Asus router as an access point just to connect these devices. I’m sure this was the cause of much DHCP log rotation.
My solution was to make the Asus router a router again and shift weather station IP management to the Asus getting the noise off of Pfsense. Pfsense assigns the IP address to the Asus and I keep all of these devices in the IOT VLAN. Of course the best solution would be to toss these weather stations in the trash but this will work for now.
-
Hi,
PfSense CE 2.6.0
As a workaround I tried disabled the log packets matched from the default block rules in the ruleset to reduce the amount of system logs, but after a period of calm, the problem has returned.
I changed the log file size from 500K to 1024 and didn't work either. After about a day the logs became polluted again.
In my case, the filter logs are very large and i need them.
I haven't found a solution for this yet. This "dirt" in the logs can hinder the visibility of some critical event.Jul 8 12:17:00 sshguard 27403 Exiting on signal.
Jul 8 12:17:00 sshguard 86043 Now monitoring attacks.
Jul 8 12:19:00 sshguard 86043 Exiting on signal.
Jul 8 12:19:00 sshguard 71802 Now monitoring attacks.
Jul 8 12:21:00 sshguard 71802 Exiting on signal.
Jul 8 12:21:00 sshguard 52201 Now monitoring attacks.
Jul 8 12:23:00 sshguard 52201 Exiting on signal.
Jul 8 12:23:00 sshguard 32915 Now monitoring attacks.
Jul 8 12:25:00 sshguard 32915 Exiting on signal.
Jul 8 12:25:00 sshguard 76907 Now monitoring attacks.
Jul 8 12:27:00 sshguard 76907 Exiting on signal.
Jul 8 12:27:00 sshguard 52340 Now monitoring attacks.Geovane
-
@geovaneg your saying you have a log file rotating every 2 minutes? Yeah I could see how that would be problematic.
-
Hi @johnpoz
Yes:
[2.6.0-RELEASE][admin@pfsense]/var/log: ls -tal | grep filter
-rw------- 1 root wheel 585448 Jul 8 12:48 filter.log
-rw------- 1 root wheel 110227 Jul 8 12:47 filter.log.0.bz2
-rw------- 1 root wheel 77990 Jul 8 12:44 filter.log.1.bz2
-rw------- 1 root wheel 101983 Jul 8 12:42 filter.log.2.bz2
-rw------- 1 root wheel 78511 Jul 8 12:39 filter.log.3.bz2
-rw------- 1 root wheel 88127 Jul 8 12:37 filter.log.4.bz2
-rw------- 1 root wheel 109005 Jul 8 12:35 filter.log.5.bz2
-rw------- 1 root wheel 82652 Jul 8 12:32 filter.log.6.bz2 -
@geovaneg your going to need to limit how much your logging, or go with a much larger size log file.. maybe 10M vs 1, or even like 100M? That seems like a lot of logging ;)
-
thank you to reply @johnpoz
I found it strange that for some time after I change the settings (about a day) the problem stopped but returns later. Also, in previous versions the amount of logs was the same and the problem did not occur.
Do you have any idea why this change in behavior?
