Huge Syslog Archive MySQL file

I or maybe you have a problem there is no disk space due to MySQL database on Security Onion Sensor Server. Upon investigating, I realized a table is huge around 34GB.

$ find / -type f -name '*.ARN' -size +1024M -ls
524481 36073464 -rw-rw---- 1 mysql mysql 36939788428 May 26 12:41 /var/lib/mysql/syslog_data/syslogs_archive_1004053.ARN

The table is related to ELSA including MySQL, Sphinx and syslog-ng.

To delete the huge file elegantly, we can use a script, /usr/bin/securityonion-elsa-reset-archive, but the target table of the script is fixed to ‘syslogs_archive_1’. So you can use the script after replacing the table name to found one above or type some commands directly as below.

$ mysql --defaults-file=/etc/mysql/debian.cnf syslog_data \
 -e "DROP TABLE syslog_data.syslogs_archive_1004053"
$ mysql --defaults-file=/etc/mysql/debian.cnf syslog_data \
 -e "DELETE FROM syslog.tables \
      WHERE table_name='syslog_data.syslogs_archive_10024053'"
$ rm /var/lib/mysql/syslog_data/syslogs_archive_1004053.ARN

If you want to remove all of tables, whose name is start with ‘syslogs_archives_1’, you can utilize the sql below.

SELECT CONCAT('DROP TABLE ', GROUP_CONCAT(table_name), ';') as statement 
  FROM information_schema.tables
 WHERE table_name LIKE 'syslogs_archive_1%'

Basically, you need to adjust a value of retention_days of ‘/etc/elsa_node.conf’ because the huge table belongs to ELSA.

BTW, the reason why the table in question became huge is still remain. I just tried delete it as above. Sorry for that.

Case Study: Security Onion Server Disk Full

잘 동작하던 Security Onion(SO)가 갑지가 동작하지 않을 때 수 많은 이유가 있겠지만, HDD DISK가 가득차 동작하지 않는 경우라면 이 글이 도움될 수 있겠네요.

이 글을 읽기 전에 아래와 같은 명령어로 디스크 사이즈를 줄여보셨나요?! 적어도 필자는 별 효과가 없었습니다. 왜냐하면 일반적인 파일 문제가 아니라 sguil이 사용하는 MySQL의 securityonion_db에 엄청난 데이터가 쌓여있기 때문 입니다.

$ du -h –max-depth=1 /  (하위 폴더별 디스크 사용량)
$ truncate -s 0 /var/log/*log (모든 log 파일 내용 지우기)
$ find /var/log -type f -name ‘*.gz’ -exec rm {} \; (모든 gz 파일 삭제하기)
$ find / -size +2048M -ls (2GB 보다 큰 파일 찾기)

Sguil Database

SO 운영자가 아직 최적화(Optimizing)를 하지 않고 설치 시 기본 값으로만 SO를 운영할 경우 금방 DISK가 차버릴 수 있습니다. 로그 저장 능력과 관련해 기본값은 아래와 같이 90일로 설정되어 있었는데, 필자의 경우 설치 후 운영한지 이틀만에 DISK FULL 되었습니다. 그래서 /etc/nsm/securityonion.conf 에서 DYASTOKEEP 과 DAYSTOREPAIR를 각각 7일과 3일로 변경 했습니다. (우선은 운영을 해야 하겠기에..ㅠㅠ)

-DAYSTOKEEP=90
+DAYSTOKEEP=7
-DAYSTOREPAIR=7
+DAYSTOREPAIR=3

그런데 아직 위 옵션들이 적용되지 않았습니다. 그 이유는 이런 옵션들은 sguil-db-purge 에 의해서 참조되기 때문에, sguil-db-purge를 별도로 실행시켜줘야 합니다.

Network Packet Capture Files

캡쳐된 Raw 패킷은 분석할 때 유용하게 사용되지만, 네트워크 볼륨에 비래한 저장공간을 필요로 하기 때문에 관련된 옵션을 잘 파악하여 운영의 묘를 살려야 하겠습니다. 기본적으로 저장되는 곳은 /nsm/sensor_data/eth0/dailylogs/YYYY-MM-DD/snort.log.*  와 같은 패턴으로 tcpdump 파일이 기록됩니다. 아래 명령어들은 이와 같은 파일들이 기록되지 않도록 합니다.

$ sed -i ‘s|PCAP_ENABLED=”yes“|PCAP_ENABLED=”no“|g’ /etc/nsm/*/sensor.conf
$ sed -i ‘s|PCAP_AGENT_ENABLED=”yes“|PCAP_AGENT_ENABLED=”no“|g’ /etc/nsm/*/sensor.conf
$ nsm_sensor_ps-stop –only-http-agent
$ chmod 0 /usr/bin/netsniff-ng