Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Вопрос о безопасности у хостеров

Всем привет.

С 2013 года у меня крутится на DigitalOcean небольшой инстанс. На нем я провожу всякие эксперименты(добрые) и иногда в nginx размещаю всякие поделки для публичного доступа.

Сегодня, в качестве увлекательного чтива на ночь я решил почитать логи nginx, узнать кто и что запрашивет, затем полез в логи MySQL и мягко говоря ахринел. В error.log содержится 99% информации о access denied ситуациях:

2016-09-27T15:32:42.526071Z 1054 [Note] Access denied for user 'root'@'222.186.21.161' (using password: NO)
2016-09-27T15:32:43.084902Z 1055 [Note] Access denied for user 'root'@'222.186.21.161' (using password: YES)
2016-09-27T15:32:43.649984Z 1056 [Note] Access denied for user 'root'@'222.186.21.161' (using password: YES)
2016-09-27T15:32:44.208965Z 1057 [Note] Access denied for user 'root'@'222.186.21.161' (using password: YES)
2016-09-27T15:32:44.769395Z 1058 [Note] Access denied for user 'root'@'222.186.21.161' (using password: YES)

Следуя частоте обращения я могу сделать вывод, что кто-то с разных ip адресов целенаправлено брутфорсит доступ к моей базе.
Исследуя другой лог, в этот раз уже системный, вижу ту же самую информацию — кто-то целенаправленно лезет под рутом на мой инстанс.

Если про пароли я не переживаю, они у меня сложные, то понять то, каким образом ip моего инстанса оказался в руках злоумышленников я ума не приложу.

Возникает вопрос к знатокам: можно ли доверять хостерам и в частности DigitalOcean в том, что они НЕ сливают ip своих инстансов куда-то публично, при условии, что с моей стороны я никому не светил свой ip? Какие еще образом мой инстанс мог быть скомпроментирован?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Пулы айпи адресов всех провайдеров вроде как есть в открытом доступе. Боты стучатся по ним всем, всегда. Проверяют какие известные CMS/CMF установлены, и какие сервисы запущенны, дальше пробуют эксплуатировать известные и неизвестные уязвимости этих сервисов, расчетом, что вы не успели поставить security апдейты. После взлома такая машина подключается в армию ботов и продолжает ломать соседей. Насколько я знаю, сейчас довольно быстро брутфорсятся даже сложные пароли. Если у вас нет чего-то типа fail2ban. C cms такая же беда, если там пароли в md5 или sha1 то это дело времени когда ломанут.

Ломают софтом, не руками. IP могут и просто перебирать, зная диапазоны хостеров. Поэтому и советуют вокруг:
1) Отключить логин по ssh для root и вместо этого использовать другого пользователя с sudo. И авторизацию только ключами. У DO есть туториал на эту тему www.digitalocean.com/...r-setup-with-ubuntu-16-04
2) Отключить доступ по сети к MySQL, оставить только 127.0.0.1. Для подключения клиентом со своей машины — ssh-tunnel

Думал, но как-то заморочено там все :)

А я оце думав, що у програмуванні все заморочено... )

Можете поставить CSF, работает сразу с „коробки”: download.configserver.com/csf/install.txt

Тут дело не в DigitalOcean — такая ситуация кругом
То что я по своим логам вижу — то доходит до маразмов когда в юникс машине по ssh идет брутфорс подбор пароля к казалось бы виндовому акаунту Administrator

IP никто не сливают — просканировать сеть довольно просто и быстро

Если страшно можно поставить fail2ban (главное себя не забанить)
У меня за 7 лет владения всякими впс-ками/серверами переборшики — так и не подобрали пароли, так что минус засраные логи и только

p.s. я бы больше переживал ставя всякие вордресики / пхпББ / плагинчики итд — так как хацкеры тогда скриптом через гугл находят нужные версии взламуемых сайтов и вперед
Таким образом сайты знакомых ломали не раз

p.s. я бы больше переживал ставя всякие вордресики / пхпББ / плагинчики итд — так как хацкеры тогда скриптом через гугл находят нужные версии взламуемых сайтов и вперед
Таким образом сайты знакомых ломали не раз

Подобные риски также можно уменьшить, на данный момент большинство атак на подобные веб-приложения проходит с использованием «хорошо известных» уязвимостей, в большинстве случаев для того чтобы себя обезопасить достаточно регулярно обновлять веб-приложения, при условии грамотного администрирования системы. Также можно пользоваться утилитами для проведения аудита веб-приложений, например для WP — это WPScan.

То что я по своим логам вижу — то доходит до маразмов когда в юникс машине по ssh идет брутфорс подбор пароля к казалось бы виндовому акаунту Administrator

