Собрал в одну заметку замечания по настройке службы SSHD, которая обеспечивает подключение к серверам по SSH. Эта служба присутствует практически во всех серверах. Сказал бы даже, что во всех. Я не припоминаю ни одной виртуалки или железного сервера, куда бы не было доступа по SSH. По возможности, доступ к этой службе лучше закрывать от публичного доступа, но иногда это либо затруднительно, либо вообще невозможно.
Настройки этой службы обычно живут в конфигурационном файле
1️⃣ Аутентификация по паролю. Включать или отключать, каждый решает сам для себя. Я лично всегда аутентификацию по паролю оставляю. Просто на всякий случай. Если пароль несловарный, то подобрать его всё равно практически нереально. Проблем с безопасностью это не вызывает.
Если аутентификацию по паролю отключить, то сразу отваливаются все боты, что непрерывно долбятся в службу. Лог будет менее замусорен.
2️⃣ Аутентификация с использованием публичных ключей. По умолчанию она включена и какой-то отдельной настройки не требует. Решил добавить этот пункт, чтобы лишний раз напомнить про ed25519 ключи. Они более надёжны и, что полезно на практике, более короткие. С ними удобнее работать. У меня была отдельная заметка про их использование.
3️⃣ Разрешение на аутентификацию пользователю root. Тут тоже не буду ничего рекомендовать. Каждый сам решает, разрешает он руту аутентификацию или нет. Если я работаю на сервере один, то обычно аутентификацию разрешаю и работаю всегда под root. Я туда только для этого и захожу, мне не нужны другие пользователи с ограниченными правами. Если же вы работаете не один, то разумнее разделять пользователей, работать через sudo и логировать действия всех пользователей. Так что универсального совета быть не может.
Если вы сами ещё не определились, как вам лучше, то отключите эту возможность. Когда разберётесь, сделаете, как вам надо.
4️⃣ Ограничение на подключение на уровне группы или пользователей. Только пользователи определённой группы или явно указанные смогут подключаться по SSH. Я на практике именно для SSH не пользуюсь этой возможностью, а вот пользователей, которые подключаются по SFTP, обычно завожу в отдельную группу и разрешаю по SFTP подключаться только им. Но это другая настройка. Будет ниже.
5️⃣ Порт, на котором работает служба. Стандартный - 22. Большого смысла менять его нет. Как только первые боты разузнают, что у вас на каком-то порту работает служба, начнут туда долбиться, так же, как и на 22-й. Да и в shodan скорее всего информация об этом появится. Я по привычке порт меняю, если он доступен публично. Хуже от этого не будет, особенно если вы от сканирования портов тоже закрылись. Если служба закрыта от публичного доступа, то оставляю, как есть.
6️⃣ Количество попыток входа в систему за один сеанс. При достижении максимально разрешенного числа попыток, сеанс обрывается.
Пользователь подключился, 3 раза неправильно ввёл пароль, его отключает. После этого нужно устанавливать новое соединение.
7️⃣ Ограничение сессий внутри одного SSH-подключения. Не путать с ограничением на количество параллельных сессий с одного хоста. Этот параметр отвечает не за это. Если вы просто подключаетесь к серверу и его администрируете, то вам хватит и одной сессии.
8️⃣ Принудительный запуск какой-то конкретной команды после регистрации пользователя в системе. Например, запускаем не стандартную оболочку, а прокладку, которая будет логировать все действия пользователей. Вот пример с log-user-session. А вот с принудительным запуском подсистемы sftp. Показываю сразу рабочий пример с подключением по sftp заданной группы пользователей, с chroot в конкретную директорию и с umask 002 для новых файлов.
#linux #security
Настройки этой службы обычно живут в конфигурационном файле
/etc/ssh/sshd_config.1️⃣ Аутентификация по паролю. Включать или отключать, каждый решает сам для себя. Я лично всегда аутентификацию по паролю оставляю. Просто на всякий случай. Если пароль несловарный, то подобрать его всё равно практически нереально. Проблем с безопасностью это не вызывает.
PasswordAuthentication yesЕсли аутентификацию по паролю отключить, то сразу отваливаются все боты, что непрерывно долбятся в службу. Лог будет менее замусорен.
2️⃣ Аутентификация с использованием публичных ключей. По умолчанию она включена и какой-то отдельной настройки не требует. Решил добавить этот пункт, чтобы лишний раз напомнить про ed25519 ключи. Они более надёжны и, что полезно на практике, более короткие. С ними удобнее работать. У меня была отдельная заметка про их использование.
PubkeyAuthentication yes3️⃣ Разрешение на аутентификацию пользователю root. Тут тоже не буду ничего рекомендовать. Каждый сам решает, разрешает он руту аутентификацию или нет. Если я работаю на сервере один, то обычно аутентификацию разрешаю и работаю всегда под root. Я туда только для этого и захожу, мне не нужны другие пользователи с ограниченными правами. Если же вы работаете не один, то разумнее разделять пользователей, работать через sudo и логировать действия всех пользователей. Так что универсального совета быть не может.
Если вы сами ещё не определились, как вам лучше, то отключите эту возможность. Когда разберётесь, сделаете, как вам надо.
PermitRootLogin no4️⃣ Ограничение на подключение на уровне группы или пользователей. Только пользователи определённой группы или явно указанные смогут подключаться по SSH. Я на практике именно для SSH не пользуюсь этой возможностью, а вот пользователей, которые подключаются по SFTP, обычно завожу в отдельную группу и разрешаю по SFTP подключаться только им. Но это другая настройка. Будет ниже.
AllowGroups sshgroupAllowUsers user01 user025️⃣ Порт, на котором работает служба. Стандартный - 22. Большого смысла менять его нет. Как только первые боты разузнают, что у вас на каком-то порту работает служба, начнут туда долбиться, так же, как и на 22-й. Да и в shodan скорее всего информация об этом появится. Я по привычке порт меняю, если он доступен публично. Хуже от этого не будет, особенно если вы от сканирования портов тоже закрылись. Если служба закрыта от публичного доступа, то оставляю, как есть.
Port 226️⃣ Количество попыток входа в систему за один сеанс. При достижении максимально разрешенного числа попыток, сеанс обрывается.
MaxAuthTries 3Пользователь подключился, 3 раза неправильно ввёл пароль, его отключает. После этого нужно устанавливать новое соединение.
7️⃣ Ограничение сессий внутри одного SSH-подключения. Не путать с ограничением на количество параллельных сессий с одного хоста. Этот параметр отвечает не за это. Если вы просто подключаетесь к серверу и его администрируете, то вам хватит и одной сессии.
MaxSessions 18️⃣ Принудительный запуск какой-то конкретной команды после регистрации пользователя в системе. Например, запускаем не стандартную оболочку, а прокладку, которая будет логировать все действия пользователей. Вот пример с log-user-session. А вот с принудительным запуском подсистемы sftp. Показываю сразу рабочий пример с подключением по sftp заданной группы пользователей, с chroot в конкретную директорию и с umask 002 для новых файлов.
Subsystem sftp internal-sftp -u 002Match User sftpusers ChrootDirectory /var/www ForceCommand internal-sftp -u 002#linux #security
12👍156👎3
Ранее рассказывал о том, как можно выпустить самоподписанный сертификат, установить его в веб сервер и настроить доверие. В комментариях были замечания, что это неудобно делать вручную для многих серверов. То решение было описано для одного сервера. Ниже рассмотрю вариант, как решить эту же задачу, только для всей внутренней инфраструктуры.
Речь пойдёт про open source центр сертификации от компании SmallStep - step-ca. Его можно развернуть у себя и использовать для различных задач. Я расскажу на примере получения HTTPS-сертификатов X.509 для локальных веб ресурсов с помощью протокола ACME и одноимённой утилиты. Помимо этого на базе step-ca можно организовать:
◽выдачу SSH-сертификатов для пользователей
◽выпуск токенов единого входа OAuth OIDC
◽выпуск клиентских сертификатов X.509 для TLS аутентификации
Всё это описано в документации и в рамках заметки не раскрыть.
Установка step-ca описана в документации. Выглядит она относительно просто, так как есть готовые пакеты. А относительно, потому что юнит systemd и рабочие каталоги придётся делать вручную.
Вот инструкция для установки на Debian/Ubuntu:
После установки делаем начальную настройку, но перед этим выполним ручную инициализацию. Покажу свои ответы на вопросы в тестовой среде, чтобы вам не гадать, что там отвечать. Хотя по смыслу понятно.
Теперь переносим настройки в
В файл
Содержимое не привожу, оно длинное, в заметку не уместится. Взял 1 в 1 из документации, он же в репозитории.
Служба должна запуститься на порту 443. Можно браузером зайти. Там будет страница с ошибкой, потому что никакого веб интерфейса нет, но тем не менее будет видно, что сервис работает.
Сразу отмечу важный нюанс. По умолчанию step-ca выпускает сертификаты на 24 часа. Для каких-то задач это, наверное, нормально, но для веб серверов не вижу смысла перевыпускать так часто, даже с учётом того, что это автоматизировано. Можете оставить так, а можете увеличить время. Тут об этом рассказано в доках.
Активируем ACME провизионер в step-ca:
Эта команда добавит некоторые настройки в ca.json. Перезапускаем службу:
Теперь можно брать acme.sh или любой другой клиент (certbot и т.д.) и настраивать выпуск сертификатов через свой CA. Для этого надо либо на клиентских системах добавить root_ca.crt в системные, либо при запуске клиента указывать явно:
Работаем с этим CA так же, как и с другими: добавляем серты в веб сервера, настраиваем автообновление. И не забываем в клиентские машины добавить CA в доверенные, чтобы в браузерах не было предупреждения.
#security #webserver
Речь пойдёт про open source центр сертификации от компании SmallStep - step-ca. Его можно развернуть у себя и использовать для различных задач. Я расскажу на примере получения HTTPS-сертификатов X.509 для локальных веб ресурсов с помощью протокола ACME и одноимённой утилиты. Помимо этого на базе step-ca можно организовать:
◽выдачу SSH-сертификатов для пользователей
◽выпуск токенов единого входа OAuth OIDC
◽выпуск клиентских сертификатов X.509 для TLS аутентификации
Всё это описано в документации и в рамках заметки не раскрыть.
Установка step-ca описана в документации. Выглядит она относительно просто, так как есть готовые пакеты. А относительно, потому что юнит systemd и рабочие каталоги придётся делать вручную.
Вот инструкция для установки на Debian/Ubuntu:
# wget https://dl.smallstep.com/cli/docs-ca-install/latest/step-cli_amd64.deb# dpkg -i step-cli_amd64.deb# wget https://dl.smallstep.com/certificates/docs-ca-install/latest/step-ca_amd64.deb# dpkg -i step-ca_amd64.debПосле установки делаем начальную настройку, но перед этим выполним ручную инициализацию. Покажу свои ответы на вопросы в тестовой среде, чтобы вам не гадать, что там отвечать. Хотя по смыслу понятно.
# step-cli ca init✔ Deployment Type: Standalone✔ (e.g. Smallstep): PrivateCA (можно любое имя использовать)✔ (e.g. :443 or 127.0.0.1:443): :443✔ (e.g. you@smallstep.com): zeroxzed@gmail.com✔ [leave empty and we'll generate one]:✔ Password: E}b;-9DU9UyАВ8TU7$FINl-T8OMТеперь переносим настройки в
/etc/step-ca и запускаем как службу. # useradd --user-group --system --home /etc/step-ca --shell /bin/false step# setcap CAP_NET_BIND_SERVICE=+eip $(which step-ca)# mkdir /etc/step-ca# mv $(step path)/* /etc/step-ca# touch /etc/step-ca/password.txt# chmod 600 /etc/step-ca/password.txt# mcedit /etc/step-ca/password.txt# chown -R step:step /etc/step-caВ файл
password.txt записываем пароль от CA, который был создан во время инициализации. В файлах /etc/step-ca/config/ca.json и defaults.json меняем все пути с /root/.step на /etc/step-ca. И создаём юнит для systemd:# mcedit /etc/systemd/system/step-ca.serviceСодержимое не привожу, оно длинное, в заметку не уместится. Взял 1 в 1 из документации, он же в репозитории.
# systemctl daemon-reload# systemctl enable --now step-caСлужба должна запуститься на порту 443. Можно браузером зайти. Там будет страница с ошибкой, потому что никакого веб интерфейса нет, но тем не менее будет видно, что сервис работает.
Сразу отмечу важный нюанс. По умолчанию step-ca выпускает сертификаты на 24 часа. Для каких-то задач это, наверное, нормально, но для веб серверов не вижу смысла перевыпускать так часто, даже с учётом того, что это автоматизировано. Можете оставить так, а можете увеличить время. Тут об этом рассказано в доках.
Активируем ACME провизионер в step-ca:
# step ca provisioner add acme --type ACMEЭта команда добавит некоторые настройки в ca.json. Перезапускаем службу:
# systemctl restart step-caТеперь можно брать acme.sh или любой другой клиент (certbot и т.д.) и настраивать выпуск сертификатов через свой CA. Для этого надо либо на клиентских системах добавить root_ca.crt в системные, либо при запуске клиента указывать явно:
acme.sh --issue --standalone -d debian12-vm \ --server https://10.20.1.36/acme/acme/directory \ --ca-bundle ~/certs/root_ca.crt \ --fullchain-file debian12-vm.crt \ --key-file debian12-vm.keyРаботаем с этим CA так же, как и с другими: добавляем серты в веб сервера, настраиваем автообновление. И не забываем в клиентские машины добавить CA в доверенные, чтобы в браузерах не было предупреждения.
#security #webserver
👍120👎2
Существует отдельный класс файрволов - NGFW (Next Generation Firewall). Они либо работают в связке с IDPS (Intrusion Detection and Prevention System), либо включает её в себе. Если говорить простыми словами, то это файрвол, интегрированный с системой обнаружения и предотвращения вторжения.
Наиболее известный бесплатный представитель этого класса - Suricata. Она интегрирована в софтовые файрволы Pfsense, OPNsense, IPFire и некоторые российские продукты. Если не ошибаюсь, то в IDECO и ИКС тоже она. Но ниже речь пойдёт не о ней, а о Zenarmor. Это коммерческий продукт, у которого есть функциональная бесплатная версия.
Обратил на него внимание, потому что он интегрирован в OPNsense, легко и быстро устанавливается и настраивается. Я сделал это, проверил работу, всё получилось с первого раза. Сразу скажу, какие задачи умеет решать бесплатная версия Zenarmor:
▪️ Просмотр текущей сетевой активности в режиме реального времени. Видно, какой хост куда обращается. Во время просмотра можно настроить различные блокировки на уровне хоста, адреса или домена назначения, tcp портов.
▪️ Сбор сводной статистики по сетевой активности с возможностью экспорта.
▪️ Блокировка доступа по сформированным спискам сайтов или типам трафика. Можно заблокировать весь трафик voip или https. Можем заблокировать конкретный сайт vk.com или применить сразу готовый список с сайтами, относящимся к социальным сетям или другим категориям.
▪️ Zenarmor регулярно обновляет сигнатуры угроз со своих серверов и теоретически может их предотвращать. На практике я это не проверял, потому что не знаю как. По идее, он должен автоматически блокировать вредоносную активность вирусов.
Всю основную функциональность я проверил. Развернул по небольшому руководству из этого видео:
▶️ Установка Next Generation FireWall Zenarmor в OPNsense
Собственно, оно и было отправной точкой в этой теме. Установил OPNsense, далее плагин Zenarmor. Подключил тестовую машину с виндой к шлюзу и погонял трафик с неё. Настройка очень простая. В приведённом видео всё есть. Там же примеры возможностей, дашбордов, отчётов. Если вам нужны красивые картинки со статистикой для руководства, то это будет неплохим решением.
Все возможности бесплатной версии Zenarmor перечислены на странице со сравнением тарифных планов. Для использования у себя не нужны никакие регистрации. Просто ставим OPNsense и соответствующий плагин из интерфейса шлюза. На выходе получается более удобный и эффективный продукт, нежели существующая в pfsense связка на базе snort+suricata.
⇨ Сайт
#gateway #security
Наиболее известный бесплатный представитель этого класса - Suricata. Она интегрирована в софтовые файрволы Pfsense, OPNsense, IPFire и некоторые российские продукты. Если не ошибаюсь, то в IDECO и ИКС тоже она. Но ниже речь пойдёт не о ней, а о Zenarmor. Это коммерческий продукт, у которого есть функциональная бесплатная версия.
Обратил на него внимание, потому что он интегрирован в OPNsense, легко и быстро устанавливается и настраивается. Я сделал это, проверил работу, всё получилось с первого раза. Сразу скажу, какие задачи умеет решать бесплатная версия Zenarmor:
▪️ Просмотр текущей сетевой активности в режиме реального времени. Видно, какой хост куда обращается. Во время просмотра можно настроить различные блокировки на уровне хоста, адреса или домена назначения, tcp портов.
▪️ Сбор сводной статистики по сетевой активности с возможностью экспорта.
▪️ Блокировка доступа по сформированным спискам сайтов или типам трафика. Можно заблокировать весь трафик voip или https. Можем заблокировать конкретный сайт vk.com или применить сразу готовый список с сайтами, относящимся к социальным сетям или другим категориям.
▪️ Zenarmor регулярно обновляет сигнатуры угроз со своих серверов и теоретически может их предотвращать. На практике я это не проверял, потому что не знаю как. По идее, он должен автоматически блокировать вредоносную активность вирусов.
Всю основную функциональность я проверил. Развернул по небольшому руководству из этого видео:
▶️ Установка Next Generation FireWall Zenarmor в OPNsense
Собственно, оно и было отправной точкой в этой теме. Установил OPNsense, далее плагин Zenarmor. Подключил тестовую машину с виндой к шлюзу и погонял трафик с неё. Настройка очень простая. В приведённом видео всё есть. Там же примеры возможностей, дашбордов, отчётов. Если вам нужны красивые картинки со статистикой для руководства, то это будет неплохим решением.
Все возможности бесплатной версии Zenarmor перечислены на странице со сравнением тарифных планов. Для использования у себя не нужны никакие регистрации. Просто ставим OPNsense и соответствующий плагин из интерфейса шлюза. На выходе получается более удобный и эффективный продукт, нежели существующая в pfsense связка на базе snort+suricata.
⇨ Сайт
#gateway #security
👍85👎4
Посмотрел запись шикарного выступления на тему информационной безопасности:
▶️ Топ-10 артефактов Linux для расследования инцидентов
Очень люблю такой формат, где много примеров и конкретики. Прям всё выступление это примеры из практики. Постарался законспектировать самую суть, чтобы можно было сохранить и вынести для себя пользу. Рекомендую выступление посмотреть, а мою заметку сохранить как шпаргалку. Без просмотра видео от шпаргалки будет не так много пользы. Я зафиксировал авторские синтаксис и пояснения из выступления.
Автор рассказывает про 10 команд для анализа системы в режиме реального времени, которыми пользуется:
◽️
◽️
◽️
◽️
◽️
◽️
◽️
◽️
📌 ТОП 10 системных артефактов, которые проверяем при взломах:
▪️SYSTEM INFO:
◽️/proc/version, /etc/release, /etc/localtime - информация о системе, времени
◽️/proc/mounts, /etc/mtab - монтирование файловых систем
◽️/etc/network/interfaces, /var/lib/NetworkManager/*.lease, /var/lib/dhcp/*.lease, /etc/sysconfig/network-scripts/ifcfg-*, /etc/sysconfig/iptables - сеть, маршруты
◽️/proc/[PID]/cmdline - процессы
▪️LOGS в /var/log:
◽️auth.log, secure.log - аутентификации пользователей
◽️lastlog - последний логин пользователей
◽️btmp - неудачные попытки логина
◽️wtmp - записи о каждом логине, логауте
◽️cron - планировщик cron
◽️dpkg, apt/history.log - установка/удаление пакетов
◽️audit/audit.log - логи аудита, если запущен
▪️SHELL HISTORY
~/bash_history, ~/.history, ~/sh_history, ~/.*_history - история команд оболочки, обязательно настраиваем у всех HISTTIMEFORMAT.
▪️FILE SYSTEM
Ищем изменённые, скрытые, большие файлы, символьные ссылки, расширенные разрешения, setuid
▪️USER ACCOUNTS
/etc/passwd, /etc/shadow, /etc/group, /etc/sudoers, /etc/sudoers.d/*, /etc/profile, /etc/profile.d/*, /etc/bash.bashrc
▪️PUBLIC FACING APP
Публичные приложения, запущенные на сервере: apache, nginx и т.д. Смотрим архитектуру, логи, рабочие директории, версию, уязвимости и т.д.
▪️PERSIST
Места, где злоумышленник или вирус может закрепиться:
/etc/cron/, /var/spool/cron/, /var/spool/anacron, /etc/crontab, /etc/at, /etc/inittab, /etc/init.d/etc/rd[0-6].d/, /etc/rc.boot/, /etc/init.conf, /etc/init, /lib/systemd/system/*, /etc/systemd/system/*
Основное внимание - cron и службы.
▪️CONFIG
Все конфигурации в /etc/
▪️APPLICATION DATA
~/.config, ~/.cache, ~/.local и т.д.
▪️TMP
/tmp, /var/tmp, /dev/shm, /var/run, /var/spool
Это конспект примерно половины выступления. Дальше в основном теория на тему того, как надо защищать сервера и анализировать подозрительную активность и ответы на вопросы. В вопросах дополнили:
- Проверяем файлы в системе на соответствие того, что было установлено из пакетов
- Проверяем реальные сетевые интерфейсы через команду ip, так как не всё может быть отражено в конфигурационных файлах
✅ Отдельно привожу ссылку на свою недавнюю публикацию, где я собрал в похожий список все действия на основе своего опыта, которые имеет смысл выполнить, если у вас есть подозрение на то, что ваш сервер скомпрометировали.
#security
Очень люблю такой формат, где много примеров и конкретики. Прям всё выступление это примеры из практики. Постарался законспектировать самую суть, чтобы можно было сохранить и вынести для себя пользу. Рекомендую выступление посмотреть, а мою заметку сохранить как шпаргалку. Без просмотра видео от шпаргалки будет не так много пользы. Я зафиксировал авторские синтаксис и пояснения из выступления.
Автор рассказывает про 10 команд для анализа системы в режиме реального времени, которыми пользуется:
◽️
ps auxwf - список процессов с дополнительной информацией в древовидном представлении◽️
ss -tupln и netstat -plunto - открытые порты (plunto - имя героя из мультика с микки маусом)◽️
last -Faiwx - список логинов пользователей◽️
tail /var/log/<file> и cat ~/.bash_history - просмотр различных системных логов◽️
ls -lta - список файлов, отсортированный по времени изменения◽️
lsof -V - открытые в настоящий момент файлы ◽️
find / -mtime -2 -ls - все файлы, изменённые за последние 2 дня◽️
stat || statx || istat - различные команды для получения информации о файловой системе📌 ТОП 10 системных артефактов, которые проверяем при взломах:
▪️SYSTEM INFO:
◽️/proc/version, /etc/release, /etc/localtime - информация о системе, времени
◽️/proc/mounts, /etc/mtab - монтирование файловых систем
◽️/etc/network/interfaces, /var/lib/NetworkManager/*.lease, /var/lib/dhcp/*.lease, /etc/sysconfig/network-scripts/ifcfg-*, /etc/sysconfig/iptables - сеть, маршруты
◽️/proc/[PID]/cmdline - процессы
▪️LOGS в /var/log:
◽️auth.log, secure.log - аутентификации пользователей
◽️lastlog - последний логин пользователей
◽️btmp - неудачные попытки логина
◽️wtmp - записи о каждом логине, логауте
◽️cron - планировщик cron
◽️dpkg, apt/history.log - установка/удаление пакетов
◽️audit/audit.log - логи аудита, если запущен
▪️SHELL HISTORY
~/bash_history, ~/.history, ~/sh_history, ~/.*_history - история команд оболочки, обязательно настраиваем у всех HISTTIMEFORMAT.
▪️FILE SYSTEM
Ищем изменённые, скрытые, большие файлы, символьные ссылки, расширенные разрешения, setuid
find / -xdev -print0 | xargs -0 stat -- printf="%i,%h,%n,%x,%y,%z,%w,%U,%G,%A,%s\n" 2>/dev/nullfind "${MOUNTPOINT}" -xdev -print0 | xargs -0 -c "%Y %X %Z %A %U %G %n" >> timestamps.dat▪️USER ACCOUNTS
/etc/passwd, /etc/shadow, /etc/group, /etc/sudoers, /etc/sudoers.d/*, /etc/profile, /etc/profile.d/*, /etc/bash.bashrc
▪️PUBLIC FACING APP
Публичные приложения, запущенные на сервере: apache, nginx и т.д. Смотрим архитектуру, логи, рабочие директории, версию, уязвимости и т.д.
▪️PERSIST
Места, где злоумышленник или вирус может закрепиться:
/etc/cron/, /var/spool/cron/, /var/spool/anacron, /etc/crontab, /etc/at, /etc/inittab, /etc/init.d/etc/rd[0-6].d/, /etc/rc.boot/, /etc/init.conf, /etc/init, /lib/systemd/system/*, /etc/systemd/system/*
Основное внимание - cron и службы.
▪️CONFIG
Все конфигурации в /etc/
▪️APPLICATION DATA
~/.config, ~/.cache, ~/.local и т.д.
▪️TMP
/tmp, /var/tmp, /dev/shm, /var/run, /var/spool
Это конспект примерно половины выступления. Дальше в основном теория на тему того, как надо защищать сервера и анализировать подозрительную активность и ответы на вопросы. В вопросах дополнили:
- Проверяем файлы в системе на соответствие того, что было установлено из пакетов
- Проверяем реальные сетевые интерфейсы через команду ip, так как не всё может быть отражено в конфигурационных файлах
✅ Отдельно привожу ссылку на свою недавнюю публикацию, где я собрал в похожий список все действия на основе своего опыта, которые имеет смысл выполнить, если у вас есть подозрение на то, что ваш сервер скомпрометировали.
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Топ-10 артефактов Linux для расследования инцидентов
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
5👍184👎4
Наглядный пример, почему не стоит сохранять пароли в браузерах. Их оттуда очень легко утянуть незаметно для пользователя. Я что 10 лет назад видел, как это просто сделать, что сейчас.
До последнего думал, что у меня ничего не получится, когда пробовал. Не верил, что за столько лет в хроме ничего не поменялось. Что-то может и поменялось, но всё равно все пароли можно разом утянуть. Можете сами проверить.
Пример для ОС Windows. Идём в репозиторий:
⇨ https://github.com/ohyicong/decrypt-chrome-passwords
Скачиваем исходник файла decrypt_chrome_password.py. Ставим на машину python. Уже не помню, как я ставил на тестовую тачку. Он тут уже стоял на тот момент, когда я тестировал.
Установил зависимости:
Запускаю скрипт. Перед этим специально сохранил пароль от одного сайта:
Получаю тут же в консоли логин и пароль в открытом виде. Он же лежит рядом со скриптом в файле decrypted_password.csv. В нём будут лежать все сохранённые в браузере пароли.
Я перестал сохранять важные пароли в браузерах с тех пор, как впервые увидел подобный трюк. Какие-то малозначительные сохраняю для удобства, либо где есть второй фактор. На что-то важное отменяю сохранение.
#security
До последнего думал, что у меня ничего не получится, когда пробовал. Не верил, что за столько лет в хроме ничего не поменялось. Что-то может и поменялось, но всё равно все пароли можно разом утянуть. Можете сами проверить.
Пример для ОС Windows. Идём в репозиторий:
⇨ https://github.com/ohyicong/decrypt-chrome-passwords
Скачиваем исходник файла decrypt_chrome_password.py. Ставим на машину python. Уже не помню, как я ставил на тестовую тачку. Он тут уже стоял на тот момент, когда я тестировал.
Установил зависимости:
> pip install pycryptodomex sqlite sqliteЗапускаю скрипт. Перед этим специально сохранил пароль от одного сайта:
> python decrypt_chrome_password.pyПолучаю тут же в консоли логин и пароль в открытом виде. Он же лежит рядом со скриптом в файле decrypted_password.csv. В нём будут лежать все сохранённые в браузере пароли.
Я перестал сохранять важные пароли в браузерах с тех пор, как впервые увидел подобный трюк. Какие-то малозначительные сохраняю для удобства, либо где есть второй фактор. На что-то важное отменяю сохранение.
#security
👍150👎10
⚠️ На прошлой неделе подписчик поделился жуткой историей с шифровальщиком. Вообще, они все жуткие, но если бэкапы тоже зашифрованы, то это вообще тушите свет. А там такая история, что в городе пострадало много организаций по одной и той же схеме. Кто-то точечно и системно поработал.
Человек предложил мне поделиться своим опытом на этот счёт. Я сам не раз сталкивался с шифровальщиками. Бэкапы не терял, только данные, к которым был доступ у пользователей. Сначала не хотел писать, так как тут чего-то нового или особенного не расскажешь. Подойдут обычные мероприятия по защите от вирусов. Потом всё же решил написать, чтобы лишний раз напомнить о том, что от шифровальщиков никто не застрахован. Лучше лишний раз поразмыслить над тем, что ты будешь делать, если завтра тебе все данные зашифруют.
Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:
❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.
Иногда такую схему трудно организовать, или просто неудобно. Может быть по-другому. Но хоть одна копия бэкапов без доступа с рабочих серверов должна быть. Иначе будет как у автора комментария к заметке, когда все бэкапы были зашифрованы с самих серверов.
Подробно про бэкапы я не так давно рассказывал в отдельных заметках:
⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов
По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:
🔴 Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.
🔴 Используем антивирусы на пользовательских компах. Если у вас бюджетка или прям совсем бедный бизнес, который не может себе позволить купить антивирус, поставьте бесплатный от Касперского. Базово он защитит от вирусов.
🔴 Не давайте пользователям полные права. Вкупе с антивирусом, это закроет большую часть проблем с их стороны. Хоть и не все.
🔴 Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.
🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.
Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.
#security
Человек предложил мне поделиться своим опытом на этот счёт. Я сам не раз сталкивался с шифровальщиками. Бэкапы не терял, только данные, к которым был доступ у пользователей. Сначала не хотел писать, так как тут чего-то нового или особенного не расскажешь. Подойдут обычные мероприятия по защите от вирусов. Потом всё же решил написать, чтобы лишний раз напомнить о том, что от шифровальщиков никто не застрахован. Лучше лишний раз поразмыслить над тем, что ты будешь делать, если завтра тебе все данные зашифруют.
Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:
❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.
Иногда такую схему трудно организовать, или просто неудобно. Может быть по-другому. Но хоть одна копия бэкапов без доступа с рабочих серверов должна быть. Иначе будет как у автора комментария к заметке, когда все бэкапы были зашифрованы с самих серверов.
Подробно про бэкапы я не так давно рассказывал в отдельных заметках:
⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов
По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:
🔴 Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.
🔴 Используем антивирусы на пользовательских компах. Если у вас бюджетка или прям совсем бедный бизнес, который не может себе позволить купить антивирус, поставьте бесплатный от Касперского. Базово он защитит от вирусов.
🔴 Не давайте пользователям полные права. Вкупе с антивирусом, это закроет большую часть проблем с их стороны. Хоть и не все.
🔴 Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.
🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.
Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.
#security
👍140👎7
В одном из видео с канала samohosting увидел интересную бесплатную утилиту с открытым исходным кодом XCA для создания и управления собственным удостоверяющим центром для выпуска сертификатов под различные службы. Я уже публиковал видео с этого канала в подборках, а сейчас хочу сделать акцент на нём. Очень качественный контент, различные тематики, подача. Рекомендую. Мне хоть и не все темы оттуда интересны, но стоит отдать должное создателю. Человек старается сделать полезный материал.
Возвращаюсь к XCA. Это кроссплатформенное приложение с GUI под все популярные системы: Windows, Linux, MacOS. Под винду можно как портированную версию скачать, так и установить из магазина.
XCA можно использовать для создания сертификатов для таких служб, как OpenVPN, IPsec, веб и почтовые сервера. Подойдёт для любых служб, которые используют TLS сертификаты. Очевидно, что речь идёт о внутренней инфраструктуре, где вы сможете раздать пользователям свой CA, чтобы софт не выдавал предупреждения о недоверенных сертификатах. Хотя для каких-то служб это не очень актуально. Например, для OpenVPN это некритично. Там сертификат CA обычно идёт вместе с конфигурацией без необходимости отдельной установки в систему.
Приложение очень простое и интуитивно понятное, особенно для тех, кто первый раз сталкивается с этой темой. Есть русский язык. Помню, как для меня было суперсложно и непонятно, когда впервые разбирался со скриптами easy-rsa для настройки своего первого OpenVPN сервера. Делал всё это в консоли, где никаких наглядных связей и привязок, только команды для генерации и ещё более длинные команды на базе openssl для просмотра сертификатов.
С одной стороны это хорошо, так как позволило быстрее вникнуть, напрячь мозги и разобраться с темой. С другой, не всем и не часто приходится этим заниматься, так что для разовых задач может быть проще и быстрее всё сделать в GUI. Если у вас нет дальнейших задач по автоматизации процессов, связанных с выпуском сертификатов, то в GUI по-любому будет быстрее и проще работать с сертификатами.
Работа с XCA выглядит следующим образом:
1️⃣ Создаёте новую зашифрованную базу для хранения приватных ключей.
2️⃣ Создаёте новый удостоверяющий центр (Certification authority - CA) с нужными вам параметрами. Основной - срок действия корневого сертификата. Лучше ставить побольше. На моей практике даже 10-ти летние сертификаты протухали, что приводило к проблемам и дополнительной работе.
3️⃣ По желанию можно выпустить промежуточный сертификат, который сделает более безопасной всю цепочку сертификации. В общем случае можно этого не делать.
4️⃣ Создаёте уже клиентские сертификаты. Делаете экспорт и отдаёте сервисам или пользователям.
То есть всё как обычно при работе со своим CA. У меня были заметки по этой теме, но только для консоли:
▪️openssl - все действия на базе openssl.
▪️step-ca - своя локальная служба для управления CA с простой автоматизацией перевыпуска.
▪️CFSSL - современная одиночная утилита от cloudflare с конфигами в формате json.
Странно, что я впервые услышал об этой программе. Вообще не знал и не использовал ни одну локальную программу по этой теме. Веб интерфейсы видел, пользовался. В pfSense, кстати, удобный веб интерфейс для работы со своим CA.
⇨ 🌐 Сайт / Исходники
#security #tls
Возвращаюсь к XCA. Это кроссплатформенное приложение с GUI под все популярные системы: Windows, Linux, MacOS. Под винду можно как портированную версию скачать, так и установить из магазина.
XCA можно использовать для создания сертификатов для таких служб, как OpenVPN, IPsec, веб и почтовые сервера. Подойдёт для любых служб, которые используют TLS сертификаты. Очевидно, что речь идёт о внутренней инфраструктуре, где вы сможете раздать пользователям свой CA, чтобы софт не выдавал предупреждения о недоверенных сертификатах. Хотя для каких-то служб это не очень актуально. Например, для OpenVPN это некритично. Там сертификат CA обычно идёт вместе с конфигурацией без необходимости отдельной установки в систему.
Приложение очень простое и интуитивно понятное, особенно для тех, кто первый раз сталкивается с этой темой. Есть русский язык. Помню, как для меня было суперсложно и непонятно, когда впервые разбирался со скриптами easy-rsa для настройки своего первого OpenVPN сервера. Делал всё это в консоли, где никаких наглядных связей и привязок, только команды для генерации и ещё более длинные команды на базе openssl для просмотра сертификатов.
С одной стороны это хорошо, так как позволило быстрее вникнуть, напрячь мозги и разобраться с темой. С другой, не всем и не часто приходится этим заниматься, так что для разовых задач может быть проще и быстрее всё сделать в GUI. Если у вас нет дальнейших задач по автоматизации процессов, связанных с выпуском сертификатов, то в GUI по-любому будет быстрее и проще работать с сертификатами.
Работа с XCA выглядит следующим образом:
То есть всё как обычно при работе со своим CA. У меня были заметки по этой теме, но только для консоли:
▪️openssl - все действия на базе openssl.
▪️step-ca - своя локальная служба для управления CA с простой автоматизацией перевыпуска.
▪️CFSSL - современная одиночная утилита от cloudflare с конфигами в формате json.
Странно, что я впервые услышал об этой программе. Вообще не знал и не использовал ни одну локальную программу по этой теме. Веб интерфейсы видел, пользовался. В pfSense, кстати, удобный веб интерфейс для работы со своим CA.
⇨ 🌐 Сайт / Исходники
#security #tls
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍139👎2
Где вы оставляете следы, когда подключаетесь по SSH к серверу на базе Linux? Собрал краткую подборку основных ваших артефактов в Debian. Будет актуальна во всех дистрибутивах на её основе. Для других могут отличаться только частности в виде имён и путей к логам, но общий смысл будет тот же.
На всякий случай сразу предупреждаю, что если логи отправляются во внешнее хранилище, то вы там наследили сразу в момент подключения. Поэтому важно иметь своё внешнее по отношению ко всем серверам хранилище системных логов.
1️⃣ Подключение по SSH фиксируется в
Лога может не быть, либо логи могут параллельно храниться в journald. Смотреть так:
2️⃣ Информация о подключении будет записана в бинарный лог
3️⃣ Информация о последнем логине пользователя хранится в бинарном файле
4️⃣ Пока вы не отключились, информация о вашей активной сессии вместе с остальными сессиями хранится в бинарном файле
5️⃣ Если во время подключения были неудачные попытки с неправильным логином и паролем, то эта информация будет сохранена в бинарном файле
6️⃣ Если что-то делали в консоли, то информация об этом сохранится в текстовом файле
В рамках сессии история будет сохраняться и отображаться по команде
Для скрытия информации о подключении можно банально обнулить указанные выше логи и бинарные файлы. О вас не останется информации, но станет понятно, что кто-то подключался. Я, кстати, с подобным сталкивался. Когда только устроился в одну компанию. Через несколько дней после начала работы, когда стал проверять все серваки и разбираться в инфраструктуре, заметил на одном из серверов очищенную историю и прочие следы. Остаётся только гадать, что там делал бывший админ.
Просто взять и удалить информацию о себе из бинарных файлов не очень просто. Как один из вариантов - взять готовый скрипт, который на основе IP адреса вычистит информацию в том числе из бинарных логов. У меня на Debian 12 он не завёлся. Всё время ругался на UTMP block size. Мучал уже родной ChatGPT с chatgpt.com на эту тему, не смог помочь. Много всего предложил, но ничего не помогло. В конце предложил по-другому очистить файл: удалить и заново создать. Забил.
Для того, чтобы от подобных очисток защититься, достаточно на любом Linux сервере запустить syslog сервер или systemd-journal-remote. И вы всегда будете знать, кто и когда к вам подключается. Для логов службы sshd не нужно ни много ресурсов, ни места на диске. Нет нужды разворачивать какое-то специальное хранилище для логов, если у вас в нём нет нужды. Я отдельно для syslog сервера поднимал виртуалку 1CPU/512M/10G.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #security
На всякий случай сразу предупреждаю, что если логи отправляются во внешнее хранилище, то вы там наследили сразу в момент подключения. Поэтому важно иметь своё внешнее по отношению ко всем серверам хранилище системных логов.
1️⃣ Подключение по SSH фиксируется в
/var/log/auth.log. С ним всё просто - это текстовый лог. Сразу посмотреть удачные подключения можно так:# grep 'Accepted' /var/log/auth.logЛога может не быть, либо логи могут параллельно храниться в journald. Смотреть так:
# journalctl -u ssh -r2️⃣ Информация о подключении будет записана в бинарный лог
/var/log/wtmp. Смотреть в консоли командой last. Увидите информацию о дате логина, пользователе, его IP адресе. Там же дополнительно хранится информация о загрузках и выключениях сервера, в том числе кем они были инициированы. Могу сразу для расширенной информации посоветовать ключи: last -Faiwx.3️⃣ Информация о последнем логине пользователя хранится в бинарном файле
/var/log/lastlog. Смотреть одноимённой консольной командой lastlog. Увидите список всех системных пользователей и дату их последнего подключения вместе с IP адресом.4️⃣ Пока вы не отключились, информация о вашей активной сессии вместе с остальными сессиями хранится в бинарном файле
/var/run/utmp. Смотреть информацию оттуда можно командой who.5️⃣ Если во время подключения были неудачные попытки с неправильным логином и паролем, то эта информация будет сохранена в бинарном файле
/var/log/btmp. Смотреть командой lastb.6️⃣ Если что-то делали в консоли, то информация об этом сохранится в текстовом файле
~/.bash_history. Если не хотите, чтобы это происходило, после логина измените место хранения истории через переопределение переменной. Выполните в консоли:# export HISTFILE=/dev/nullВ рамках сессии история будет сохраняться и отображаться по команде
history, но в файл записана не будет.Для скрытия информации о подключении можно банально обнулить указанные выше логи и бинарные файлы. О вас не останется информации, но станет понятно, что кто-то подключался. Я, кстати, с подобным сталкивался. Когда только устроился в одну компанию. Через несколько дней после начала работы, когда стал проверять все серваки и разбираться в инфраструктуре, заметил на одном из серверов очищенную историю и прочие следы. Остаётся только гадать, что там делал бывший админ.
Просто взять и удалить информацию о себе из бинарных файлов не очень просто. Как один из вариантов - взять готовый скрипт, который на основе IP адреса вычистит информацию в том числе из бинарных логов. У меня на Debian 12 он не завёлся. Всё время ругался на UTMP block size. Мучал уже родной ChatGPT с chatgpt.com на эту тему, не смог помочь. Много всего предложил, но ничего не помогло. В конце предложил по-другому очистить файл: удалить и заново создать. Забил.
Для того, чтобы от подобных очисток защититься, достаточно на любом Linux сервере запустить syslog сервер или systemd-journal-remote. И вы всегда будете знать, кто и когда к вам подключается. Для логов службы sshd не нужно ни много ресурсов, ни места на диске. Нет нужды разворачивать какое-то специальное хранилище для логов, если у вас в нём нет нужды. Я отдельно для syslog сервера поднимал виртуалку 1CPU/512M/10G.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #security
526👍291👎2
Вчера одной знакомой мошенники взломали учётную запись от Госуслуг. Причём сделали это таким запутанным способом, что я даже не уверен, что ломали именно их. Расскажу обо всём по порядку. Возможно кто-то с подобным сталкивался. Другим наука будет, чтобы предупредили знакомых и родственников.
1️⃣ 9 утра, человек едет в метро. Раздаётся звонок на телефон. Слышно плохо. Мошенники называют ФИО и адрес проживания. Говорят, что пришла посылка на почту рядом с домом. Чтобы забрать, надо привязать в почте свой номер телефона, на который придёт код подтверждения для забора посылки.
2️⃣ Приходит смс от Госуслуг. Тут первая странность. В смс текст: Для подтверждения смены номера введите код подтверждения: 1234. Не сообщайте никому! Странности тут две. Во-первых, коды подтверждения у Госуслуг 6-ти значные, а тут только 4 знака. Во-вторых, сейчас от Госуслуг приходит другой текст. В конце добавляют, что этот код спрашивают только мошенники. И при этом смс пришла от отправителя gosuslugi и легла в тот же чат, где все остальные смс от реального сервиса.
3️⃣ Человек называет код и тут же понимает, что это какая-то ерунда и обман. Она кладёт трубку, заходит через приложение Госуслуг на смартфоне и меняет пароль. Приходит смс для аутентификации и там 6 знаков и привычный текст.
4️⃣ Человек заходит в свою почту и там видит несколько подозрительных писем:
▪️Первое от реальных Госуслуг, где указано, что её номер введён в другой учётной записи.
▪️Второе фейковое от хостинга Aeza, отправленное с домена aeza_email, где указано, что для подтверждения почты нужно пройти по ссылке и активировать учётку. Тут я уже удивился, так как сначала вообще не понял, при чём тут Aeza. В письме странные ссылки через сокращатели. Не ходил по ним. Письмо точно фейк, потому что у меня есть письма от реальной Аезы. Они по-другому отправляют.
▪️Третье письмо подделано под шаблон Госуслуг. Там сказано, что кто-то совершил вход под вашей учётной записью. Указан IP адрес и расположение: Украина - г. Киев. И ниже указан номер тех. поддержки, куда предлагают позвонить, если это были не вы. Забегая вперёд скажу, что номер мошенников. Письмо отправлено с домена в зоне .org, похожего на госуслуги.
5️⃣ Человек звонит по этому номеру. Там сразу снимают трубку, как-будто ждали звонка. Мужчина без всякого акцента рассказал, что кто-то заходил в учётку, если это не вы, то надо срочно менять пароль и привязку телефона. А потом отложил трубку и судя по всему забыл отключить микрофон. Начал разговаривать матерясь с какой-то девушкой рядом, а та ему говорила, что надо что-то ещё, чтобы она сделала или ничего не получится.
6️⃣ Знакомая поняла, что это опять мошенники, положила трубку. Зашла с компьютера в Госуслуги, снова сменила пароль, убедилась, что привязан её мобильный номер. Для аутентификации все смски с кодами приходили к ней на смартфон.
Всё просмотрела в личном кабинете, вроде никаких изменений. В списке действий ровно одно подозрительное действие как раз после первого звонка, совершённое не с её IP адреса. При этом IP адрес московский. Выполнено действие - отключение входа с подтверждением. Что это значит, не очень понятно, так как подтверждение по телефону реально не отключили.
Вот такая странная история произошла. Ниже список писем в тот день и скрины фейкового письма с госуслуг и от Aeza. Вот последняя меня больше всего интересует. При чём тут вообще этот хостинг? Знакомая с ним никак не связана и вообще не знает, что это такое.
И второй момент. От чего в итоге был передан мошенникам код из 4-х знаков? У меня есть подозрение, что Госуслуги тут только прикрытие каких-то других дел. Я не знаю, можно ли подделать отправителя смс, чтобы его сообщение попало в папку или чат с реальными смс от Госуслуг. А может на смену номера там только 4 символа и остался старый шаблон. Но смена по какой-то причине не состоялась.
Кто-нибудь сталкивался с подобным? Что это может быть? Какая-то многоходовая махинация. Тут и посылка, и фейковые письма, и поддержка.
#security
▪️Первое от реальных Госуслуг, где указано, что её номер введён в другой учётной записи.
▪️Второе фейковое от хостинга Aeza, отправленное с домена aeza_email, где указано, что для подтверждения почты нужно пройти по ссылке и активировать учётку. Тут я уже удивился, так как сначала вообще не понял, при чём тут Aeza. В письме странные ссылки через сокращатели. Не ходил по ним. Письмо точно фейк, потому что у меня есть письма от реальной Аезы. Они по-другому отправляют.
▪️Третье письмо подделано под шаблон Госуслуг. Там сказано, что кто-то совершил вход под вашей учётной записью. Указан IP адрес и расположение: Украина - г. Киев. И ниже указан номер тех. поддержки, куда предлагают позвонить, если это были не вы. Забегая вперёд скажу, что номер мошенников. Письмо отправлено с домена в зоне .org, похожего на госуслуги.
Всё просмотрела в личном кабинете, вроде никаких изменений. В списке действий ровно одно подозрительное действие как раз после первого звонка, совершённое не с её IP адреса. При этом IP адрес московский. Выполнено действие - отключение входа с подтверждением. Что это значит, не очень понятно, так как подтверждение по телефону реально не отключили.
Вот такая странная история произошла. Ниже список писем в тот день и скрины фейкового письма с госуслуг и от Aeza. Вот последняя меня больше всего интересует. При чём тут вообще этот хостинг? Знакомая с ним никак не связана и вообще не знает, что это такое.
И второй момент. От чего в итоге был передан мошенникам код из 4-х знаков? У меня есть подозрение, что Госуслуги тут только прикрытие каких-то других дел. Я не знаю, можно ли подделать отправителя смс, чтобы его сообщение попало в папку или чат с реальными смс от Госуслуг. А может на смену номера там только 4 символа и остался старый шаблон. Но смена по какой-то причине не состоялась.
Кто-нибудь сталкивался с подобным? Что это может быть? Какая-то многоходовая махинация. Тут и посылка, и фейковые письма, и поддержка.
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍134👎4
Продолжаю пересматривать старые заметки. Нашёл показательную новость от 2020 года, которую скорее всего все уже позабыли.
⇨ Удалённая уязвимость в серверных платах Intel с BMC Emulex Pilot 3
Это когда в BMC-контроллере, который используют для управления серверной платформой, нашли эпические уязвимости, которые позволяли без аутентификации получить доступ к консоли удалённого управления KVM. Причём по словам выявившего уязвимость исследователя работать с BMC через эксплоит гораздо удобнее, чем при помощи штатного Java-клиента. Ну случайно так вышло, понимать надо ☝️.
И такие уязвимости регулярно всплывают. Помню, как в ядро Linux какие-то "шутники" протолкнули уязвимости, их приняли, а потом заметили. Оказалось, их туда в исследовательских целях добавляли, тоже понимать надо.
К чему я это написать решил. Не помню, акцентировал ли когда-нибудь конкретно на этом внимание. Я стараюсь сам и рекомендую остальным закрывать доступ извне ко всему, что не требует публичного доступа, файрволом. Закрываю даже SSH, хотя не всегда так делал. Последние года стабильно закрываю службу SSH списками IP адресов. Возможно и ICMP стоит закрывать, чтобы не отсвечивать лишний раз, но я оставляю для удобства мониторинга.
Есть расхожее мнение на тему того, что если регулярно и своевременно ставить обновления, то можно особо не бояться уязвимостей. К сожалению, это не так. Уязвимости закрывают, когда они появляются в публичной плоскости. А сколько они эксплуатируются в теневом режиме - неизвестно. Я лично сталкивался с историей, когда сервер живёт своей жизнью - останавливает и запускает сервисы, а ты не можешь понять кто и как это делает. Из исследовательских целей оставлял сервер и долго с ним ковырялся, но не мог понять, что там происходит. Пришлось переустанавливать. Подозреваю, что через какую-то непубличную уязвимость ломали, да и всё.
На днях ещё одну новость видел: У криптовалютной биржи Bybit похитили 1,46 млрд долларов. Во времена хайпа крипты я плотно работал с компанией, которая писала криптовалютные биржи и приложения. Я реально опасался за безопасность, хотя старался делать всё, что от меня зависело, для безопасности, но всякое бывает. Потом больше всего вопросов к администратору будет, если случится инцидент. Больше не занимаюсь этим и не хочу. Технически работа была интересная, но с точки зрения безопасности постоянно чувствовал некоторую тревогу. Там сервисы публичные были, всё не закрыть.
#совет #security
⇨ Удалённая уязвимость в серверных платах Intel с BMC Emulex Pilot 3
Это когда в BMC-контроллере, который используют для управления серверной платформой, нашли эпические уязвимости, которые позволяли без аутентификации получить доступ к консоли удалённого управления KVM. Причём по словам выявившего уязвимость исследователя работать с BMC через эксплоит гораздо удобнее, чем при помощи штатного Java-клиента. Ну случайно так вышло, понимать надо ☝️.
И такие уязвимости регулярно всплывают. Помню, как в ядро Linux какие-то "шутники" протолкнули уязвимости, их приняли, а потом заметили. Оказалось, их туда в исследовательских целях добавляли, тоже понимать надо.
К чему я это написать решил. Не помню, акцентировал ли когда-нибудь конкретно на этом внимание. Я стараюсь сам и рекомендую остальным закрывать доступ извне ко всему, что не требует публичного доступа, файрволом. Закрываю даже SSH, хотя не всегда так делал. Последние года стабильно закрываю службу SSH списками IP адресов. Возможно и ICMP стоит закрывать, чтобы не отсвечивать лишний раз, но я оставляю для удобства мониторинга.
Есть расхожее мнение на тему того, что если регулярно и своевременно ставить обновления, то можно особо не бояться уязвимостей. К сожалению, это не так. Уязвимости закрывают, когда они появляются в публичной плоскости. А сколько они эксплуатируются в теневом режиме - неизвестно. Я лично сталкивался с историей, когда сервер живёт своей жизнью - останавливает и запускает сервисы, а ты не можешь понять кто и как это делает. Из исследовательских целей оставлял сервер и долго с ним ковырялся, но не мог понять, что там происходит. Пришлось переустанавливать. Подозреваю, что через какую-то непубличную уязвимость ломали, да и всё.
На днях ещё одну новость видел: У криптовалютной биржи Bybit похитили 1,46 млрд долларов. Во времена хайпа крипты я плотно работал с компанией, которая писала криптовалютные биржи и приложения. Я реально опасался за безопасность, хотя старался делать всё, что от меня зависело, для безопасности, но всякое бывает. Потом больше всего вопросов к администратору будет, если случится инцидент. Больше не занимаюсь этим и не хочу. Технически работа была интересная, но с точки зрения безопасности постоянно чувствовал некоторую тревогу. Там сервисы публичные были, всё не закрыть.
#совет #security
👍86👎2