{"id":893,"date":"2018-10-31T12:47:16","date_gmt":"2018-10-31T12:47:16","guid":{"rendered":"https:\/\/www.nicktailor.com\/?p=893"},"modified":"2022-10-21T11:36:26","modified_gmt":"2022-10-21T11:36:26","slug":"how-to-survive-a-log-flood-wazuh","status":"publish","type":"post","link":"https:\/\/nicktailor.com\/tech-blog\/how-to-survive-a-log-flood-wazuh\/","title":{"rendered":"How to survive a log flood – wazuh"},"content":{"rendered":"
\n

This is directly from wazuh documentation, but I thought it would good to have here for people browsing through. I guess the main section to take notice of is how to augment the agent buffer via the ossec.conf on the client side for troubleshooting purposes<\/strong><\/em><\/p>\n

Survive a log flood<\/span><\/span><\/p>\n

A centralized logging system needs to be able to process many events per second (eps) from many different log sources at the same time, but sometimes things just get completely out of hand. A variety of problems like infinite loop conditions, poorly written software, and misconfigured applications can cause one or a few individual devices to suddenly start producing a huge and unstopping stream of log messages rushing at your logging system at a rate of hundreds or even thousands of events per second. When such a device or devices suddenly take up vastly more than their fair share of network and log processing resources, it can become widely disruptive. Log flooding can saturate your network bandwidth and\/or overtax your <\/span>Wazuh<\/span> and Elastic system components while one gigabyte after another of likely the same repeated log messages are being <\/span>reanalyzed<\/span> and churned to disk.<\/span><\/span><\/p>\n

Thankfully the <\/span>Wazuh<\/span> agent has a flood protection mechanism to prevent out of control log production on one system from creating disruptions to your network or to your <\/span>Wazuh<\/span>\/Elastic services. In this lab we will create a small log flood and observe how it is gracefully contained by the <\/span>Wazuh<\/span> agent before it departs the system where the logs are produced. We will also <\/span>take a look<\/span> at the leaky bucket queue that <\/span>Wazuh<\/span> uses to accomplish this. <\/span>Lastly<\/span> we will note the alerts that are produced to keep us informed about the onset of, escalation of, and recovery from log flooding events.<\/span><\/span><\/p>\n

Configure the <\/span>Wazuh<\/span> agent client buffer on <\/span>linux<\/span>-agent<\/span><\/span><\/p>\n