За последний месяц я заметил в моем средстве просмотра событий на сервере sql множество проверок сбоев. Похоже на атаку грубой силы с ip в китае, пытающуюся войти в учетную запись sa, которую я отключил. Я заблокировал его на своем сетевом брандмауэре, но через неделю я получаю такую же атаку с другого IP-адреса, также находящегося в Китае. Пока я заблокировал 6 ips. Могу ли я что-нибудь сделать, чтобы предотвратить эту атаку, или просто продолжаю блокировать IP-адреса?
Этот сервер должен быть подключен к Интернету, потому что у меня есть сторонние разработчики, которые обращаются к нему. Я посмотрю в настройках файервола. Я использую cisco asa.
Если у вас нет веской причины, не ставьте свой SQL-сервер на периферию вашей сети.
Я вижу, вы думаете, что вам нужен SQL в Интернете, потому что разработчикам нужен доступ. Это не хорошая причина делать SQL доступным в Интернете. У вас есть несколько вариантов, позволяющих вашим разработчикам получать доступ к серверу, не делая доступным SQL-сервер. Они могли подключаться к серверу по SSH и запускать команды SQL через командную строку. Они могли использовать VPN для подключения к серверу и запускать любое приложение. Вы даже можете заблокировать брандмауэр, чтобы разрешить доступ только вашим разработчикам. Вам доступны многие более безопасные варианты.
Для записи, мне больше всего нравится доступ по SSH с использованием ключей для аутентификации. Это дает вам больше возможностей безопасности, и ваши разработчики могут использовать SSH для туннелирования к серверу, если это необходимо, с доступом из командной строки, когда это не так. Вы можете защитить сервер от разработчиков, используя chroot, jail или просто старые разрешения
Ответ: не открывайте свой SQL-сервер напрямую в Интернете.
Другой ответ в этих строках, за который я проголосовал, гласил: «Если вам не нужно», но я не согласен с этой частью этого ответа: если вы считаете, что вам действительно нужно разместить SQL-сервер в Интернете напрямую, то перепроектируйте свое приложение. пока вам больше не придется это делать. Как минимум, если, скажем, у вас есть только один сервер, и он запускает все, тогда брандмауэр отключен от соответствующей коробки и не раскрывает порты SQL-сервера (или что-либо еще, что вам абсолютно не нужно) для внешнего мира.
Это не просто SQL-сервер, или Microsoft, или веб-приложение, это базовый здравый смысл в области безопасности; одна из первых вещей, которые вы делаете для защиты системы, - это минимизация «поверхности атаки», которую могут «увидеть» хакеры.
У вас не должно быть чего-то вроде SQL-сервера, напрямую доступного в публичной сети. Если внешним пользователям нужен доступ, тогда все равно заблокируйте SQL-сервер из общедоступной сети, но предоставьте разработчикам доступ через какую-то настройку VPN (например, настройку OpenVPN или туннелирование через SSH) - таким образом вы не получите соединение с принудительной силой попытки злонамеренных людей / кода, и вы получаете дополнительное преимущество, заключающееся в том, что вся связь между ними и вашим сервером зашифрована (и, при правильных параметрах SSH или VPN, сжата, что может иметь большое значение).
Крайне важно не разрешать публичный доступ к серверу. Держите его за брандмауэром или NAT. Я уверен, что кто-то другой мог бы дать вам более подробный ответ, но решил, что об этом стоит упомянуть.
Если вы должны сделать свой SQL-сервер видимым, скажите своему брандмауэру блокировать повторяющиеся попытки сбоя. Я не знаю, что вы используете, но любой достойный пакет межсетевого экрана позволит вам настроить что-то в этом роде.
Если вы не можете отключить его с помощью брандмауэра, измените порт со значения по умолчанию 1433 на что-то другое - большинство этих попыток будут автоматическими попытками грубой силы и даже не рассматривают возможность использования других портов.
Я согласен с этим, если блок SQL не должен быть обращен к внешней стороне, отключите его или добавьте вторичный сетевой интерфейс, двойной домашний для служб sql в серверной сети и ограничьте доступ к внешнему адаптеру с выходом в Интернет.
В SQL Server используются два режима проверки подлинности: проверка подлинности Windows и смешанный режим (включает как проверку подлинности Windows, так и проверку подлинности SQL Server). Первый режим менее уязвим для атак методом грубой силы, поскольку злоумышленник может столкнуться с блокировкой входа в систему (учетная запись Функция политики блокировки) после конечного числа попыток атаки. В каждой производственной среде, если используется режим проверки подлинности Windows, следует использовать функцию политики блокировки, поскольку она делает невозможными атаки методом перебора.
Когда дело доходит до уязвимости для атаки методом перебора аутентификации SQL Server, ситуация не столь благоприятна. SQL Server Authentication не имеет функций, позволяющих определить, когда система подвергается атаке методом грубой силы. Более того, SQL Server очень быстро реагирует на проверку учетных данных для аутентификации SQL Server. Он может легко справляться с повторяющимися агрессивными попытками входа в систему с использованием грубой силы без отрицательной общей производительности, которая может указывать на такие атаки. Это означает, что проверка подлинности SQL Server является идеальной целью для взлома паролей с помощью атак грубой силы.
Чтобы защитить свой SQL Server от атак методом перебора, вы должны учитывать следующее:
• Не используйте режим аутентификации SQL Server - заставьте злоумышленника заблокировать вход через аутентификацию Windows.
• Если вам нужно использовать режим аутентификации SQL Server, отключите или удалите вход в SA - таким образом злоумышленник должен угадать и связать имя пользователя и пароль.
Вы можете заблокировать sql с помощью брандмауэра, он не требует подключения к Интернету, он общается с apache, у которого есть все необходимое подключение к Интернету, я предлагаю вам установить netlimiter, и вы можете сделать резервную копию своих файлов и выполнить сканирование на вирусы . pref с помощью сканирования загрузки avast.
Удачи.
PS Я не рекомендую использовать какую-либо сборку в брандмауэре ОС Windows, Apple или Linux.