Можно ещё поставить модуль https://www.drupal.org/project/hacked - он найдёт несоответствия в ядре и модулях - покажет какие файлы были изменены. Плюс поиском поискать все вхождения eval и base64 - в файлах и базе.
Был от uptimerobot.com алерт. C 2018-09-03 16:42:45 до 2018-09-03 16:46:05 лежало.
А причем тут ватермарки, имелись ввиду скорее всего права на файлы картинок.
По теме - лучше родного ClamAV никто не справится, базы только ему поставить от malware.expert и maldet - https://www.rfxn.com/projects/linux-malware-detect/
Уязвимость очень серьёзная - варианта исправления 2 - либо обновить ядро Drupal до последнего. Либо второй вариант настроить mod_secure на сервере и прописать одно из двух правил:
# SPECIFIC: Block #submit #validate #process #pre_render #post_render #element_validate #after_build #value_callback #process #access_callback #lazy_builder #type #markup #value #options parameters
SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3298,t:none,block"
SecRule ARGS_NAMES|ARGS_GET|FILES_NAMES|REQUEST_COOKIES_NAMES "#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder|type|markup|value|options)|\[#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder|type|markup|value|options)" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:removeWhitespace"
# GENERIC: Block all parameter names or get args starting with # or containing /# or space# or [#...]
SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3314,t:none,block"
SecRule ARGS_NAMES|ARGS_GET|FILES_NAMES|REQUEST_COOKIES_NAMES "^#|\/#| #|\[(?: )?#.*]" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:compressWhitespace"
Эти правила закрывают и первую и вторую уязвимости на уровне веб сервера. Первое - специфичные для уязвимостей точки входа, второе вообще все возможные комбинации с #-й
А попробуйте добавить:
table_definition_cache = 400
table_open_cache = 400
По умолчанию в новых версиях подняли до 2000 и эпизодически подтекала память.
Всё правильно сделали, более того - я не знаю никого, у кого бы под базы было отдано 80% оперативки - есть же ещё апач, php процессы пользователя и т.п. :)
Так тут CageFS вообще не причем, это они в лимиты LVE упираться начали, достаточно было бы VMEM отключить для начала и всё.
Ну и как эти глюки CageFS выглядят и как их можно повторить? 5 лет юзаем, в первый раз такое слышу, аж интересно стало.
А у CentOS 10 лет :)
7.x - EOL June 30th, 2024
> Я извиняюсь но в каком месте они 1 к 1?
Я отвечал именно на этот вопрос. К слову, если взять конфигурацию побогаче, например за 239$ (13600руб.) Intel Xeon E3-1270v5/32GB/4x464GBSSD RAID10, то в xelent такой же будет стоить 34400руб., скриншот: https://yadi.sk/i/Ub0QtTjw3MjJRr - это более чем в 2 раза дороже.
