Rsyslog является улучшенной версией демона syslogd и из названия понятно, что он занимается сбором сводной информации о состоянии системных демонов с последующей записью в файлы. Бывает rsyslogd долго занимает процессор от 20% и выше.
Некоторым помогает переустановка или обновление rsyslogd, а в некоторых случаях rsyslogd предпочитают удалять с последующей заменой на другой демон сбора системной информации, но в корне всё это проблемы не решает!
Про удаление rsyslogd и речи быть не может имхо его удаление лишит нас возможности сбора и анализа информации о состоянии системы! Хотя в любом случае из выше перечисленных мер нам не помешает обновление и обновляться мы будем из оригинального репозитория до самой свежей и актуальной версии (текущая 7.2.6):
cd /etc/yum.repos.d/ wget http://rpms.adiscon.com/rsyslogall.repo vi rsyslogall.repo # add this line in section "[rsyslog-v7-stable]" if use yum-priorities priority=1 sh-4.1# yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning repos: atomic base epel extras nginx rsyslog-v7-stable updates Cleaning up Everything Cleaning up list of fastest mirrors sh-4.1# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors epel/metalink | 18 kB 00:00 * atomic: www7.atomicorp.com * base: centos-mirror.rbc.ru * epel: fedora-mirror01.rbc.ru * extras: centos-mirror.rbc.ru * updates: centos-mirror.rbc.ru atomic | 1.9 kB 00:00 atomic/primary_db | 520 kB 00:01 base | 3.7 kB 00:00 base/primary_db | 4.4 MB 00:03 epel | 4.2 kB 00:00 epel/primary_db | 5.0 MB 00:04 extras | 3.5 kB 00:00 extras/primary_db | 19 kB 00:00 nginx | 1.3 kB 00:00 nginx/primary | 5.2 kB 00:00 nginx 37/37 rsyslog-v7-stable | 2.5 kB 00:00 rsyslog-v7-stable/primary_db | 55 kB 00:00 updates | 3.5 kB 00:00 updates/primary_db | 1.4 MB 00:01 239 packages excluded due to repository priority protections Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package rsyslog.x86_64 0:5.8.10-6.el6 will be updated ---> Package rsyslog.x86_64 0:7.2.6-3.el6 will be an update --> Processing Dependency: liblognorm.so.0()(64bit) for package: rsyslog-7.2.6-3 .el6.x86_64 --> Processing Dependency: libjson.so.0()(64bit) for package: rsyslog-7.2.6-3.el 6.x86_64 --> Processing Dependency: libestr.so.0()(64bit) for package: rsyslog-7.2.6-3.el 6.x86_64 --> Processing Dependency: libee.so.0()(64bit) for package: rsyslog-7.2.6-3.el6. x86_64 --> Running transaction check ---> Package json-c.x86_64 0:0.9-4.el6 will be installed ---> Package libee.x86_64 0:0.4.1-1.el6 will be installed ---> Package libestr.x86_64 0:0.1.5-1.el6 will be installed ---> Package liblognorm.x86_64 0:0.3.6-1.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: rsyslog x86_64 7.2.6-3.el6 rsyslog-v7-stable 768 k Installing for dependencies: json-c x86_64 0.9-4.el6 rsyslog-v7-stable 36 k libee x86_64 0.4.1-1.el6 rsyslog-v7-stable 21 k libestr x86_64 0.1.5-1.el6 rsyslog-v7-stable 7.9 k liblognorm x86_64 0.3.6-1.el6 rsyslog-v7-stable 26 k Transaction Summary ================================================================================ Install 4 Package(s) Upgrade 1 Package(s) Total download size: 860 k Is this ok [y/N]: y Downloading Packages: (1/5): json-c-0.9-4.el6.x86_64.rpm | 36 kB 00:00 (2/5): libee-0.4.1-1.el6.x86_64.rpm | 21 kB 00:00 (3/5): libestr-0.1.5-1.el6.x86_64.rpm | 7.9 kB 00:00 (4/5): liblognorm-0.3.6-1.el6.x86_64.rpm | 26 kB 00:00 (5/5): rsyslog-7.2.6-3.el6.x86_64.rpm | 768 kB 00:02 -------------------------------------------------------------------------------- Total 222 kB/s | 860 kB 00:03 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : libestr-0.1.5-1.el6.x86_64 1/6 Installing : libee-0.4.1-1.el6.x86_64 2/6 Installing : liblognorm-0.3.6-1.el6.x86_64 3/6 Installing : json-c-0.9-4.el6.x86_64 4/6 Updating : rsyslog-7.2.6-3.el6.x86_64 5/6 warning: /etc/sysconfig/rsyslog created as /etc/sysconfig/rsyslog.rpmnew Cleanup : rsyslog-5.8.10-6.el6.x86_64 6/6 Verifying : libee-0.4.1-1.el6.x86_64 1/6 Verifying : json-c-0.9-4.el6.x86_64 2/6 Verifying : libestr-0.1.5-1.el6.x86_64 3/6 Verifying : rsyslog-7.2.6-3.el6.x86_64 4/6 Verifying : liblognorm-0.3.6-1.el6.x86_64 5/6 Verifying : rsyslog-5.8.10-6.el6.x86_64 6/6 Dependency Installed: json-c.x86_64 0:0.9-4.el6 libee.x86_64 0:0.4.1-1.el6 libestr.x86_64 0:0.1.5-1.el6 liblognorm.x86_64 0:0.3.6-1.el6 Updated: rsyslog.x86_64 0:7.2.6-3.el6 Complete! sh-4.1# service rsyslog stop Shutting down system logger: [ OK ] sh-4.1# service rsyslog start Starting system logger: rsyslogd: error: option -c is no longer supported - igno red [ OK ] vi /etc/sysconfig/rsyslog #SYSLOGD_OPTIONS="-c5" service rsyslog restart
Итак... Обновились с версии 5.8.10 до 7.2.6 и что? Помогло? Нефига не помогло! rsyslogd продолжает пожирать время CPU...
Значит теперь идём в /var/log и мониторим файлы, смотрим на размер файлов журнала и вот оно... - /var/log/messages занимает более 15 ГБ!;( Ждём ещё 5-10 мин, проверяем, и теперь /var/log/messages уже весит более 16 ГБ! Читать его не пробуем имхо зависнем!
Удаляем rm /var/log/messages перезапускаем сисьлог service rsyslog restart и сразу же читаем less /var/log/messages:
Apr 5 05:45:04 myhost kernel: [FW SYN DROP]: IN=eth0 OUT= MAC=00:50:56:a8:7 8:f9:00:04:23:b7:d0:d2:08:00 SRC=80.89.192.62 DST=93.170.129.132 LEN=48 TOS=0x00 PREC=0x20 TTL=116 ID=31712 DF PROTO=TCP SPT=55251 DPT=80 WINDOW=8192 RES=0x00 S YN URGP=0 ............... Apr 5 06:22:08 myhost kernel: [FW SYN DROP]: IN=eth0 OUT= MAC=00:50:56:a8:7 8:f9:00:04:23:b7:d0:d2:08:00 SRC=95.32.239.199 DST=93.170.129.132 LEN=48 TOS=0x0 0 PREC=0x00 TTL=119 ID=6373 DF PROTO=TCP SPT=24617 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
В 05:45:04, т.е. за 1 сек., я насчитал 100-300 и более SYN-пакетов, а это уже явный признак присутствия SYN-флудераста. Отрубив 80.89.192.62 на арену вышел 95.32.239.199, который был менее активен, но тоже с признаками аномальности.
Невзирая на то, что система ограничивала одновременные SYN-подключения и содержала ряд прочих антиДДОС настроек, узким местом оказалось логирование превышения лимита на одновременные SYN-подключения с одного ИП, а следовательно отсюда и повышенное потребление ресурсов CPU демоном rsyslogd, которому приходилось за одну секунду регистрировать 200-300 и более событий.
Отсюда вывод: либо отключить регистрацию событий о превышении лимита на одновременные SYN-подключения или же чаще анализировать события, а также принимать своевременные и адекватные меры.
Но как всегда есть одно "НО" - отключение логирования превышения лимита на одновременные SYN-подключения не позволит обнаружить легитимные ИП поисковых роботов, которые могут регулярно меняться! Т.е. для диапазонов ИП принадлежащих поисковым ботам мы снимаем любые ограничения или ставим более мягкие ограничения, а их ИП (диапазоны) могут меняться или дополняться!