Я не уверен что это «маразм», скорее всего атакующий не смог правильно идентифицировать целевую операционную систему, такое случается :)

p.s. я бы больше переживал ставя всякие вордресики / пхпББ / плагинчики итд — так как хацкеры тогда скриптом через гугл находят нужные версии взламуемых сайтов и вперед
Отдельный юзер на каждый сайт с php, довольно безопасно

Если честно я не уверен что Вы правильно понимаете в чем смысл данного мероприятия. Смысл в том что когда эксплуатация уязвимости в веб приложении уже произошла и атакующий получил доступ к выполнению команд или файловой системе — ограничить дальнейшие возможности атакующего. Например ограничить доступ к файловой системе, или список команд для выполнения, как правило этот прием комбинируется с монтированием файловой системы на которой находиться веб-приложение с no execute, no suid, no guid флагами и chmod’oм каталогов на 700, файлов на 600. Но и в таком случае есть возможность для продвижения атаки используя ошибки системы ведущие к горизонтальному\вертикальному privilege escalation. В тоже время если целью атакующего был доступ к файловой системе и компрометация документов находящихся в закрытом доступе на данном веб-ресурсе, он уже достиг своей цели и необходимости в продвижении атаки нет.

Да, я понимаю о чем Вы. Просто я сталкивался с ситуацией, когда через сайт на джумле заражали все соседние, и судя по всему атака проводилась в автоматическом режиме, и цель была именно продвижение. Хотя бы от таких ситуаций защищает.

Пост и комменты вещь! Кратко и доступно на одной странице по вопросу, который меня давно интересовал.

Привет. На самом деле все гораздо проще. IP 222.186.21.161 c которого «атаковали» Ваш сервер находиться в China, Nanjing. Подобного рода атаки характерны для China и идут в автоматическом режиме на большой диапазон IP адресов, с примерно следующим алгоритмом:
1. Поиск доступных IP в заданном диапазоне c открытым 22м портом.
2. Комбинированный (атака по словарю с мутацией и перебор до 8ми символов) bruteforce учетной записи root.
3. go to 1.
Доверять hosting’ам можно, это их деньги, если вскроется факт «слива» важной информации — компания понесет финансовые и репутационные убытки.
Для того чтобы минимизировать риски необходимо сделать доступ к ssh только по ключу, убрать возможность логина пользователя root через ssh, для административных задач использовать пользователя(не root) с доступом к выполнению sudo\su через предварительную авторизацию(пароль),не забывать про регулярные security update и держать открытыми в мир только необходимые службы.

читаю, и будто реченька льется. Такие ответы — музыка для души :)

добавлю еще что можно ssh на какой-то левый 5значный порт повесить, а 22 закрыть

Можно, этот подход называется «security through obscurity» (безопасность через неясность), но на мое мнение этот прием не сильно снижает риски, лишь усложняет поиск и идентификацию служб. Для того чтобы данный фокус был эффективный нужно иметь активную защиту от port scanning и service fingerprint, а это уже выходит за рамки данной темы :)

Немножко поворчу:

Для того чтобы минимизировать риски необходимо сделать доступ к ssh только по ключу, убрать возможность логина пользователя root через ssh
Достаточно оставить только по ключу в принципе.
для административных задач использовать пользователя(не root) с доступом к выполнению sudo\su через предварительную авторизацию(пароль),
В случае sudo врядли поможет (разве что если залезут через уязвимости в приложении, но те юзеры не должны быть sudoers ни при каких раскладах), т.к. после брутфорса у хакера уже будет пароль этого юзера.

Сейчас с su — sudo уже наигрались и сошлись на мнении, что смысл данных команд в основном в том, чтобы не отстрелить себе ногу, а не в конфиденциальности. Для многопользовательских систем — другое дело, там аудит должен определять кто конкретно что делал.

не забывать про регулярные security update
Минимум раз в месяц.
и держать открытыми в мир только необходимые службы.
Желательно переставив порты для администрирования типа sshd, дабы сканеры, бьющие «по площадям» диапазонов, без полного перебора их не находили.

С Вашего позволения и я поворчу :)

В данном случае использования пользователя отличного от root с доступом по ключу и авторизацией на sudo\su нужны для того чтобы реализовать «defense in depth» в данном случае используются разные механизмы для доступа к серверу (ключ) и выполнению привилегированных команд (пароль) для того чтобы получить полный доступ к серверу нужно:
1. Узнать пользователя.
2. Украсть ключ.
3. Узнать пароль к sudo.

В вашем случае достаточно выполнить один пункт — 2й.

