// codeart.ru / Обзоры / Журнал «Хакер» написал про то как вымогают деньги за сайты, а мы расскажем на чем попадались сами Форум

Журнал «Хакер» написал про то как вымогают деньги за сайты, а мы расскажем на чем попадались сами rss подписка

Автор: Evgeniy Sergeev

Интересную заметку под интригующим названием Хочешь сайт обратно? Плати опубликовал журнал Хакер. Коротко расскажу в чем суть метода. На первом этапе в модули сайта внедряется вирус, который перехватывает и шифрует данные, до того как они попадают в БД. Чтобы подмена стала заметна не сразу, вирус некоторое время позволяет получать шифрованные данные и корректно их отображает. Но в один прекрасный день, ключи шифрования удаляются и пользователи видят мусор вместо своих данных. Чтобы вернуть данные владельцам сайта приходится платить злоумышленникам.

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

Долгое время мы использовали git для отслеживания изменений в скриптах

Все наши сайты крутятся на нескольких VPS и нужно сказать, что за время их существования мы несколько раз были настолько беспечны, что допускали инфицирование наших скриптов зловредными программами. Как правило злоумышленники использовали «дыры» в WordPress-е или PHPBB, через которые успешно наносили вред нашим проектам.

Довольно быстро мы поняли, что вооружен тот, кто предупрежден. И для успешной борьбы с вирусами нужно знать кто, когда и как изменял наши скрипты.

Когда мы задумались о том как отслеживать изменения в наших файлах, мы вдруг поняли, что мы это уже делаем! Ведь мы используем систему контроля версий — git. Поэтому достаточно дать команду «git status» и узнать какие изменения произошли.

Мы настроили наши сервера так, чтобы раз в сутки запускался скрипт, который проверяет статус git-репозитория. В случае если зафиксированы изменения от head-версии, выполняется откат. Чтобы атаки не проходили бесследно нам дополнительно отправляется электронное сообщение.

Достаточно долго мы жили без бед, используя указанный выше метод защиты, но оказалось, что мы слишком расслабились и перестали соблюдать элементарные правила безопасности. Так мы сделали самую позорную ошибку за все время нашей работы с собственными VPS. Случилась это на новом VPS, который мы недавно купили у SimpleCloud. Ошибки было аж три.

А потом нас хакнули…

Во-первых, мы не настроили файрвол. Как-то было не до того и мы оставили сервер совершенно открытым для любого вида трафика. Сколько раз мне рассказывали истории про беспечных горе админов, которые забывали или ленились закрыть лишние дыры с помощью Firewall. Никогда не думал, что окажусь одним из них.

Во-вторых, что еще хуже, чем первая ошибка. Мы не поменяли дефолтный ssh-порт. А продолжали использовать стандартный SSH (22). И это при том, что везде, абсолютно везде говорят о том, что порт SSH демона нужно менять сразу после того как сервер развернут. Но мы отложили этот вопрос, как и вопрос с файрволом, на потом.

В-третьих, мы поменяли дефолтные пароли postgres пользователя на что-то совсем простое. А сделали мы так просто потому, что неправильно понимали как работает служебный пользователь postgres. Бывает…

В итоге, буквально через пару недель после того как наш сервер стал доступен в Интернете, на него была совершена атака. Буквально за десяток попыток пароль к нашему postgres пользователю был подобран. Далее был получен доступ по SSH. И в зключение злоумышленник создал бота, который начал сканирование интернета в таких же балбесов как мы.

Все могло закончиться печально, но админы одного из серваков, который попал в зону внимания свежеустановленного бота, написали гневное письмо, чтобы мы разобрались и устранили проблемы. Мы, конечно, разобрались, настроили файрвол, настроили уведомления о том куда и по каким протоколам лезет наш VPS, поправили ssh-порт, почистили все хвосты, которые оказались на нашем сайте. Сделали все то, что нужно было сделать сразу. Сделали быстро, буквально за вечер.

Вывод мы сделали простой — лучше когда мучается и рвет волосы на голове кто-нибудь другой. В том смысле, что Backend as Service — это классно.

  1. Честно говоря никогда не видел смысла менять дефолтный порт, ну да это мое личное.

    А вот про пользователя postgres стало чертовски интересно.
    Почему сервисная устетка: 1) имеет шел и 2) имеет пароль?

    Не могули бы вы просветить касательно шела? Ибо сам не пользую пострес.

    Ну и по поводу пароля.
    На одном из доступных мне серверов:
    cat /etc/shadow | grep postgres
    postgres:!:14934::::::

    Под таким пользователем нельзя авторизоваться.

  2. Vovochka, вот я тоже как-то удивился тому, что к серваку подключились под пользователем postgres. Потому как по-умолчанию этот пользователь заблокирован для входа:
    postgres:*:15689:0:99999:7:::

    Но на новом серваке у нас вместо «*» указан зашифрованный пароль. Поэтому я и оговорился, что возможно в какой-то момент мы зачем-то поменяли пароль на postgres и поэтому вход по ssh стал возможен. Причем поставили что-то совсем простое, потому что судя по логу подобрали пароль очень быстро.

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

    UPD. хорошее объяснение как нужно было настроить чтобы все было секьюрно — http://serverfault.com/questions/110154/whats-the-default-superuser-username-password-for-postgres-after-a-new-install

  3. Блин, читаю что я понаписал и ужасаюсь количеству опечаток..
    Нет, честно, я писал это трезвым 😀

    Спасибо за разъяснения.

Leave a Reply

« »