aggressive-cleaning enable but still got disk usage email alert?

[MP18]

i have configured the command below  but still got email alert 

model: PA-5050
sw-version: 8.0.9

-NGFW-1(active)> show system state | match aggressive-cleaning

cfg.debug-sw-du.config: { 'aggressive-cleaning': True, }

domain: 1
receive_time: 2019/04/29 05:03:23
serial: 002201001803
seqno: 6880362
actionflags: 0x8000000000000000
type: SYSTEM
subtype: general
config_ver: 0
time_generated: 2019/04/29 05:03:23
dg_hier_level_1: 0
dg_hier_level_2: 0
dg_hier_level_3: 0
dg_hier_level_4: 0
vsys_name:
device_name: NGFW-1
vsys_id: 0
vsys:
eventid: general
object:
fmt: 0
id: 0
module: general
severity: critical
opaque: Disk usage for / exceeds limit, 96 percent in use, cleaning filesystem

I thought when you configure aggressive cleaning it should do this automaticalls and we should not get email alert?

[gwesson]

I have to get this out of the way first: Please upgrade to a more current code version. 8.0.9 was released over a year ago and has several vulnerabilities at medium or high priority. Unpatched devices are the most common vectors for attacks. Also, 8.0 has six months before it is End of Life as well, so that might be a good opportunity to begin upgrading to 8.1, which is supported on the PA-5000 series until 2024.

PAN-SA-2019-0002 (High). Cross site scripting (XSS) vulnerability in the management interface. Fixed in 8.0.15.

PAN-SA-2018-0008 (High). Denial of Service (DoS) in the management interface. Fixed in 8.0.10.

PAN-SA-2018-0009 (medium). XSS in the GP login page. Fixed in 8.0.11.

PAN-SA-2018-0015 (medium). OpenSSL vulnerabilities. Fixed in 8.0.13.

PAN-SA-2018-0012 (medium). FragmentSmack vulnerability. Fixed in 8.0.13.

PAN-SA-2019-0001 (medium). XSS in external dynamic lists. Fixed in 8.0.15.

PAN-SA-2019-0007 (medium). DoS in the management interface. Fixed in 8.0.16.

With that said, it depends on how much logging you are doing. Check your logging rate (debug log-receiver statistics) to see where you're at for logs/second. Even with aggressive cleaning the system may simply be getting so many logs it cannot keep up. 

You may be able to reduce that as well. Make sure you're not logging at session start, don't log on the default deny rule (logging is disabled by default on it). You may also want to exclude logging for things like NTP, DNS, Ping, etc. by disabling the 'log at session end' in a rule dedicated just to that type of traffic.

[ozheng]

Hello,

Actually you should edit the rule for the email logging, by adding a AND condition with negate option on the descrtiption.

Hope that helps

[MP18]

Right now it is after hours and logging rate is low as users are gone

here is info from that command

> debug log-receiver statistics

Logging statistics
------------------------------ -----------
Log incoming rate: 83/sec
Log written rate: 83/sec
Corrupted packets: 0
Corrupted URL packets: 0
Corrupted HTTP HDR packets: 0
Corrupted EMAIL HDR packets: 0
Logs discarded (queue full): 0
Traffic logs written: 124003056
GTP logs written: 0
Tunnel logs written: 0
Auth logs written: 0
Userid logs written: 11898465
URL logs written: 5368
Wildfire logs written: 193
Anti-virus logs written: 0
Widfire Anti-virus logs written: 0
Spyware logs written: 16432611
Spyware-DNS logs written: 0
Attack logs written: 0
Vulnerability logs written: 1923724
Fileext logs written: 0
Fileext logs URL not written: 0
Fileext logs URL not written (timedout): 0
URL cache age out count: 0
URL cache full count: 0
URL cache key exist count: 0
URL cache wrt incomplete http hdrs count: 0
URL cache rcv http hdr before url count: 0
URL cache full drop count(url log not received): 0
URL cache age out drop count(url log not received): 0
Email hdr cache count: 127
Email hdr cache hit count: 124
Traffic alarms dropped due to sysd write failures: 0
Traffic alarms dropped due to global rate limiting: 0
Traffic alarms dropped due to each source rate limiting: 0
Traffic alarms generated count: 0
Netflow incoming count: 0
Log Forward count: 501
Log Forward discarded (queue full) count: 0
Log Forward discarded (send error) count: 0
Total logs not written due to disk unavailability: 0
Logs not written since disk became unavailable: 0

Summary Statistics:
Num current drop entries in trsum:0
Num cumulative drop entries in trsum:0
Num current drop entries in thsum:0
Num cumulative drop entries in thsum:0
Num current drop entries in gtpsum:0
Num cumulative drop entries in gtpsum:0

External Forwarding stats:
Type Enqueue Count Send Count Drop Count Queue Depth Send Rate(last 1min)
syslog 266368006 266368006 0 0 14796
snmp 0 0 0 0 0
email 0 0 0 0 0
raw 142364950 142364950 0 0 7906
http 0 0 0 0 0
autotag 0 0 0 0 0

we are only logging at sessiond end.

also we are logging at default deny rule

also we have logging for intrazone enabled.

There is not much ntp or dns traffic.

How can i verify that the logging rate at peak time is high for PA 5050?

Any baseline i could check?

[MP18]

can you please explain in more detail about email logging?

[ozheng]

what is the config you have done to receive the alerts by email?

[MP18]

please follow this link.

You can choose what sev you want for email alert

https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/monitoring/configure-email-alerts

[ozheng]

ok, then in the log settings, you have "filter builder".

[MP18]

yes like 

sev equal critical