Сейчас с su — sudo уже наигрались и сошлись на мнении, что смысл данных команд в основном в том, чтобы не отстрелить себе ногу, а не в конфиденциальности.

Если вдаваться в буквоедство то конфиденциальность и авторизация это разные термины, в данном случае правильный термин — авторизация, sudo не обеспечивает конфиденциальность.

Желательно переставив порты для администрирования типа sshd, дабы сканеры, бьющие «по площадям» диапазонов, без полного перебора их не находили.

О «security through obscurity» писал выше.

С Вашего позволения и я поворчу :)
Приятно поворчать с хорошим человеком! :)
В вашем случае достаточно выполнить один пункт — 2й.
В принципе да. Но для того, чтобы его украсть (а отбрутфорсить его врядли удастся без помощи Эшелона;)), нужно полностью скомпрометировать клиентскую ОС. А там добраться до логина даже проще чем до ключа.
sudo как доп. защита имеет смысл только, если аутентификация по ключу, иначе пароль уже известен.
Если вдаваться в буквоедство то конфиденциальность и авторизация это разные термины
Соглашусь, конечно. Выразился неудачно. Я исходил из списка: конфиденциальность, целостность и доступность и в этом списке ААА относится больше к конфиденциальности.
О «security through obscurity» писал выше.
Тут скорее речь об обходе стандартных методик reconnaissance, где обычно используется набор стандартных портов для nmap при сканировании больших диапазонов. При таргетированной атаке не спасет, но в принципе будет нелишним.

Кстати никто не посоветовал ТС-у обратить пристальное внимание на защиту своей рабочей станции, а зря. Собственно крайне желательно, чтобы уровень ее безопасности соответствовал обслуживаемым серверам.

Приятно поворчать с хорошим человеком! :)

Взаимно ! :)

А там добраться до логина даже проще чем до ключа.sudo как доп. защита имеет смысл только

Подразумевается что пользователь и пароль хранятся только в памяти человека, в таком случае узнать пользователя будет сложно.


если аутентификация по ключу, иначе пароль уже известен.

Согласен, но в том-то и смысл.

Соглашусь, конечно. Выразился неудачно. Я исходил из списка: конфиденциальность, целостность и доступность и в этом списке ААА относится больше к конфиденциальности.

На данный момент в мировой практике к классической CIA во многих источниках добавляют также authentication/authorization и non-repudiation.

Тут скорее речь об обходе стандартных методик reconnaissance, где обычно используется набор стандартных портов для nmap при сканировании больших диапазонов. При таргетированной атаке не спасет, но в принципе будет нелишним.

Соглашусь, если я Вас понял правильно — именно об этом я и писал. Уточню, данный фокус работает только в сочетании с более эффективными механизмами, сам по себе, на мое мнение — не эффективен.

Кстати никто не посоветовал ТС-у обратить пристальное внимание на защиту своей рабочей станции, а зря. Собственно крайне желательно, чтобы уровень ее безопасности соответствовал обслуживаемым серверам.

Бесспорно.

Можно добавить про port knocking — все порты (кроме http[s]) на серваке должны быть закрыты, а нужный открывается если «постучать» определенным образом (обычно по UDP), у DO есть даже статья по теме — www.digitalocean.com/...-from-attackers-on-ubuntu

Прикольная вещь. Однако с винды могут быть сложности с набором тула для создания последовательности.

Японский городовой — несчастные ведроюзеры никогда не слышали о netcat ? Там же в статье есть пример специально для таких чайников

Японский городовой — несчастные ведроюзеры никогда не слышали о netcat ?
Вы не поверите... ;)

Ну, тогда можно как в том самом Мюнхаузене — записать в свой дневник чайника: 12:00 — Совершить подвиг, а скобках (скачать netcat под венду)

а почему инстанс скомпрометирован? Нашли вашу поделку в публичном доступе -> нашли сервер -> попробовали брутфорсить сервисы, слушающие дефолтные 22 и 3306 порты. Или я что-то не так понял?

Возможно где-то нашли мои поделки, но на вскидку первые пять ip из списка оказались китайскими :) Совпадение? Я так не думаю© :)

Если про пароли я не переживаю, они у меня сложные, то понять то, каким образом ip моего инстанса оказался в руках злоумышленников я ума не приложу.

nmap.org

Оставлять порт mysql открытым наружу обычно мягко говоря не очень хорошая идея.
Для ssh рекомендуется избавляться от паролей и оставлять только ключи.

Я просто периодически дергаю базу со своего ноутбука. Спасибо за инфу

Дергайте через VPN или SSH туннель

Подписаться на комментарии