В больших компаниях наоборот пользователям сети делают с двойным или тройным запасом по размеру, почему? Потому что появляются задачи типа DRP и BCP. Например, у нас один офис становится неработоспособным по какой-то причине (залито все оборудование, пожар, пандемия, …) и все работники бегут в другой офис и начинают работать в нем, так вот если бы сетки не были нарезаны с запасом, то пришлось бы нарезать новые, писать правила доступа.
Вадим,
1. Имелось ввиду риск эксплуатации каких-то уязвимостей, слово не дописал.
2. Правила WAF, для ModSecurity есть несколько бесплатных наборов правил. Основной набор правил OWASP (CRS) является стандартным набор правил используется с ModSecurity, поддерживаемый сообществом и наиболее широко используемый, который предоставляет конфигурацию по умолчанию.
Он содержит правила, помогающие остановить распространенные векторы атак, включая внедрение SQL (SQLi), межсайтовый скриптинг (XSS) и многие другие, а также может интегрироваться с Project Honeypot, содержит правила для обнаружения ботов и сканеров.
При установке ModSecurity из репозитория Debian/Ubuntu по умолчанию, modsecurity-crs пакет устанавливается как зависимость. Этот пакет содержит основной набор правил OWASP версии, вам следует использовать последнюю версию основного набора правил.
Он умеет собирать все что записано в файлы, соответственно нужно понять где лежат файлы логов, я нагуглил что тут: Default path for the log file is %systemroot%\system32\LogFiles\Firewall\pfirewall.log.
Или тут: %windir%\system32\logfiles\firewall\pfirewall. log
Осталось проверить где в вашей ОС лежат логи и в конфиге sysmon прописать мониторинг и этого файла
Дмитрий, видимо вы плохой работник, попались на явно злых действиях нарушающих не то что корпоративные правила, но и здравый смысл. У вас очень субъективное мнение. Я лично таких безопасников не знаю.
Иван Петров, отдельный сервер в отдельном сетевом сегменте и недоступный из интернета, логи на него передаются исключительно по syslog - протокол не позволяет создать управляющее воздействие, только дописать новые логи, соответственно на межсетевом экране уровня сети от своего пк открываете ssh/rdp в зависимости от ОС сервера логов. От серверов откуда собираются логи на сервер логов только syslog (tcp или udp в зависимости от размера сообщений, порт 514).
Конечно если злоумышленник начнет писать много логов чтобы зачистить свои децствия поскольку вы настроите ротацию логов, то вам нужно предусмотреть как решить данную проблему
Добавлю: неверная конфигурация сервера, то есть использование слабых параметров, проверить конфигурацию сервера можно так: https://www.ssllabs.com/ssltest/analyze.html?d=habr.com
Например, зная что сервер использует слабые алгоритмы, злоумышленник может попытаться заставить клиента при работе с сайтом заставить перейти на слабый алгоритм, например, на SSL 3.0, а дальше реализовать атаки направленные на уязвимости протокола или его реализации.
Пример: атака POODLE. Впервые об атаке POODLE стало известно в 2014 году. Уязвимость в протоколе SSL 3.0 обнаружил специалист по ИБ Бодо Мёллер (Bodo Möller) с коллегами из Google.
Ее суть заключается в следующем: хакер вынуждает клиента выполнить подключение по SSL 3.0, эмулируя разрывы связи. Затем он ищет в зашифрованном в CBC-режиме трафике специальные сообщения-метки. С помощью серии подставных запросов злоумышленник получает возможность реконструировать содержимое интересующих его данных, например cookies.
А какая конечная задача? Я виду что должен быть гипервизор который делает 3 виртуалки и в каждую подает свой VLAN. Ну будут у вас отключаться сетевые карты, это значит что если злоумышленник захачит одну учетку он просто включит другую карту. Да и разные провайдеры не понять зачем, муть какая-то. 3 провода должны включаться в роутер, а не в ПК.
Основная проблема в том, что ваша CMS доступна прямо из интернета, а не из внутренней сети по VPN, видимо и сама база там же на сервере. Ставьте WAF (mod security для nginx), Wazuh (там и комплаенс проверка и проверка уязвимостей и система обнаружения вторжений и EDR, и контроль целостности файлов), анализируйте логи. Все запускать под разными учетками и максимально зарезать права в системе.
by_EL, по возможности выберите интересующий алгоритм шифрования, выберите интересующую его реализацию в виде исходного кода, например, с github.com и посмотрите как они это делают. Так же можно прочитать RFC интересующего алгоритма, там всегда предусмотрены варианты
DFalco, ГардаБД покупайте или аналог . А вообще не правильное ТЗ, нужно блокировать попытки перебора, а не саму базу. Скажите что предложен неверный метод устранения угрозы. Представьте если бы сайт госуслуг отрубался как-только очередной бот попытался залогиниться под кем-то....
Так же непонятно, попытки при прямом доступе по SQL? Если нет, то значит есть какое-то приложение (сервер приложений) которое принимает запросы скорее всего по HTTPS, тогда WAF можно поставить и на нем блокировать запросы еще до того как они в базу полетят. Если запросы приходят от легитимного внутреннего пользователя, тогда нужно доступ к базе делать только с изолированных ПК которые не имеют никуда доступа кроме как к базе или самому сервису в целом), чтобы нельзя было на этом ПК открыть фишинг письмо к примеру, чтобы вообще не было внешнего входящего доступа на ПК. Нужно делать очень сильную межсетевую экранированность сети, все внутренние ПК имеющие доступ к корпоративным сервисам и внешним сетям как потенциально скомпрометированные. Нужно настроить мониторинг событий безопасности и смотреть на безопасность в целом. Попытка перебора пароля это вообще не инцидент ИБ, вот если этому предшествовало взлом ПК и запуск зла на ПК, то тут да стоит ПК отрубить от сети, НО не базу.
Безопасность защищает конфиденциальность, целостность, доступность. Защищать конфиденциальность нарушая доступность это не решение задачи с точки зрения ИБ...
