Опубликовано

Защита аккаунта от взлома на веб-сайтах и соцсетях

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

Итак, тезисно:

  • Пароли. Существует мнение, что пароли должны быть сложными для того чтобы их не взломали. На самом деле, даже супер-сложный пароль могут подобрать. Особенно, если вы используете один и тот же пароль на разных сайтах. Некоторые сайты (со слабой защитой) могут взломать и базы данных логинов и паролей «утекут» в открытый доступ. Далее, злоумышленники обязательно попробуют именно этот логин и пароль на других популярных сервисах.

Конечно, пароль должен быть не из тех, что простые и распространенные. Но главное, все таки, это количество символов — не менее 10. И самое главное — не использовать один и тот же пароль для различных сервисов. Но чтобы не усложнять вам жизнь, существует такой лайфхак — добавлять к вашему «сложному паролю» несколько символов (систему) в зависимости от сервиса.

Предположим, ваш обычный пароль есть «ParOLb83561». Для YouTube вы можете использовать такой пароль «ParOLb83561-YT» (черточка как разделитель и две буквы, которыми можно зашифровать сервис), для TWitter такой «ParOLb83561-TW». И тогда сложный пароль становится уникальным

  • Двух-факторная авторизация. Этим понятием, уже не удивить, это не диковинка. Многие сервисы и соцсети предлагают ее, как дополнительную меру безопасности. Это не сложно, советую ее использовать в тех сервисах, где взлом будет очень болезненный (или потерей денег или других ценностей).

Наиболее распространённые разновидности: с помощью СМС и подтверждающих кодов Google Authenticator.

  • Ссылки в письмах. К письмам со ссылками или кнопками стоит относится очень скептически. (Злоумышленники умеют маскироваться свой адрес электронной почты под емэйл компании, от лица которой пишут) Вполне вероятно, что злоумышленники сделали свой сайт, похожий на знакомый вам сервис для того, чтобы украсть ваш логин и пароль.

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

  • В продолжении предыдущего пункта — для чувствительных сайтов или соцсетей используйте функцию браузера — избранное, чтобы открывать такие сайты только от туда, а не из писем или даже из поиска в гугле. Так надежнее и исключается возможность попадания на фишинговый (поддельные) сайты.

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

Опубликовано

Защита сайта от брутфорс и ддос атак

Чтобы понять, как защитить веб-систему от брутфорс или ддос атак, необходимо разобраться, что они из себя представляют.

Подробно о брутфорсах было раскатано ранее.

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

Так же «ддосить» эффективнее всего страницы, которые потребляют больше всего ресурсов вашего сервиса, а брутфорсят форму авторизации/восстановления пароля или же аналогичные АПИ для авторизации или восстановления пароля. При этом, злоумышленникам выгоднее, если ваш сайт, все таки доступен, так что они, скорее всего позаботятся, чтобы нагрузка была равномерная.

Итак, общие методы защиты и от брутфорса и от ддоса будут следующие:

  • Выставление лимитов на количество запросов в секунду/минут на уровне веб-сервера
  • Использование инструментов, которые автоматизируют блокировки айпи-адресов или user-agent клиентов, если количество запросов или ошибок блокировки превышает пороговое значение (например, fail2ban)
  • Косвенным инструментом, так же, являются панели мониторинга, настроенные на количество запросов или ошибок, которые позволят оперативно реагировать на параметры, отличные от нормальной ситуации
Пример одного из даш-бордов из Grafana со статусами ответов и ошибок
  • Настроенные уведомления, при изменении поведения вашей системы, т.е. потенциальных атаках
  • Так же важны обновления операционной системы и настройки веб-сервера на соответствующие нагрузки

Что еще можно добавить по бтурфорсам, отдельно

  • Собственные лимиты на формы и АПИ авторизации, восстановления паролей, которые могут быть строже, чем на «любую» страницу
  • На веб-формы можно повесить капчи (google recaptcha) и CSRF-защиту
  • Дву-факторная авторизация (например, с помощью СМС-шлюза или же Google Authenticator)
  • Уведомления пользователям, в случае, если произошла авторизация из неизвестного устройства или локации

Из косвенных методов зашиты:

  • Дополнительные слои анализа и защиты в местах, где выводятся вашим реальным пользователем выводятся деньги или другие ценности, чтобы сделать сложнее жизнь злоумышленнику, даже, если ему удасться взломать пару-тройку аккаунтов
  • Возможность временной блокировки скомпрометированных аккаунтов пользователей
Опубликовано

Nginx basic auth — аутентификация для сайта или папки сайта на Linux

Иногда возникает желание поставить аутентификацию (запаролить) сайт или же папку на сайте.

Например:

  • Для области администрирования
  • Проводятся работы по разработке и рано открывать область или функционал широкому кругу пользователей
  • Область, предназначенная только для разработки
  • Необходимо закрыть от индексирования (не через специальные файлы, а совсем)
  • Есть желание предоставлять доступ к области только для ограниченного круга лиц
  • Другие причины

Генерация аутентификационного файла

Такого рода аутентификация называется Basic auth (или Http auth), подразумевает ввод логина и пароля и выглядит следующим образом

При этом, если логин и пароль не введен или введен не верно — выдает 401ю ошибку

Обычно, файл, в котором хранятся логин и зашифрованный пароль, находится по пути:

/etc/nginx/.htpasswd

Проверим, существует ли уже такой файл

$ sudo su
# cat /etc/nginx/.htpasswd

И если он не существует, создадим такой файл с пользователем user01

# htpasswd -c /etc/nginx/.htpasswd user01

Система предложит 2 раза ввести пароль, который мы заранее подготовили и сохранили. Именно этот логин (user01) и пароль будут использованы для аутентификации

Если же файл .htpasswd существует, можно добавить пользователя таким образом

# htpasswd -c /etc/nginx/.htpasswd user02

При этом, далее, можно в режиме редактирования файла убрать других пользователей, если это необходимо — удалением соответствующих строк.

Если введенные пользователь (user02) уже существует — таким образом, мы просто поменяем ему пароль…

Конфигурирование Nginx

Следующий шаг — внедрение аутентификации в конфигурацию сайта Nginx. При этом, можно закрыть как весь сайт, расположив строчки:

auth_basic "Restricted area";
auth_basic_user_file /etc/nginx/.htpasswd

На уровне server:

server {
    .…
    auth_basic "Restricted area";
    auth_basic_user_file /etc/nginx/.htpasswd
    ….
}

Так и на уровне какой то области (папки), в примере ниже в зоне «admin»:

server {
    .…
    location /admin {
        ….
        auth_basic "Restricted area";
        auth_basic_user_file /etc/nginx/.htpasswd
        ….
    }
    ….
}


После добавления в конфигурацию сайте — не забываем перезагрузить nginx.

Исключения для определенных IP

Бонусом, есть возможность добавить какие то айпишники в «белый список», чтобы для них не запрашивалась аутентификация, а для остальных — запрашивались логин и пароль. Делается это следующим образом:

{
    …
    satisfy any;
    allow 11.22.33.44; # whitelisted IP 1
    allow 22.33.44.55; # whitelisted IP 2
    …
    deny all;
    auth_basic "Restricted area";
    auth_basic_user_file /etc/nginx/.htpasswd;
    …
}