Взлом matrix.org – пример очень показательного взлома с точки зрения базовой безопасности. Нарушено куча важнейших принципов, описанных ниже. Сам хакер очень подробно все описал.
https://archive.md/MfrjB в матриксе крутили на х.ю самые обычные бестпрактисы. Молодцы, че
I noticed in your blog post that you were talking about doing a postmortem and steps you need to take. As someone who is intimately familiar with your entire infrastructure, I thought I could help you out.
[SECURITY] 2FA is gud 2FA is often touted as one of the best steps you can take for securing your servers, and for good reason! If you'd deployed google's free authenticator module (sudo apt install libpam-google-authenticator), I would have never been able to ssh into any of those servers. Alternatively, for extra security, you could require yubikeys to access production infrastructure. Yubikeys are cool. Just make sure you don't leave it plugged in all the time, your hardware token doesn't do as much for you when it's always plugged in and ready for me to use. Alternate-Alternatively, if you had used a 2FA solution like Duo, you could have gotten a push notification the first time I tried to ssh to any of your hosts, and you would have caught me on day one. I'm sure you can setup push notifications for watching google-authenticator attempts as well, which could have at least given you a heads up that something fishy was going on. Anyways, that's all for now. I hope this series of issues has given you some good ideas for how to prevent this level of compromise in the future. Security doesn't work retroactively, but I believe in you and I think you'll come back from this even stronger than before. Or at least, I hope so -- My own information is in this user table... jk, I use EFNet.
Лишние привилегии (даешь рут для всех :/)
[SECURITY] Principle of Least Privilege Escalation could have been avoided if developers only had the access they absolutely required and did not have root access to all of the servers. I would like to take a moment to thank whichever developer forwarded their agent to Flywheel. Without you, none of this would have been possible.
Отсутствие аудита логов безопасности
[SECURITY] Monitor log files to avoid relying on external whitehats Let's face it, I'm not a very sophisticated attacker. There was no crazy malware or rootkits. It was ssh agent forwarding and authorized_keys2, through and through. Well okay, and that jenkins 0ld-day. This could have been detected by better monitoring of log files and alerting on anomalous behavior. Compromise began well over a month ago, consider deploying an elastic stack and collecting logs centrally for your production environment.
Отсутствие постоянных обновлений критичных для безопасности систем (CI Jenkins)
После первого взлома командой Matrix был опубликован отчёт, в котором указано, что взлом был совершён через уязвимость в необновлённой системе непрерывной интеграции Jenkins.
Прямой доступ из интернета НА ВСЕ СЕРВЕРА без каких то глупых VPN/reverse-proxy/bastion-host
на SSH сервера
на сервер CI Jenkins
[SECURITY] Controlled Production Access I was able to login to all servers via an internet address. There should be no good reason to have your management ports exposed to the entire internet. Consider restricting access to production to either a vpn or a bastion host.
[SECURITY] Jenkins Slave listening to SSH on the internet Once I was in the network, a copy of your wiki really helped me out and I found that someone was forwarding 22226 to Flywheel. With jenkins access, this allowed me to add my own key to the host and make myself at home. There appeared to be no legitimate reason for this port forward, especially since jenkins tunnel was being used to establish the communication between Themis and Flywheel.
Ну и чуть более сложные:
Хранение ключей для создания подписей СВОИХ МЕГА БЕЗОПАСНЫХ ПРИЛОЖЕНИЙ на рабочих серверах, а не на изолированном хосте
[SECURITY] Signing keys in production?!? There I was, just going about my business, looking for ways I could get higher levels of access and explore your network more, when I stumbled across GPG keys that were used for signing your debian packages. It gave me many nefarious ideas. I would recommend that you don't keep any signing keys on production hosts, and instead do all of your signing in a secure environment.
Включенный “проброс ключа ForwardAgent” в ssh – позволяет с одного сервера подключаться на другой без пароля, форвардом ключа от первого сервера второму
[SECURITY] SSH Agent Forwarding Complete compromise could have been avoided if developers were prohibited from using ForwardAgent yes or not using -A in their SSH commands. The flaws with agent forwarding are well documented.
Хранение в Git репозитории всех важных данных и полностью репа заливалась на хосты, хотя по факту в этом нужды не было
[SECURITY] Git is not a secret store The internal-config repository contained sensitive data, and the whole repository was often cloned onto hosts and left there for long periods of time, even if most of the configs were not used on that host. Hosts should only have the configs necessary for them to function, and nothing else.
Источники
Большая часть информации ниже взята из открытых источников, которые изучались по мере прохождения:
Очень хороший github repo h4cker.org в котором Omar Santos (автор курса SCOR) собрал разную информацию в контексте сетевой безопасности. Например там есть,
хорошая таблица по тому, какие алгоритмы хеширования и шифрование рекомендуется/не рекомендуется использовать. Какие являются будущим.
А теперь перейдем от практики к непосредственно теории.
Стандартизация
NIST Cybersecurity Framework (National Institute of Standards and Technology) – совокупность индустриальных стандартов и наилучших практик для защиты организаций в контексте кибербезопасности от гос. органа США (всего более 500 штук). Одной из основных целей стандартизации является управление рисками кибербезопасности критической инфраструктуры эффективно и не дорого. Framework может использоваться как основа для любой организации. В целом публикации NIST охватывают широкий круг вопросов безопасности (от контроля доступа до беспроводной безопасности) и являются очень ценным источником информации.
ISO/EIC 27000 (ISO27k)– набор стандартов (порядка 50) о информационной безопасности от ISO (International Organization for Standardization) и IEC (International Electrotechnical Commission). Первые же 6 документов рассматривают большой пул вопросов касающихся развертывания/поддержки/мониторинга/аудита систем управления ИБ (ISMS). Организации могут/проходят процедуру соответствия этим сертификациям.
What the Suricata development by the OISF has shown in my opinion is that we’ve managed to create a very promising new Open Source project out here. In little over a year, funded for about $600k by the US government and with heavy (and growing) industry support, we’ve produced a new IDS/IPS engine mostly compatible with Snort but build on a all new code base an incorporating some very interesting fresh ideas. We’re already seeing a community form around our project with a lot of support from that new community.
This work has been funded by the National Security Agency INFOSEC University Research Program under Contract Number DOD-MDA904-93-C-4084.
Терминология (словарь/dictionary)
CIA triad (confidentiality, integrity, availability) – ключевые аспекты безопасности. Каждый из аспектов можно раскрыть подробнее, например
конфиденциальность подразумевает что данные видимы только тем, кто авторизован их видеть. Требует совокупность мер для реализации – шифрование, ограничения физического и логического доступа и даже контроль маршрутизации трафика. Чаще всего технически задача конфиденциальности решается шифрованием. В общем случае задача конфиденциальности решается тремя общими концепциями:
определение того, какая информация нуждается в контроле
определение лиц, которые авторизованы и не авторизованы в получения доступа к этой информации
контроль доступа к информации только авторизованным пользователям
целостность подразумевает что данные защищены от порчи, подмены (имитозащита). Чаще всего технически задача целостности решается хешированием. Так же шифрованием, цифровыми подписями, контролем процессов, тестированиями кода, анализ логов, мониторинг (напр. контроль целостности файлов), тренинги персонала.
Воровство пароля админа в последующим изменением конфигурации сервисов/серверов/устройств – тоже атака на целостность.
Malware которое модифицирует/уничтожает системные файлы, необходимые для загрузки – пример неавторизованной манипуляции, атаки на целостность.
Подмена/удаление медицинских или банковских данных.
доступность подразумевает что сервис доступен (напр. сайт online retailing, ISP provider, cloud provider) для легитимных пользователей. Самой частой атакой против доступности является DoS (denial-of-service). Показателем доступности является uptime (сколько времени в процентах сервис доступен), например ISP/датацентры часто публикуют данные/подписывают договоры (SLA) с 99.999% доступностью (99.999% uptime). В среднем мы более уязвимы к проблемам доступности в сравнении с проблемами конфиденциальности и целостности. Методы митигации угроз доступности включают контроль доступа, мониторинг, отказоустойчивость, виртуализация, административные меры (процедуры, планирование).
Какой из этих аспектов CIA triad более важен? Во первых они связаны – например, потеря пароля может привести к проблемам по любому из аспектов. Во вторых компания должна решать сама на основе ее целей, сервисов, регламентов и соглашений.
Атаковать сложнее чем защищать – атакующему зачастую достаточно провести успешно только одну атаку из 100, чтобы взломать систему. При этом защищающийся может успешно отразить 99 атак и система все равно будет взломана.
Risk (риск, управление рисками) – возможность понести потери в случае атаки на систему (реализации угрозы). Безопасность вся основывается на рисках – определение рисков, определение вероятности атак, разработка/проектирование систем для минимизации рисков этих атак (простейший пример из жизни – переход дороги). В контексте безопасности есть аксиома, что невозможно полностью исключить риск (полностью безопасная система – отключенная от сети, питания, к ней нет доступа ни у кого). Лучшее, что можно сделать, это идентифицировать риск, принять меры по уменьшению и мониторить, приняв его как остаточный риск (residual risk). С риском ассоциируются понятия assets (активы), threats (угрозы) и vulnerabilities (уязвимости). Для “работы” с рисками правительство США разработало risk management framework (RMF) на базе публикации NIST 800-37.
Assets (активы) – любой предмет, который представляет какую либо ценность. Может быть реальным – роутеры, сервера, ноутбуки и проч; может быть и виртуальным – формулы, базы, таблицы, торговые секреты. Независимо от типа актива его потеря может привести к финансовым потерям компании.
Risk assessment (оценка рисков) – начинается с threat modeling (моделирования угроз). Подразумевается идентификация возможных источников угроз (векторов атак, таких, как уязвимости) для систем (критичных систем/критичных данных) с точки зрения потенциального атакующего, приоритизация этих угроз в зависимости от вероятности и серьезности (например, для уязвимости – можно ли использовать ее удаленно, вероятность ее использования, тип доступа, который получит атакующий в результате эксплойта).
Trade-off (компромис) – во многих темах безопасности встречаются темы компромиссов между безопасностью и удобством:
безопасный пароль ! = пароль который легко запомнить,
максимальная длина ключа != максимальная скорость работы,
цена/безопасность аппаратной реализации != цена/безопасность программной
безопасность 3FA != удобству 1FA
удаленный доступ со своего девайса (вместо rdp/VM) != безопасный доступ
и так далее
Vulnerability (уязвимость) – недостаток в системе (программной или аппаратной), который может быть использован для компроментации системы. Уязвимость не всегда имеет эксплойт (особенно публичный) и не всегда даже может быть эксплуатирована (подробнее ниже). Уязвимость может быть обнаружена в любой системе (application, OS, hardware) – не существует полностью неуязвимых систем. Вендоры/исследователи обычно после обнаружения уязвимости назначают ей номер CVE (Common Vulnerabilities and Exposure) и исправляют, но это не всегда так – вендор/пользователь может не исправлять уязвимость из-за простого отсутствия финансов. Так же уязвимость может не исправляться т.к. библиотека уже всеми забыта. Поддержкой CVE базы занимается организация MITRE. Пример конкретной уязимости CVE-2017-3881. Пример аппаратных уязвимостей – Spectre, Meltdown. Пример базы с уязвимостями ФСТЭК.
Не все уязвимости имеют Exploit, такие уязвимости часто называют “theoretical vulnerabilities”, но нужно всегда иметь ввиду, что если вы не нашли или не придумали эксплойт, это не значит его нельзя найти (напр. глубоко в darkweb) или придумать и скрытно использовать (напр. спецслужбами). Поэтому в природе не бывает полностью “theoretical vulnerabilities”.
0-day vulnerability, zero-day exploit – уязвимость нулевого дня – уязвимость, которая неизвестна производителю продукта, но известна хакеру. 0 дней подразумевает за сколько нужно ее починить (или сколько дней известно о уязвимости) 😀 По факту зачастую даже после патча чинится куда дольше – нужно время для его “разливки”.
Exploit – софт или набор шагов, который использует (эксплуатирует) уязвимость в системе.
Пример базы с exploit-ами – популярный http://exploit-db.com/ от Offensive Security или github. Есть так же очень удобный command-line tool “searchsploit“, который позволяет выгрузить копию exploit database и в консоли искать эксплойты. Exploit’ы чаще всего продают в dark web. Exploit’ы не всегда выкладываются для злого умысла или зарабатывания денег – они являются proof-of-concept (POC).
Threat – в общем случае это любая потенциальная угроза. Это может быть угроза использования уязвимости (возможная атака), угроза отказа в обслуживании, угроза воровства данных, отказа объекта КИИ (stuxnet), угроза пожара или другого катаклизма и проч. В общем случае угроза может приводить к любым проблемам CIA (Confidentiality, Integrity, Availability). Сущность, получающая профит от использования уязвимости известна как malicious actor (threat actor – подробнее отдельно), а путь используемый этим actor для осуществления атаки известен как threat agent/threat vector.
Threat actor, malicious actor – личность или группа личностей, осуществляющих атаку или ответственные за security инцидент. Типы:
script kiddies (используют написанные другими инструменты),
organized crime groups (в основном занимаются воровством информации и зарабатыванием денег),
state governments (серьезные ребята),
hacktivists (занимаются этим по идеологическим причинам),
terrorist groups (групп мотивированные политическими или религиозными целями).
Attack vector (вектор атаки) – метод или механизм, которые атакующий может использовать для атаки сети/системы. Примеры векторов атак – вложения в почте, сетевые протоколы/сервисы. В зависимости от используемого приложения могут быть наиболее “актуальные” те или иные веторы атак, к примеру есть очень известный список OWASP TOP-10 (линк на непосредственно сайт OWASP – Open Web Application Security Project), в который включены самые опасные атаки на WEB приложения (SQL injection, auth implementation problems, sensitive data exposure, XXE, XSS, url,deserialization, security misconfiguration, unsecure components, using components with known vulnerabilities, insufficient logging & monitoring, etc).
Для тренировки с уязвимостью XSS и другими WEB-уязвимостями, которые рассмотрены в проекте OWASP можно использовать тулзу OWASP Juice Shop, можно на практике посмотреть уязвимости OWASP top 10 и другие (подробнее в XSS).
Defense in depth (эшелонированная защита) – концепция наличия нескольких наложенных систем защиты. Может быть реализована даже в рамках одного продукта (например, Firewall). 1) Нельзя полагаться на одну систему (SPOF) 2) Каждый из элементов защиты может быть не идеален, но он является потенциальным барьером, который может помочь отразить атаку. Как в замке.
Отказоустойчивость в вопросе безопасности зачастую так же критична (а иногда и критичнее), чем работа непосредственно сервиса. Причем система может не упасть и ты не будешь знать что она не работает, а кто-то тем временем будет пользоваться уязвимостью в ней. К примеру,
Яркий пример – это куча эксплойтов у ведущих вендоров, позволяющих обойти аутентификацию. Почему ОБЯЗАТЕЛЬНО нужно закрывать доступ к устройствам на уровне протоколов (ACL), использовать серую адрессацию, а не только полагаться на аутентификацию в соотвествующих протоколах (SSH, SNMP, telnet, etc).
best practice настраивать и sshd_config и iptables для защиты подключения по ssh на сервер
как бы плохи антивирусы не были, они хорошо защищают от популярных известных атак (модель blacklist). Конечно, с точки зрения безопасности лучше иметь binary whitelisting software (bit9) – который будет запрещать все, кроме того что явно не разрешено (концепция implicit deny ниже), но это очень неудобно, особенно если он не полагается на signing PKI (концепция trade-off выше ;)), но недостаток есть и у них – если доверять всему подписанному, не смотря внутрь, то, в тот момент, когда подделают подпись – тебе хана (примеры подобных атак были).
как бы не были плохо функции защиты port security и MAC authentication, если они не накладывают серьезных недостатков в поддержании актуальными баз адресов – они могут быть полезны
То же самое и про firewall – помимо классических сетевых устройств, должны быть и host-based firewall, у которых будут примерно такие же правила, как у классического устройства или даже больше (защита внутри сети от зараженных устройств внутри сети за файрволом) или защита mobile юзера.
Implicit deny/whitelisting/default deny – концепция о том, что нужно отключать/удалять ненужные сервисы (или ограничивать к ним доступ) и не давать лишние доступы (всем права админа – это не соответствует best practice концепции “least privilege”). Встречается везде и нужно использовать везде – даже на клиентских устройствах (host-based firewall). Отсюда например вытекает implicit deny в ACL (на роутерах Cisco или в iptables на INBOUND) – концепция из сетевого мира, которая подразумевает, что все, что явно не разрешено, должно быть запрещено – это относится как к входящему трафику, так и к исходящему. Это намного более безопасная концепция, чем black listing, хотя и менее удобная.
Fail-closed – близкая к Implicit deny концепция, только описывает что делать с трафиком после сбоя (default action в таком случае)
Internal Attack Team – есть во многих организациях, включая Google. Хакеры в белых шляпах.
OSINT (Open sourceintelligence) — Разведка на основе анализа открытых источников информации, разведывательная дисциплина, включающая в себя поиск, выбор и сбор разведывательной информации из общедоступных источников, а также её анализ. Примером можно считать avinfobot telegram бот, который из открытых источников агрегирует информацию по номерам авто/телефонам или ФИО.
Survival Time системы без защиты, патчей (что не менее важно) и с неактуальной версией системы (Windows XP, god forbid), смотрящие “голо” в интернет – час. Потом ее хакнут. Поэтому безопасность – это важно.
Security Misconfiguration – неправильная конфигурация продукта с точки зрения безопасности (напр. использование устаревших типов шифрования, устаревших методов аутентификации). Частая проблема, особенно в свете того, что дефолтные конфиги зачастую уже имеют заложенные недостатки с точки зрения безопасности.
Security Education – обучение по безопасности, обязательно в компаниях, которые заботятся о своей безопасности. Обучать нужно всех сотрудников, не только сотрудников SoC/IRP. Должно включать самые распространенные способы атаки (почтовые вложения, зеркала, пароли) и способы защиты от них.
Third party security – безопасность сторонней организации с которой взаимодействует твоя организация. Нужно проверять сторонние организации на соответствие политикам безопасности (внутренним внутри организации и зачастую даже твоим политикам) через VSAQ (Vendor security assessment questionnaries, быстрый и эффективный способ) или даже тестировать (audit, vulnerability test, pentest) их решения на безопасность. Пример VSAQ от Google.
Zero Trust не доверяем никому и ничему по умолчанию (пользователям, приложениям, трафику, данным или узлам) до тех пока не проведем их проверку.
Концепция Zero Trust появилась, когда современные подходы, основанные, в первую очередь, на защите периметра, стали давать сбой. Когда к внутренним ресурсам стали подключаться различные клиенты, партнеры, контрагенты, когда компании начали активно уходить в облака и использовать мобильные устройства, прежняя концепция – защита периметра – перестала справляться. Возникла новая необходимость защитить и данные, и пользователей, и устройства, которые постоянно меняют свое местоположение. Именно тогда была предложена концепция Zero Trust. Она как раз и означает, что мы изначально не доверяем никому: пользователям, приложениям, трафику, данным, узлам. Не доверяем до того момента, пока не проведем проверку. Эта проверка производится либо постоянно, либо через небольшие интервалы времени, чтобы убедиться, что злоумышленники не смогли подменить пользователя, устройство, трафик, данные, узел и т.д.
Bastion host – хост, на входе в какую то (какие-то) IT системы. Позволяет получить доступ к каким то системам с себя/через себя, но на него наложены политики безопасности (аутентификации/авторизации, логгирования, мониторинга).
Advanced Persistent Threat (APT) – атака с внедрением в сеть и незаметным там нахождением существенное время. Advanced – потому что зачастую это таргетированная атака, при которой нет почти ограничения по времени/ресурсам. Чаще всего угроза постоянна – поэтому persistent. Примеры таких атак – Stuxnet, атака на RSA SecurID в 2011 (потенциально на Lockheed Martin).
Data leak prevention (DLP) – системы предотвращения данных. Могут анализировать любую активность, включая даже данные, копируемые по RDP.
Персональные данные (personally identifiable information, PII) – данные которые позволяют идентифицировать персону. Защищаются законами в большинстве стран и требуют ‘особую’ защиту (напр. ГОСТ шифрование). Потеря таких данных может стать причиной судебного преследования компании, помимо потери доверия клиентов. Примеры персональных данных/информации:
PII – personally identifiable information,
NPPI – nonpublic personal information,
PCI – payment card information,
PHI – personal health information.
Разведка угроз (Threat Intelligence)
Разведка угроз (Threat Intelligence) – это знания о существующих и появляющихся угрозах к активу (asset). Основное применение – информирование бизнеса относительно рисков и последствий угроз для актива. Threat Intelligence включает информацию о активе, внутренних и внешних угрозах, контекст (context), механизмы (mechanisms), индикаторы компрометации (Indicators of Compromise, IoCs), последствия (implications), действия (actionable advice). Вся эта информация является критической для Security Operations Centers (SOC).
В целом использование опыта других – это полезно (немного капитаним).
Процесс threat intelligence можно разбить на этапы: планирование (planning), сбор (collection), обработка (processing), подготовка/аналитика/внедрение (analysis and production) и распространение (dissemination).
Существует ряд стандартов разработанных в контексте Threat Intelligence. Первые три основаны MITRE, поддерживаются сейчас OASIS.
STIX – Structured Threat Information eXpression – язык для обмена информацией о атаках, может включать IP адреса/домены контрольных серверов (Command-and-control, C2, CNC), хеши malware и прочее.
TAXII – Trusted Automated eXchange of Indicator Information – отрытый транспортный механизм, который стандартизировал автоматический обмен информацией о гибер-угрозах. Использует формат STIX для передачи cyber threat intelligence (CTI).
Кибербезопасность включает в себя традиционные вопросы информационной безопасности, но и добавляет дополнительные требования – контроль всех соединений, контроль данных на этапе хранения/передачи и обработки, управление софтом и аппаратным обеспечением, управление инцидентами.
ОЦЕНКА уровня угроз (CVSS)
Common Vulnerability Scoring System (CVSS) – оценка уровня угрозы (совокупность рисков) конкретной уязвимости. Можно встретить двух версий – CVSSv2, CVSSv3 (чаще). CVSS является стандартом, используемым security специалистами во всем мире и поддерживается организацией FIRST (Forum of Incident Response and Security Teams). Примеры расчета оценок CVSS на основе анализа реальных уязвимостей есть у самого FIRST.
CVSS оценка имеет градацию на низкий/средний/высокий/критический уровень. Во ФСТЭК градация почти аналогичная CVSSv3. Примером критичной уязвимости можно считать уязвимость, которая позволяет атакующему удаленно компроментировать систему и получить полный контроль над ней.
CVSS Textual severity ratings of None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0)[10] were defined, similar to the categories NVD defined for CVSS v2 that were not part of that standard .[11]
ФСТЭК - низкий уровень, если 0,0 ≤ V ≤ 3,9; - средний уровень, если 4,0 ≤ V ≤ 6,9; - высокий уровень, если 7,0 ≤ V ≤ 9,9; - критический уровень, если V = 10,0.
Нужно понимать, что CVSS относится к конкретной уязвимости, но зачастую, особенно в случае APT-атак, уязвимости эксплотируются в цепочке и несколько минорных уязвимостей могут в итоге стать серьезной проблемой, когда их эксплуатируют одновременно. Анализ последствий таких атак крайне сложен.
CVSS оценка состоит из трех компонентов, каждый из которых имеет свою оценку от 0 до 10 и описывает различные характеристики уязвимости и то, как атакующий может эти характеристики использовать:
Базового (base)
Временного (temporal)
Среды (environmental)
Подробнее о каждом:
Базовый (base) – самый важный компонент и единственный обязательный (mandatory) компонент, представляет собой характеристики, присущие уязвимости, которые неизменны со временем и не зависят от пользовательской среды. Сам компонент состоит из трех метрик:
Эксплуатируемость (exploitability) – условия, при которых возможна эксплуатация уязвимости.
Вектор атаки (Attack Vector, AV) – уровень доступа к уязвимой системе, при которых возможна эксплуатация уязвимости. Бывает четырех типов:
Сетевой (Network, N)
Смежный (Adjacent, A)
Локальны (Local, L)
Физический (Physical, P)
Сложность атаки (Attack Complexity, AC) – описывает условия, которые не контролируются атакующим, которые должны существовать для эксплуатации уязвимости.
Низкая сложность (Low, L)
Высокая сложность (High, H)
Требуемые привелегии (Privileges Required, PR) – представляет из себя уровень привилегий, которыми атакующий должен обладать на уязвимой системе.
Не требуются (None, N)
Низкие (Low, L)
Высокие (High, H)
Взаимодействие с пользователем (User Interaction, UI) – требуется ли взаимодействие с пользователем для осуществления атаки.
Не требуется (None, N)
Требуется (Requred, R)
Влияние на CIA (impact) – влияние на ключевые аспекты безопасности (CIA)
Влияние на Конфиденциальность (Confidentiality, C)
Низкое (Low, L)
Среднее (Medium, M)
Высокое (High, H)
Влияние на Целостность (Integrity, I)
Низкое (Low, L)
Среднее (Medium, M)
Высокое (High, H)
Влияние на Доступность (Availability, A)
Низкое (Low, L)
Среднее (Medium, M)
Высокое (High, H)
Зависимые системы (scope change, S) – влияние на другие системы, которые не имеют уязвимости, но зависимы от уязвимой (напр. из-за “падения” роутера с уязвимостью страдают все подключенные к нему устройства, если не имеют backup)
Нет влияния (Unchanged, U)
Есть влияние (Changed, C)
Временный (temporal) – изменяемые характеристики уязвимости, зафиксированные на момент оценки
Наличие эксплойтов (Exploit Code Maturity, E)
Наличие средств защиты от уязвимости (Remediation Level, RL)
Полнота знаний об уязвимости (Report Confidence, RC)
Среды (environmental) – характеристики уязвимости с учетом среды организации
Требования к безопасности (Security Requirements CR, IR, AR) для уязвимой и зависимых систем
Модифицируемые метрики (Modified Base Metrics, MAV, MAC, MAPR, MUI, MS, MC, MI, MA) на основе конкретной среды организации
Пример определения значений показателей базового компонента без расчета CVSS на базе атаки, в которой атакующий может вызвать сбой (crash) удаленного хоста особым пакетом сетевого трафика.
Attack vector (AV) – Network т.к. атакующий потенциально может находится где угодно и отправить созданный пакет (вообще, зачастую спорно, если 1) хост в изолированном сегменте 2) пакет нужно послать L2)
Attack complexity (AC) – Low т.к. создать пакет не сложно (напр. используя Scapy)
Privilege Required (PR) – None т.к. не требуется привилегий на уязвимой системе
User Interaction (UI) – None т.к. не требуется взаимодействия между атакующим и пользователем уязвимой системы
Scope (S) – Unchanged т.к. от хоста не зависят другие системы
Confidentiality Impact (C) – None т.к. атака нацелена на Availability
Integrity Impact (I) – None т.к. атака нацелена на Availability
Availability Impact (A) – High т.к. устройство полностью недоступно после эксплуатации уязвимости
Виды хакеров (hacker, Cracker, white-list)
Изначально термин hacker означал – компьютерный энтузиаст. Далее журналисты начали так же называть личностей, которые занимаются взломом с злыми намерениями. Индустрия предложила в таком случае использовать термин cracker (black hat hackers), а тех, которые “добрые” white hat hacker (ethical hacker). “Добрые” хакеры считают, что вы должны подходить к безопасности инфраструктуры используя хакерские утилиты и идеи. Различают так же и серых хакеров (grey hat hackers), которые в основном выступают в роли “белых” хакеров, но иногда становятся и “черными”. Таких сотрудников лучше не нанимать.
Виды атак
Malware (вредоносный софт)
virustotal.com – крутой сайт для проверки всем чем можно (в текущий момент 58 антивирусов) файлов
www.talosintelligence.com/reputation – Cisco Talos File Reputation Lookup, можно по sha256 сделать поиск является конкретный файл опасным или нет (ниже скрин для wannacry), посмотреть репутацию ip/domain и прочее
www.hybrid-analysis.com – проверка файлов в sandbox и решение о вредоностности на основе поведения файла в системе (Windows, Linux, Android). Много аналитики поведения (напр. обращения к сетевым хостам).
Существует огромное количество разновидностей malware и ущерба, которые они делают (от рекламных сообщений до уничтожения физических устройств). Писатели malware стараются обойти методы их обнаружения применяя методы обфускации. Примеры зловредов можно найти уже в 80е годы.
Viruses and worms – вирус отличается от червя тем, что требует пользовательского действия для инфицирования и распространения. Червь же может распространятся без пользовательских действий.
Adware
Spyware – в общем случае софт, перехватывающий без разрешения пользовательские данные (вводы, куки, поведение, etc) и передающий для последующего анализа (хакерам, маркетологам, статистам, etc).
keylogger – бывают как программные (перехватывают на программном уровне сигналы клавиатуры/мыши или тапы телефона), так и аппаратные – например в виде накладок на банковские терминалы, врезка в USB кабель от устройства ввода информации и проч. Так же могут быть проводным/беспроводными. Кейлогеры могут устанавливаться как легитимное ПО для слежки за сотрудниками, в таком случае рекомендуется CERT SEI использовать формулировку с предупреждением этих сотрудников о слежке – иначе можно получить иск. Пример аппаратного решения для перехвата – KeyHost (записывает данные с клавиатуры, которые можно потом прочитать на другом ПК). Много програмных решений можно найти в интернете (как платно, так и бесплатно).
Ransomware – шифрует данные в системе и требует перевода денег за ключи дешифрования. Чаще всего после перевода денег ключи не предоставляются. Крайне популярны сейчас (wannacry, pyeta, notpetya, bad rabbit). Могут шифровать особые файлы в системе (файлы баз данных, excel, word), а могут все (включая, например, master boot record).
Trojan (троян) – легитимное приложение осуществляет зловредную деятельность помимо/вместо основной функции.
Трояны могут быть похожими на легитимные PDF, email, Word/Excel/PowerPoint документы, но по факту содержать malware код, который сделает все что угодно с вашей системой.
В отличии от вирусов и червей трояны обычно не имеют механизмов распространения, они полагаются только на незнание пользователя.
Существуют разные виды троянов:
RATs (Remote Access Trojans) – предоставляют полный контроль над жертвой, пример такого трояна Poison Ivy
Data hiding (ransomware) – прячем пользовательские данные и требуем с него $. По сути это ransomware распространенный методом “trojan”.
E-banking – перехватывает финансовые данные пользователя (напр. Zeus)
DoS – предназначены для DoS активности (подробнее о dos/ddos)
Proxy – позволяет действовать от имени компьютера жертвы, а не от своего, что позволяет сложнее идентифицировать атакующего или подставить кого-то
Security software disablers – отключают антивирусы/файрволы для упрощения последующей malware активности
Poison apple, USB key drop и даже USB cable drop – оставляем где-то зараженную USB флешку (или даже USB кабель со встроенным чипом, напр. USBNinja) и ждем пока ее кто-то подберет и заразится. Обычно оставляется в офисе (напр. столовой) конкретной компании.
Цели троянов бывают разные – от уничтожения компьютерных систем до обнаружения специальной информации. Обычно трояны пишутся для воровства банковских данных и цифровых кошельков, паролей, apt и простой файловой шары.
Rootkit
Backdoor – софт/доступы – что может использоваться взломщиками, для возможности доступа на машину после успешного взлома. Причем некоторые backdoor написаны так, что соединение устанавливается с зараженной машины на командный центр, а не наборот. Такая концепция опасна тем, что трафик из защищенного периметра в общем случае анализируется менее тщательно, чем в этот периметр. Кроме того это позволяет обойти NAT.
Существуют разные способы передачи вирусов (первые три самые популярные):
Master boot record infection – самый первый способ
File infection – полагается на то, что пользователь запустит исполняемый файл (.com, .exe). После запуска загружаются в RAM (немного капитанства). А для того, чтобы они загружались после перезагрузки системы malware могут прописать свой запуск как запуск драйвера, windows service или просто в стартап.
Macro infections (Excel, Word, PowerPoint, etc) – использование malware кода в макросах Microsoft Office.
BIOS infection – крайне опасен тем, что может вызвать полный отказ – еще даже до прохождения POST девайс зависнет
Propogating over the network (many types)
Multipartite – использование сразу нескольких способов передачи – например Boot sector + program files. Примером вируса является NATAS.
Соединения поверх сети интернет являются наиболее чаще используемым каналом передачи данных для распространения malware – это могут быть email attachments (самый часто используемый тип, обычно идущий вместе с социальной инженерией), peer-to-peer сети, instant messaging (IM), internet relay chat (IRC), browser/browser extension vulnerabilities, SMS, infected mobile apps (или видимая копия популярного mobile app с трояном по меньшей цене чем оригинал), watering hole (заражение сайта который посещает выбранная жертва), freeware (ничто не бесплатно в этом мире) и проч и проч. Но никуда не делся и классический способ – физический доступ (слив данных флешкой, установка жучков/кейлогеров и проч).
Сам код вируса может располагаться как в начале инфицированного файла (prepender), так и в конце (appender).
Анализ malware
Вообще анализ malware это “целая наука” и это зачастую крайне сложный процесс.
В своем базовом сценарии malware анализ бывает двух типов:
static анализ – используются методы реверс-инженеринга с инструментами в виде декомпиляторов/дизасемблеров (примеры софта – IDA Pro Hex-Rays, Binary Ninja, Evan’s Debugger edb, The Ghidra – сюда контрибьютил NSA, OllyDbg), OllyDbg, BinText (находит текст в исполняемых файлах). Этот софт позволяет (не всегда – подробнее в evasions) “восстановить” source code исполняемого файла. В целом довольно полный список разных утилит есть в github repo h4cker.org.
dynamic анализ – создается специальная среда (testbed, например в VM/docker) обычно в безопасном окружении sandbox (созданной вручную или автоматически; подробнее ниже, поиск по sandbox) в которую помещается malware и анализируется его поведение в этой среде и сети с попыткой 1) не привлечь внимание атакующих к тому, что исполняемая среда является фейковой 2) ни в коем случае не допустить распространение malware дальше изолированной среды (подробнее в sandbox, поиск по “malware contained”). Подготовка правильного testbed требует зачатую не мало времени.
В malware так же существует понятие search routine – malware делает поиск новых файлов/пространства ОП для заражения. Далее посредством infection routine происходит заражение уязвимых хостов. Payload routine подразумевает непосредственные действия, для которых был написан софт – шифрование диска, отображение текста, отправка зловреда всем твоим друзьям и проч. Trigger routine – счетчик, когда стартует payload routine.
Так же существует понятия profiling – сбор информации о системе и изменения поведения malware для минимизации обнаружения. Это может включать anti-forensics/antidetection routine техники (обфускация, защита от реверс-инженеринга), включенные в malware.
Сетевая безопасность (network seucirity; наличие firewall, ids/ips, шифрование важных данных, мониторинг/алертинг, использование Wi-Fi, использование VPN, аутсорсинг управления сетью, какое оборудование используется, наличие бекапов конфигов, наличие политик по управлению инфраструктурой – обновление конфигов/софта/проч) крайне важна – сетевые устройства это первая линия обороны в IT инфраструктуре против внешних атакующих.
Скорость распространения
Вирусы отличаются скоростью распространения:
fast infection – вирус инфицирует любой файл “до которого может дотянуться”
sparse infection – вирус не инфицирует все подряд во избежание раннего обнаружения
СОБЫТИЯ и ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ (security incidents & ALARMS)
Security incident – выявленная или неминуемая проблема в безопасности (NIST 800-61), например – слив, модификация или уничтожение персональных данных (PII, NPPI, PCI, PHI), неавторизованный доступ к интеллектуальной собственности, нарушение сервисов (DoS). По сути любой негатив для CIA triad.
A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
От disaster отличается тем, что касается подрыва ключевых аспектов CIA, а не широкого бедствия
От security event отличается тем, что явно несет какой-то ущерб для компании.
Само понятие инцидента должно быть определено в компании – что является индидентом, а что нет. Сам же факт произошедшего инцидента должен триггерить процедуру ответных действий на него. Причем не все инциденты одинаковы по приоритету – дыра, которая привела к сливу персональных данных (PII, NPPI, PCI, PHI), обычно требует более строгое и быстрое расследование т.к. потенциально придется отчитываться перед контролирующими органами по нему. Приоритет инциденту обычно выставляется инцидент-менеджером или сотрудником ИБ, занимающимся расследованием. Приоритет обычно определяет сроки устранения и список эскалации о инциденте.
Incident handling, incident response – управление инцидентами – подразумевает, по сути, предсказуемый ответ на разные ситуации (инциденты). Incident response program обычно состоит из ряда документов, которые согласовываются на уровне руководства компании –
политики – систематизируют документы,
планы – описывают подходы,
процедуры – подробно описывают конкретные шаги,
людей – так же Incident response program включает ведущих инцидент людей (incident response team, SoC), ответственных за определеные зоны, процессы взаимодействия между людьми.
Все это в совокупности позволят быть готовыми к разным ситуациям и, как итог, минимизировать финансовые потери в следствии инцидентов. При этом важно помнить, не обязательно все эти политики и процедуры должны появится в один день и быть сразу идеальными.
Ключевой персонал управления инцидентами – координаторы, дежурные, члены IRT, внешние советники.
IRC – (Incident Response Coordinator) (дежурный), член команды IRC. Является ключевой точкой для всех инцидентов. Получает информацию об инциденте, проверяет и логгриует его, нотифицирует при необходимости соответствующий персонал, включая менеджера, ответственного за инцидент (Designated Incident Handler)
DIH – (Designated Incident Handler) – менеджер, ответственный за инцидент, имеющий навыки кризис-менеджмента и навыки коммуникаций, опыт, знания и стойкость для управления инцидентом. Взаимодействует с топ-менеджментом и IRT. DIH подключает членрв команды IRT для решения инцидента.
IRT – команда Incident Response Team, подробнее в CSIRT.
Для помощи организациям в понимании как нужно обрабатывать security инциденты несколько письменных рекомендаций было создано, например, NIST Special Publication 800-61 – в документе подробно рассказано о работе с инцидентами – определение инцидента и связанных терминов, приоритизация, уведомления, документы и процедуры (policies, plans, procedures), координирование инцидентов, взаимодействие с третьими сторонами, ответственность и ее зона у ролей сотрудников/менеджмента, цели и объекты процедур, зона охвата процедур и проч, проч.
Incident handling, incident response в соответствии с NIST 800-601 включает 4 основные фазы:
подготовку – на основе оценки рисков проводится
обучение incident response team/SoC и обычных сотрудников, зачастую в виде игр и даже учений (tabletop exercises, playbooks) на уровне технического персонала (technical simulations) или менеджеров (risk-based exercises), которые включают подготовку/проведение и отчетность
создание/развитие/закупка программных и аппаратных инструментов и ресурсов для их работы (анализ инцидентов, устранение инцидентов и проч) – примерами могут быть knowledge base, topology maps, inventory tables, log collection/correlation
оценка защищенности и целостности (конфигураций, времени и проч) всех элементов и устранение выявленных проблем.
обнаружение проблемы, анализ/обнаружение влияния и последствий (в том числе root cause), приоритизация – зачастую это самая сложная фаза, ряд инцидентов обнаружить легко (напр. DoS), но многие инциденты остаются необнаруженными из-за “blind spots” в сети (network visibility), существующим в вашей инфраструктуре, недели и месяцы! Эти blind spots надо устранять, используя разные инструменты (сканеры, аналитика). Источниками информации при инцидентах могут быть те, которые описаны выше, простой googl’инг, снифинг пакетов, ids/ips, netflow/ipfix (подробнее о network visibility и netflow в отдельной статье).
сдерживание разрастания проблемы (containment strategy, напр. через ограничение сетевого доступа или даже отключения уязвимых хостов), устранение и восстановление последствий. Так же в эту фазу включается сбор доказательств, определение ущерба (повреждения/воровства/недоступности сервисов и проч), необходимые ресурсы (временные/материальные) для сдерживания/устранения/восстановления, тип выбранного решения по покрытию инцидента (полное, частичное покрытие), тип выбранного решения по времени (аварийное, временное, постоянное).
активность после инцидента “lessons learned/post-mortem” – изменение процедур/инфраструктуры для минимизации повторного возникновения. Кроме того в эту фазу включается сохранение доказательств. Все это применимо и к инцидентам, касающимся безопасности.
Управление security инцидентами (так же как и compliance) должно раcпространяться на третьи стороны – эти организации нужно на контрактной основе обязывать уведомлять о фактах произошедших у них индидентов. Кроме того, о инцидентах в вашей компании зачастую придется так же взаимодействовать с третьими сторонами – правоохранительными органами, партнерами, медиа, провайдерам, интеграторами, программными и аппаратными вендорами, а так же в поисках внешней экспертизы (координационные центры, другие команды SoC/incident response). Так же могут быть центры обмена подобной информацией в целом или для конкретной индустрии – например, FS-ISAC (Financial Services Information Sharing and Analysis Center). Взаимодействие со всеми этими внешними организациями, так же как и со внутренними, должно быть описано в incident response plan. Обмен информацией о событиях ИБ с неавторизованными участниками (и зачастую даже с неавторизованными представителями! авторизованных участников) должен быть запрещен во избежание слива информации.
Incident reporting:
Должен быть простым, так, чтобы любой сотрудник мог это сделать
Приоритет инциденту, выставляемый инициатором не может являться конечным т.к. зачастую тот, кто обнаружил инцидент не имеет всех знаний и компетенций для понимания его приоритета
Зачастую люди не сообщают о инцидентах – их боязни ошибиться, лени, нежелании быть “в каждой бочке затычкой” или просто хотят “лишний раз не высовываться”. Компания же, при всем при этом, должна приветствовать и даже поощрять заведение инцидентов и негативно не реагировать на false positive заведенные инциденты.
Нужно держать как можно меньшее количество активных инцидентов, закрывать уязвимости еще до того, как они будут эксплуатированы. После же инцидентов нужно обязательно искать “root-cause” (если не нашли во время устранения) оценивать эффективность его обработки и составлять “lessons learned/post-mortem” – выученные уроки с инцидента.
Разумно предовращать эти индиденты (incident preparedness), осуществляя:
периодическую оценку рисков (про риски отдельно выше)
Forensic analysis – криминалистический анализ логов/данных с хостов, серверов или сетевых устройств (digital forensic evidence). Чаще всего криминалистический анализ делается на битовой копии данных утилитами, во избежание изменения оригинальных данных (софт начал выпиливаться после того, как увидел, подозрительную для себя активность – напр. недоступность интернета). Оригинальная зараженная система при этом должна быть переведена в режим read only – например, используя джамперы на HDD (сейчас уже редко встретишь, да и данные зачастую в облаке) или, например, аппаратными или программными write blocker. Так же крайне желательно хранить носитель с доказательствами в антистатической сумке или forensic room (и такое бывает, хотя у нас это скорее защищенная “переговорка”) в которой реализована клетка Фарадея (Faraday cage), клетки из проводящих материалов, препятствующtq радио волнам попадать внутрь клетки и выбраться из клетки (mobile, wi-fi, наводкаи, etc).
В контексте криминалистической экспертизы так же крайне важно сохранение каждого чиха (chain of custody), который делался по расследованию инцидента и работе с доказательствами вплоть до судебного процесса – как вы узнали об инциденте, когда/как/кем собраны доказательства, как хранили/перевозили (lockable container?)/кто имел доступ к доказательству (желательно, чтобы ответственный всегда был с доказательством).
Существуют различные типы incident response команд и других security команд. Все они призваны минимизировать риски, возникающие от инцидентов ИБ. Стоимость потенциальных угроз зачастую значительно выше содержания в штате специалистов ИБ, которые позволят этим угрозам или не стать инцидентами или устранить эти инциденты с минимальными потерями для бизнеса. Так же есть опция аутсорса подобных услуг (MSSP, подробнее ниже).
InfoSec/SoC – команда ИБ.
CSIRT (Computer Security Incident Response Team) – наиболее популярный тип IRT (Incident Response Team). Плотно работает с InfoSec (командой ИБ) и другими IRT, в небольших организациях CSIRT и InfoSec объединены. В крупных CSIRT отвечает за инциденты ИБ, а InfoSec за эксплуатацию и деплой. В очень крупных бывает несколько CSIRT команд, каждая со своей специализацией. Хорошее описание работы/целей/ответственности CSIRT сделали в CERT.ORG. Подключать члена CSIRT к инциденту или нет решает менеджер по инциденту (DIH). Обычно в CSIRT находятся члены с разными “скилами” – менеджмент, ИБ, физическая безопасность, ИТ, право, комплаенс, HR, взаимодействие с клиентами и прессой. Какие то члены участвуют во всех инцидентах, другие – когда необходимы. Поэтому и задачи крайне разнообразные – управление инцидентом, анализ ситуации, разработка и реализация методик сдерживания/исправления инцидента, взаимодействие с клиентами и органами власти, анализ root cause и lessons learned.
PSIRT (Product Security Incident Response Team) – рассматривают инциденты по ИБ, относящиеся к продукту-ам компании вендора (напр. Omar Santos из Cisco инженер из команды PSIRT). PSIRT узнают о уязвимостях в продукте из разных источников – во время внутреннего тестирования, во время разработки или уже из внешних источников (во время тендеров, при деплое, эксплуатации). Практически невозможно на этапе дизайна и разработке устранить все уязвимости, поэтому в компании, разрабатывающей security продукты должен быть внедрен SDL (подробнее в SDL). Так же при работе команда PSIRT анализирует какой TPS (third party software) используется, смотрит на наличие уязвимостей в этом софте (подробнее в SDL -> TPS).
MSSP (Managed Security Service Provider) – компания, предоставляющая услуги по обслуживанию сервисов ИБ (включая зачастую IRT) для компании-заказчика. На этом рынке работает и Cisco. Аутсорсинг Security услуг с каждым годом все более популярен.
Национальные CERT, помимо обеспечения безопасности/расследования инцидентов в ключевых для страны сегментах (финансовом, медицинском, индустриальном, IT и т.д) и информации о разных уязвимостях, обычно предоставляют какое-то обучение, best-practices.
Coordination center – буквально несколько организацией в мире, которые помогают координировать уязвимости вендорам, провайдерам и исследователям, проводят исследования ИБ, проводят курсы/семинары/вебинары/подкасты, разрабатывают инструменты, анализируют ваши регламенты и практики на соответствие best practice. В общем оказывают большое количество consulting услуг. Один из лучших примеров – cert.org (CERT Division of the Software Engineering Institute). Они взаимодействуют с правительственными организациями U.S. Department of Defense, Department of Homeland Security, FBI, CIA и ключевыми организациями.
Типы alert/alarm/incidents в security устройствах IDS/IPS:
False positive (ложное срабатывание) – по сути false alarm. Срабатывание системы безопасности на легитимный трафик. Могут быть совсем не безобидным явлением, когда таких эвентов будет много – они будут требовать время на отработку и отвлекать от настоящих security events/incidents.
False negative (ложное несрабатывание) – несрабатывание системы безопасности на malicious трафик.
True positive (правильное срабатывание) – успешное обнаружение security events и срабатывание механихмов защиты на него.
True negative (правильное несрабатывание) – успешное обнаружение легитимной активности и несрабатывание механизмов защиты.
MALWARE EVASIONS
Malware всегда пытаются скрыть свои действия и минимизировать вероятность обнаружения пользователем или продуктами безопасности их активности. Malware развиваются в соответствии с развитием продуктов безопасности. Вирус может мутировать при распространении – это называется полиморфизм. Полиморфный вирус может изменять себя каждый раз при реплицировании и заражении нового файла – в итоге он может не обнаружится антивирусным ПО в каждом конкретном файле.
Методы, которые усложняют static анализ вирусов с использованием декомпиляторов/дизасемблеров – шифрование, обуфскация, кодирование, Anti-VM, Anti-debugger.
Кроме того вирусы сегодня не распространяются так широко как ранее – они пишутся под конкретную цель, что в итоге делает сложным обнаружения семпла вируса и написания сигнатуры на него. Что своего рода тоже “evasion technique”.
Распространятся malware софт может в wrappers – пакетах программ, включающих два или более исполняемых файла. Так же софт может распространятся в packers в архивах подобных WinZip, Rar, Tar. Еще одним типом является droppers – по сути тоже самое что wrappers. Crypters шифруют код malware используя алгоритмы шифрования или преобразования данных. Делаются все эти манипуляции (wrappers, packers, droppers, crypters) для обфускации обнаружения/активности malware антивирусным/ips ПО при установке malware в систему жертвы.
Malware может использовать многоуровневые подходы к обвускации и шифрования своего кода и единичное или совокупное использование всех этих манипуляций (wrappers, packers, droppers, crypters) приводит к тому, что обнаружение malware cтановится все более сложной задачей.
Примеры сокрытия в ОС:
для запуска после перезагрузки – ключи регистра, startup folder, файлы Win.ini. и System.ini
для блокировки апдейтов от вендоров ИБ или редиректа трафика клиента куда угодно (напр. подмена рекламы) добавляем необходимые адреса в файле hosts (на неработающие в случае вендоров ИБ, на необходимые в случае редиректа)
Pixilized image obfuscation
По идее depix (depixilizer) можно восстановить – нужный функционал есть в gimp/photoshop или github Depix и других инструментах (напр. бесплатный online сайт lunapic), но на практике Depix не работал даже с правильным “словарем” (несмотря на матчи генерировался бред). Причем над одной строкой pixilized данных скрипт работал 3-5 часов, загружая в полку CPU.
Depix is a tool for recovering passwords from pixelized screenshots. This implementation works on pixelized images that were created with a linear box filter. In this article I cover background information on pixelization and similar research.
# python3 depix.py -p pic2.png -s images/searchimages/black-shell-dict-putty.PNG -o output2.png INFO:root:Loading pixelated image from pic2.png INFO:root:Loading search image from images/searchimages/black-shell-dict-putty.PNG INFO:root:Finding color rectangles from pixelated space INFO:root:Found 494 same color rectangles INFO:root:480 rectangles left after moot filter INFO:root:Found 77 different rectangle sizes INFO:root:Finding matches in search image INFO:root:Removing blocks with no matches INFO:root:Splitting single matches and multiple matches INFO:root:[3 straight matches | 23 multiple matches] INFO:root:Trying geometrical matches on single-match squares INFO:root:[3 straight matches | 23 multiple matches] INFO:root:Trying another pass on geometrical matches INFO:root:[3 straight matches | 23 multiple matches] INFO:root:Writing single match results to output INFO:root:Writing average results for multiple matches to output INFO:root:Saving output image to: output2.png
Network evasions
Примеры:
fragmentation
segmentation
polymorphic like obfuscation/encoding/encryption (HTTP, SMTP, etc)
time delay attacks
attacks under load
промежуточные системы типо proxy (подмена IP/PORTS)
Скрытые коммуникации могут быть реализованы на базе практически любого протокола, который используется в сети для обмена данными между конечными хостами, особенно часто этим протоколом является один из следующих: IPv4/IPv6, TCP, UDP, ICMP, DNS.
IPv6 используется для этой задачи часто т.к. edge устройства зачастую не сконфигурированы или даже не поддерживают распознавание IPv6 трафика и он на них не запрещен. Кроме того (по мнению US-CERT) недостатком считается функционал IPv6 autoconfiguration. В итоге возможно туннелирование сетевого трафика приватной сети поверх сети Интернет используя тулзы вроде 6tunnel, socat, nt6tunnel, relay6. Нужно понимать, что даже если продукты информационной безопасности поддерживают распознавание IPv6, эти же продукты могут не справится с задачей корректного анализа IPv6, когда он инкапсулирован в IPv4.
Точно так же как IPv6, ICMP протокол может так же использоваться для туннелирования трафика.
В контексте TCP есть разные бекдоры. Например ACKCMD – обходим файрволы, которые настроены для инспекции только 3WHS – считаем, что если мы на уровне файрвола контролируем установку 3WHS (напр. на базе SYN permit/deny rule), то мы контролируем полностью TCP обмен между хостами. Backdoor требует установки софта на зараженный хост, который будет реализовывать обмен только на базе TCP ACK пакетов.
В контексте UDP он может вообще не логгироваться как соединение в файрволе или по умолчанию иметь разрешающее правило для DNS трафика. Примером backdoor на основе DNS являются: UDP tunnel (туннелируем TCP в UDP пакетах), DNSCAT (туннелируем данные в DNS протокол). Безусловно резкий скачек DNS трафика может быть подозрителен для администраторов/ИБ, но особо умные делают его отправку по расписанию.
В контексте туннелирования на уровне приложения возможны сценарии использования HTTP(S), SSH, DNS и туннелирования в них данных других протоколов. Используя netcat можно передать данные поверх HTTP, а используя cryptcat поверх HTTPS.
Social engineering (социальная инженерия)
Phishing (fake email, spear phishing, email spoofing), Baiting (usb-drive), Tailgating (access to restricted area) – чаще всего решаются через обучение персонала
Software Development (атаки на софт)
Secure Development Life сycle (SDL) – повторяемый и измеряемый процесс разработки, нужен для того, чтобы продукты были максимально безопасными и устойчивыми даже в случае обнаружения уязвимостей в них. Практически невозможно на этапе дизайна и разработке устранить все уязвимости, поэтому в компании, разрабатывающей security продукты должен быть внедрен SDL. SDL обычно включает не только программирование:
Описание требований по безопасности к продукту
Безопасность третих сторон (Third-party software, TPS) – важный аспект т.к. в сегодняшних реалиях почти любая компания использует open-source и third-party (платный/бесплатный) софт. Получается PSIRT нужно отслеживать какие библиотеки используются (для этого есть специальные утилиты по скану source code/binaries), какие у них уязвимости и инициировать патчи этих уязвимостей. Так же нужно быть готовыми к тому, что вы не можете управлять продуктом третьей стороны полноценно – например, зачастую, уязвимости в них могут патчится месяцами и даже годами.
Дизайн безопасности
Безопасное программирование
Аналитика безопасности
Тестирование на уязвимости
Баги софта (bugs) – ошибки программирования, которые могут приводить к разного уровня угрозам – от мирных/незначительных инцидентов, до полной катастрофы. Как избежать: проводить code review, обновление языков программирования/библиотек/модулей/приложений, отключение ненужных приложений, ограничение доступа к нужным приложениям
Неправильные практики программирования
validating input & sanitizing user input (подробнее в sql injection, XSS, buffer overflow)
hardcoded сенситивная информация (api credentials, passwords, пути, старый код)
комментарии с такой информацией, слив такой информации в публичные или плохо защищенные приватные репозитории – существует публично доступный список типов уязвимостей Common Weakness Enumeration (CWE), в котором слив информации через комменты обозначен отдельным ID – CWE-615
отсутствие error handling или наоборот слишком подробный error handling выдаваемый пользователю
небезопасные практики API (шифрование, аутентификация, несоответствие стандарту, отсутствие документации и проч) в API любого типа (SOAP+XML, REST+JSON, GraphQL, etc) – используем такие вещи как SWAGGER OpenAPI
Authentication&AUTORIZATION-based attacks
Примеры атак на аутентификацию и авторизацию:
Brute forcing
Session hijacking
Redirecting
Использование default или weak credentials
Использование authn/authz/encryption/hash уязвимостей (напр. WEP, RC5, MD5, DES, Kerberos)
Password attacks напр. brute force, dictionary обычно митигируются путем использования strong passwords, 2FA, captcha, IPS
Brute force так же используется как атака для взлома шифрования (подробнее ниже)
Offline атаки на пароли (попытка найти пароль на основе hash/зашифрованного content, как, например в Wi-Fi) более опасны в сравнении с online – т.к.
их попытки не логгируются и не обрабатываются в системах, доступ к которым пытается получить взломщик – после ряда неудачных попыток аутентификации – не будет паузы/блокировки аккаунта/запроса каких-то доп. данных/reCAPTCHA
возможен перебор намного большего количества credentials в секунду.
В brute-force мы пытаемся угадать ключ/пароль к зашифрованным или захешированным данным, защита через длину ключа/выбора хеш функции, но технически говоря, считается что 100% защиты от brute force не существует – все упирается во времени и ресурсах, если они безграничны – любая система в теории может быть взломана. Какие рекомендации – использовать сложный пароль, использовать salt, прогонять пароль и соль через hashing алгоритм много раз (до сотен) раз.
Strong password & 2FA/MFA
Очень часто администраторы и пользователи не меняют пароль на устройства (свичи, роутеры, AP и даже Firewalls). Для таких есть поговорка – зачем вам нужны хакеры, если вы используете дефолтные пароли.
Слабо защищенные и не ротируемые credentials являются основной причины компрометации учетных данных. Чем более устойчивый к подбору пароль вы используете – тем лучше (немного капитаним). Еще лучше использовать 2FA/MFA как дополнительный этап аутентификации – они значительно уменьшают вероятность атак на базе простого подбора.
Незащищенные пароли – пароли можно найти в code девелопе и скриптах автоматизации.
Strong password не должен полагаться только на замену букв на созвучные буквы/цифры (типо f1rst), это учтенные вещи во многих password cracking tools. Обычно политики создания/обновления паролей задаются централизованно через AD, IPA (Identity Policy Audit) и уже AD/IPA проверяют пароли на политики – длина, наличие спец. символов, повторяемость, отсутствие словарных слов и прочее. И безусловно нельзя – передавать пароль, записывать на бумажке, использовать один пароль в нескольких системах. Пароли нужно периодически ротировать.
Из спец. публикации NIST 800-63B:
Аутентификационная стойкость пароля является функцией от его сложности.
Основное – длина пароля. Минимум 8 символов. Но в целом нужно учитывать модель угроз.
В пароле должны присутствовать:
Спец. символы
Разный регистр
Цифры и буквы
Рекомендуется регулярная ротация парольной информации
На уровне приложения
должна быть реализована защита от brute force как минимум на уровне rate limit
рекомендуется реализовать обязательную смену пароля при первичной настройке
Использование одного пароля везде серьезно увеличивает вероятность взлома
2FA/MFA
2FA/MFA – Уровень аутентификации обычно определяется по уровню угроз. Но в общем случае чем безопасней, тем лучше – даже геймеры используют MFA уже годы. Примеры данных, на основе которых проводят аутентификацию – по username/password, PIN, карта, по ключу, по смс, по токену (physical/software), face ID/IRIS scan/fingerprint, связка методов (2FA/MFA). Почему нельзя использовать только пароль: haveibeenpwned.com
Большое количество примеров есть на сайте Cisco Duo. Так же про Cisco duo в статье про AAA.
signature/keystroke dynamic считаются не очень надежными способами т.к. системы на их основе изначально спроектированы с вероятностью ошибок (подробнее об ошибках работы с биометрическими системами ниже)
по тому, где вы находитесь (geo IP),
по тому, когда вы работаете с системой (рабочие часы или наоборот)
Knowledge factor: "Something you know." The knowledge factor may be any authentication credentials that consist of information that the user possesses, including a personal identification number (PIN), a user name, a password or the answer to a secret question.
Possession factor: "Something you have." The possession factor may be any credential based on items that the user can own and carry with them, including hardware devices like a security token or a mobile phone used to accept a text message or to run an authentication app that can generate a one-time password or PIN.
Inherence factor: "Something you are." The inherence factor is typically based on some form of biometric identification, including finger or thumb prints, facial recognition, retina scan or any other form of biometric data.
Location factors of authentication confirm the identity of a user based on their location in the world. If a user had registered an account in one country, for example, and suddenly there are login attempts from another, location factors could trigger and attempt to verify the identity of the new user. Many location factors are based on the IP address of the original user and compares the address to that of the new attempt to access information.
Time factors of authentication verify the identity of a user by challenging the time of the access attempt. This is based on the assumption that certain behaviors (like logging into a work computer) should happen within predictable time ranges. If an attempt to access a platform happens outside of the usual time range, the attempt can be challenged or terminated until a user can verify their identity.
Single factor – когда только один из перечисленных факторов используется
Multifactor (MFA) – когда используются несколько
Multilayer – когда один и тот же фактор проверяется два и более раз
Out-of-band authentication – когда аутентификация производится по независимому от данных каналу
В контексте аутентификации важным вопросом является session management – как проверяющая сторона принимает/передает/сохраняет информацию об аутентифицируемом объекте (клиенте/сервере). Чаще всего в WEB приложениях используется Session ID, который сохраняется на сервере как соответствие конкретному клиенту и передается клиентом в каждом запросе к серверу. Сессии должны быть уникальны и сложно математически вычисляемыми.
Пароли в правильных реализациях хранятся не в виде clear text, а в виде hash. Аналогичное справедливо и для биометрических данных – они не хранятся в том виде, в котором существуют.
They’re creating fake fingerprints using things like glue, allowing friends to mark each other as present if they’re late or skip school.
If a biometric characteristic, like your fingerprints, is compromised, your option for changing your "password" is to use a different finger. This makes "password" changes limited. Other biometrics, like iris scans, can't be changed if compromised. If biometric authentication material isn't handled securely, then identifying information about the individual can leak or be stolen.
Два типа ошибок различают при работе с биометрическими системами:
Type 1 – False Rejection eRrors (FRR) – система откланяет валидного пользователя
Type 2 – False Acceptance eRrors (FAR) – система аутентифицирует невалидного пользователя (напр. атакующий выдает себя за валидного пользователя)
В контексте ошибок биометрики так же существуют понятие Crossover error rate (CER) которое так же называют Equal error rate (EER) – когда уровень False rejection errors (FRR) равен уровню False Acceptance Error (FAR). CER/EER обычно является индикатором точности биометрической системы.
Использование encryption/authn/authz уязвимостей (напр. WEP, RC5, MD5, DES, Kerberos)
При шифровании процесса аутентификации с использованием уязвимых протоколов шифрования можно потерять credentials. Очень хорошая табличка на этот счет есть у Cisco (скопировал только первые три строки).
Тоже самое справедливо для WEP – его плохой дизайн приводит к потере пользовательских credentials.
Сохранение hash паролей без salt приводит к возможности использования rainbow tables (подробнее поиском по randbow).
Session hijcking
Существуют разные способы “воровства сессии”:
Предсказание токена сессии – должно быть рандомизированно, иначе это всегда возможно
Прослушивание сессии (обычно происходит из-за отсутствия шифрования)
MitM атака
MitB атака (Man-in-the-browser attack) – по сути MitM, только в качестве объекта по середине выступает зараженный браузер.
Injection attackS
SQL injection attack (SQLi) – приводят к сливам/изменению SQL базы за счет доступа к ней напр. используя спец. символы, логические операторы и уязвимости приложения по их обработке. Вообще помимо SQL injection существуют и другие виды injection атак, основанных на том же принципе отправки “некорректных” данных – HTML script injection (ниже подробнее), Command Injection (ниже подробнее), Dynamic code evaluation, Object injection, Remote file inclusion, Uncontrolled format string, Shell injection. Как избежать: изменение кода, good software principles like validating input & sanitizing user input (часто включено в WEB frameworks), изоляция переменных, переиспользование функций. Для демо атаки можно использовать DVWA, OWASPWEBGOAT (линки на них поиском по OWASP), BurpSuite (прокси перехватывающее транзакцию между браузером и сервером) + sqlmap (подменяем запросы в сохраненной BurpSuite транзакции, узнаем название базы и сливаем ее с попыткой подбора по хешам паролей на основе словаря).
“Ручная” инъекция используя OWASPWEBGOAT
Способы эксплуатации SQL injection (примеры красным выше в выводе sqlmap; способы могут быть комбинированы вместе):
Union operator: поддержка оператора объединения, в итоге можно сделать несколько запросов к базе в одном SQL statement
Boolean: проверка на true/false.
Error-based technique: учимся на получаемых ошибках и улучшаем запрос.
Time delay: использование задержки в ответе.
Категории SQL injection атак:
In-band SQLi – атакующий получает данные используя тот же канал, что для запроса (т.е. данные выгружаются непосредственно в web application или web page). Базовая форма SQL injection.
Out-of-bandSQLi – атакующий получает данные используя канал отличный от того, который использовался для запроса (напр. email, ftp, IM, http/scp/etc connection to different server).
Blind (or inferential) SQLi – приложение при такой атаке не отображает и не передает какие-либо данные, атакующий реконструирует информацию путем отправки SQL запросов и просмотра поведения приложения и базы данных (вода конечно, при детальном разборе нужно подробнее).
HTML injection – пользователь может инъецироать HTML код в web-приложение, что в итоге может приводить к потере cookies, изменению контента на сайте, XSS и другим проблемам.
проверка на корректность входных переменных (input validation)
параметризируемые запросы в базу (parameterized/bin/placeholders)
экранирование специальных символов (escaping)
ограничение доступа к базу только необходимым (least privilege)
Pattern check Integer, float or boolean, string parameters can be checked if their value is valid representation for the given type. Strings that must follow some strict pattern (date, UUID, alphanumeric only, etc.) can be checked if they match this pattern
Parameterized statements With most development platforms, parameterized statements that work with parameters can be used (sometimes called placeholders or bind variables) instead of embedding user input in the statement.
Escaping A straightforward, though error-prone way to prevent injections is to escape characters that have a special meaning in SQL.
Database permissions Limiting the permissions on the database login used by the web application to only what is needed may help reduce the effectiveness of any SQL injection attacks that exploit any bugs in the web application.
Command injection – атакующий исполняет команды, которые он не авторизован исполнять из-за уязвимости в приложении. Command injection отличается code execution/code injection атак тем, что он не использует уязвимости buffer overflow, а использует уязвимости некорректной валидации данных получаемых от пользователя (вообще довольно спорное утверждение, особенно что эта причина зачастую является следствием и buffer overflow).
Buffer overflow attacks
Buffer overflow (подтипом являются атаки возврата в библиотеку, ret2libc) – переполнение буфера. Атака, как и многие другие (SQL injection, XSS) является причиной недостаточного input validation/sanitation/escape technique – блок данных при записи переполняет выделенный буфер под эти данные, что приводит или к отказу в обслуживании или к (зачастую еще хуже) использованию участков памяти, предназначенных под другие данные (heartbleed, buffer over-read), что в свою очередь может приводить к remote/arbitrary code execution (RCE), чтению/изменению персональных данных или ключей шифрования и прочим радостям жизни. Обычно сама проблема возникает в системных языках типо C, C++. Сама проблема buffer overflow часто обнаруживается при использовании fuzzing утилит.
Для избежания buffer overflow (особенно с последующим code execution) могут быть использованы техники ОС:
ASLR – Address Space Layout Randomization – рандомизируем адресацию памяти
Canaries – сознательно оставляем пустое пространство между буферами
Stack smashing protection – защищает от code execution т.к. обнаруживает buffer overflow (stack smashing) и потенциально может вычистить проблемный сегмент памяти
ASCII Armoring – при использовании техники адрес каждой системной библиотеки (напр. libc) начинает содержать нулевой байт в начале при хранении в памяти, в итоге исполняемый участок памяти не уникален относительно первого байта и нужно вызывать overflow нулевого байта.
Non execute bit (NX-bit) – не защищает от самого buffer overflow, но защищает от code execution нового кода после buffer overflow
Пример кода C скрипта содержащего уязвимость buffer overflow и эксплуатацию этой уязвимости с последующим code execution функции “secretFunction” (которая не вызывается вообще непосредственно кодом скрипта) с использованием objdump + edb (Evan’s Debugger) + немного python.
C script
XSS, CSRF attacks
XSS (cross-site scripting) – добавление зловредного кода на сайт например для session/cookie hijacking/account compromise пользователей этого сайта, установки зловредного кода или даже простого перенаправления пользователя (напр. зеркало легитимного сайта). Несмотря на то, что в атаке XSS используется уязвимость WEB приложения, жертвой обычно является конечный пользователь этого приложения. Очень популярная атака. Самое противное – чаще всего атака проходит незаметно для жертвы.
Существует три типа XSS атак:
Stored (persistent) – уязвимая страница/скрипт сохранена в постоянной памяти (в базе/в файле) на сервере с XSS уязвимостью. Чаще всего веб-сервер/веб-приложение с XSS уязвимостью является “доверенным” для клиента.
Reflected (non-persistent) – уязвимая страница не сохранена в постоянной памяти. К примеру, пользователь может пройти по линку, который будет включать XSS скрипт с уязвимостью.
DOM-based
Уязвимость XSS обычно обнаруживается в следующих местах: поля для поиска, HTTP заголовки, формы ввода, сообщения об ошибках с пользовательским текстом, спрятанные поля с пользовательскими данными.
Методы защиты от XSS (как на уровне серверной так и на уровне клиентской стороны) описаны в статье на wiki.
не даем пользователю (потенциальному атакующему) вводить что угодно (экранируем в зависимости от контекста пользовательский ввод и проверяем ввод):
Contextual output encoding/escaping of string input
Safely validating untrusted HTML input
ограничиваем или запрещаем работу cookie и скриптов на клиентской стороне (потенциальной жертве)
Cookie security – привязываем cookie к конкретному IP (воровство клиентского cookie не даст клиентский доступ, если не использовать его IP) или не отдаем cookie на клиент вообще
SameSite cookie parameter – запрещаем xss или ограничиваем его только ro операциями, отослав от сервера клиенту cookie с определенным параметром
Disabling scripts or Selectively disabling scripts – отключаем скрипты полностью/на уровне домена/анализируя их автоматически
Хороший пример самой атаки так же описан в статье на wiki.
Для тренировки с уязвимостью XSS и другими WEB-уязвимостями, которые рассмотрены в проекте OWASP можно использовать тулзы OWASP Juice Shop, OWASP WEBGOAT, OWASP ZAP (Zed Attack Proxy) или DVWA (Damn Vulnerable Web Application) – можно на практике посмотреть уязвимости OWASP top 10 и другие. К примеру вместо “omar was here” можно сгенерировать “please relogin” и перенаправить пользователя на фейк страницу, на которой собирать учетки. Примеры атак XSS. Чаще всего XSS/CSRF уязвимости являются причиной недостаточного input validation/sanitation/escape technique.
CSRF/XSRF (Cross-site Request Forgery, one-click attack, session riding) – подделка пользовательских запросов. Атака отличается от XSS, где уязвимым хостом является сервер – тут уязвимость эксплуатируется на пользователе. Эксплуатируется то, что сайт считает, что пользователь авторизован на это действие, а по факту действие инициировано не самим пользователем и пользователь об этом действии обычно не знает. Может приводить к списанию средств (покупка/перевод средств от вашего лица), изменению вашего пароля, получению доступа к приватной информации и прочим прелестям. Чаще всего XSS/CSRF уязвимости являются причиной недостаточного input validation/sanitation/escape technique (как и многие многие другие атаки).
MISC ATTACKS
Cookie manipulations attacks, DOM-based attacks – уязвимое пользовательское приложение сохраняет пользовательский ввод в DOM как часть ответа. Атакующий может изменить эти данные в сookies. Влияние зависит от того, как эти cookie обрабатываются внутри приложения.
Race Condition (TOCTOU attack; time of check to time of use) – когда несколько процессов пытаются прочитать/записать один и тот же ресурс (напр. файл) в один момент времени, при этом система на это не рассчитана. Считается сложной для эксплуатации атакой т.к. система при race condition дает в общем случае лишь малое окно времени, в которую можно получить profit от успешно проведенной атаки race condition.
Unprotected APIs – многие API плохо контролируются, не мониторятся и сложны в своей логике. В самом API (REST/SOAP, без разницы) может быть реализовано все самое новое (что еще в roadmap), а в документации все тщательно описано, что позволит хакерам чувствовать себя у вас как дома.
XEE (XML External Entities) – использование уязвимостей обработчиков XML (напр. перенаправления URI handler, внутренние share, remote code execution, DoS)
Insecure Deserialization – неправильное хранение или передача десерализованных данных может приводить к rce (remote code execution), атакам на повторение (replay attacks), атаках на инъекцию (injection) и повышение привилегий (privilege escalation).
Using components with known vulnerabilities – библиотеки, фреймворки и модули (напр. open source) имеющие известные уязвимости используются в системе.
Insufficient logging & monitoring – приводит к проблемам при forensics, отстутствию понимания причин/уровня ущерба и зараженных систем, поздному обнаружению заражения (или даже отсутствию этого обнаружения)
Directory traversal, path traversal, dot-dot-slash attack – уязвимость состоит в том, что мы можем выходить из пределов директории web сайта в директорию системы и манипулировать там с файлами (как минимуму read). Вместо точек иногда получается использовать закодированные символы %2e, %2f, которые по сути означают тоже самое (точка и слеш) или комбинацию этих символов со стандартными. Протестировать эксплуатацию уязвимости можно используя DVWA (о нем подробнее по поиску). Для защиты от уязвимости нужно не давать пользователю вводить пути файловой системы, использовать политики разграничения, которые можно наложить в зависимости от ОС, не сохранять важные файлы в web root directory. Пример path traversal уязвимости – в Cisco ASA и Cisco Firepower при включенном webvpn возможна атака path traversal с изменением и удалением системных файлов CVE-2020-3187, CVSS 9.1.
Cryptology (криптография)
Steganography (стеганография) — это наука о скрытой передаче информации путём сохранения в тайне самого факта передачи. Главная задача сделать так, чтобы человек не подозревал, что внутри передаваемой информации, не представляющей внешне абсолютно никакой ценности, содержится скрытая ценная информация.
Cryptology/cryptography(криптография). Шифруем что-то, чтобы не увидели другие. Реализация принципов CIA: конфеденциальность, целостность, аутентификация. Теме тысячи лет, но особенно она развивается сейчас.
Cryptosystem – взаимосвязь алгоритмов генерации ключа шифрования, шифрования и дешифрования данных.
Cryptanalysis – криптоанализ. Попытка расшифровать данные, даже если неизвестны какие-то необходимые элементы для этого (ключи/алгоритмы). Например, путем взлома алгоритма шифрования или его имплементации.
Лингвистический анализ – подход для старых алгоритмов
Frequency analysis – практика изучения частоты появления букв в зашифрованном тексте. Frequency analysis основан на том, что в письменном языке: 1) определенные буквы встречаются чаще, чем другие (English: e, t, a, o) 2) определенные буквы чаще группируются вместе с другими (English: er, th, an, on). Frequency analysis может быть использован для таких методов шифрования как Letter transposition/substitution т.к. они сохраняют частоту букв в шифре.
Математический анализ + автоматизация – подход для новых алгоритмов. Подразумевает, как вычисления на базе обычных CPU, так и на основе видеокарт или даже квантовых компьютеров. Несмотря на то, что современные криптосистемы считаются очень стойкими, риски взлома с использованием современных же методов и разработок вполне реальны (напр. квантовые вычисления и простота операции факторизации числа (разложение на множители) для них, при этом аксиома сложности этой операции для больших числе заложена например в RSA) .
Encryption Algorithm (Алгоритм шифрования) – алгоритм, на основе которого шифруются данные – DES, AES, RSA. Являются по сути дизайном, а не реализацией. Этот дизайн в последующем имплементируют разработчики в реализацию – софтовую, хардварную. Важными параметром алгоритма являются:
криптостойкость
скорость и потребность в ресурсах для шифрования -операция шифрования частая, даже одни данные могут несколько раз шифроваться, поэтому нужно чтобы быстро и максимально ненапряжно для системы. Поэтому часто hardware (Intel/AMD CPU имеют AES инструкции встроенные в CPU).
простота реализации – важна не только из-за скорости time-to-market, стоимости реализации, но и из-за вероятности баги в сложной имплементации. Очень часто проблема заложена не в алгоритме или разрядности, отданной под ключ, а в реализации алгоритма на практике – такие вещи как AES и DES правильно реализовать непросто.
Cipher – шифр. Набор правил (алгоритм) как выполнять шифрование/дешифрование.
Security through obscurity (безопасность через неясность) – плохой шифр состоит только из encryption algorithm. Основан на том, что никто не знает какой алгоритм мы используем (совсем базого – ключ под ковриком двери, пароль под клавой).
Шифр подстановки (Transposition cipher, Letter transposition) – простое перемещение букв.
Шифр замены (Substitution cipher, letter substitution) – простая статичная замена одних букв/пары или тройки букв, на другие. Это совсем базовое шифрование, основанное только на encryption algorithm. Например, шифр
Caesar Cipher (шифр Цезаря), в котором замещение символа происходило символом, находящимся на некотором постоянном числе позиций левее или правее него в алфавите. Формально тут есть ключ – количество символов и направление смещения, но он слишком простой и зная логику, можно подобрать ключ.
ROT13, в котором замещение символа происходило символом, находящимся на 13 позиций левее него в алфавите. Частный случай шифра Цезаря. В интернет-форумах для оскорблений других используюется иногда 😉 По сути это частный пример шифра цезаря с ключем 13. Причем число 13 (половина от английского алфавита) позволяет добиться эффекта, что шифр симметричный (смещаемся на 13 символов для кодирования символа и еще на 13 символов для декодирования = начальный символ) – можно использовать тот же ключ для дешифрования, что и для шифрования.
Poly alphabetic ciphers – по сути substitution cipher на основе нескольких алфавитов. Переключение алфавита происходит по особому символу.
Kerckhoffs’s principle (Shannon‘smaxim, “the enemy knows the system”) – хороший шифр состоит из двух компонентов – encryption algorithm + key. Такой encryption algorithm как RSA не разберешь без PhD в математике. Ключ добавляет что-то уникальное в шифр, что с одной стороны, имея ключ, позволяет расшифровать исходные данные, с другой – не позволяет расшифровать шифр, зная даже используемый алгоритм, а во многих случаях и публичный ключ.
Постквантовая криптография описывает проблемы (уязвимость алгоритмов на базе факторизации, эллиптических кривых) и потенциальные методы решения (использование симметричных алгоритмов, увеличение длины ключа, использование квантовых методов обмена ключами вместо алгоритмов на основе открытого ключа)
Encryption – шифрование. Применение к исходным данным (plaindata, plaintext) какого то encryption algorithm (DES/RSA/AES) с ключем, чтобы при передаче данные были зашифрованы (cipherdata, ciphertext).
Decryption – дешифрование. Применение к зашифрованным данным (cipherdata, ciphertext) какого-то decryption algorithm с ключем, для получения исходных данных (plaindata, plaintext). Основные типы шифрования различаются по методу decryption:
Symmetric (симметричное) – используют один ключ для шифрования и дешифрования
Assymetric (ассиметричное) или Public key/private key – используют разные ключи для шифрования и дешифрования.
Сразу несколько определений по картинке ниже:
Encryption Key (ключ шифрования) – используется для кодирования данных. Важные процессы в контексте ключей – его
key size/length (размер/длина ключа) – чем больше, тем лучше. Пишется в битах (напр. в DES 56 bit = 72kkkkk, квадриллион или 72000 триллионов возможных ключей). Определяет количество бит, которые составляют ключ шифрования. Или другими словами – максимальное количество возможных ключей, которое может сгенерировать алгоритм шифрования. Длина ключа влияет на ряду со стойкостью самого алгоритма (зачастую важнее, но в идеальной ситуации, когда криптоалгоритм неуязвим, можно только атаковать ключ, например brute force’ом пытаясь угадать его) на максимальную потенциальную криптостойкость системы. The larger the key, the more secure the encrypted data will be. The security of a symmetric cryptosystem is a function of two things: the strenght of the algorithm and the length of the key.
key generation (генерация ключа) – может являться комбинацией нескольких ключей (ключ алгоритма + ключ IV). Тут появляется вопрос псевдо-рандом (см. DSA и Sony) или рандом. Генерация может основываться на базе
факторизации числа (number factorization)
эллиптических кривых (elliptic curves)
key exchange (распространение ключей) – для безопасного распространения симметричного ключа может использоваться ассиметричное шифрование или Diffie Hellman алгоритм (подробнее ниже)
повторное использование (защита с использованием initialization vector, IV)
PFS (perfect forward secrecy) – фича протокола, которая позволяет избежать зависимости сессионных ключей между собой – компрометации старых сессионных ключей при компрометации новых и наоборот
Random generator – Random является крайне важной темой в безопасности, т.к. многие системы безопасности полагаются на отсутствие логики в нем.
Random number generator (NG) – генератор (не псевдо) случайных чисел. Обычно аппаратный, например TPM (Trusted Platform Module). Пример полезного сайта для генерации настоящего (как утверждают на основе погодных данных) рандома – random.org. Широко используется в лотереях – по факту, при простой трансляции экрана, не защищает от подмены сайта в hostname и поддержки зеркалом; правильно было бы еще иметь возможность генерировать обратный url с ID запрашивающего на random.org для проверки результата.
RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs. People use RANDOM.ORG for holding drawings, lotteries and sweepstakes, to drive online games, for scientific applications and for art and music. The service has existed since 1998 and was built by Dr Mads Haahr of the School of Computer Science and Statistics at Trinity College, Dublin in Ireland. Today, RANDOM.ORG is operated by Randomness and Integrity Services Ltd.
Pseudo-random number generator (PNG, Генератор псевдослучайных чисел) – алгоритм, порождающий последовательность чисел, элементы которой почти независимы друг от друга и подчиняются заданному распределению (обычно равномерному). В операционных системах для генерации рандома используется entropy pool – источник рандомных данных (время, состояние диска, фаза луны..), которые используют генераторы рандома.
Initializationvector(IV, векторинициализации), представляет собой произвольное число, которое может быть использовано вместе с секретным ключом для шифрования данных. В результате получается схема: shared master key + one-time encryption IV key (передается открыто). Пример использования – 802.11 WEP шифрование, AES. Использование IV предотвращает повторение шифрования данных, что делает процесс взлома более трудным для хакера с помощью атаки по словарю, в попытках найти шаблоны и сломать шифр.
Nonce– рандомная последовательность, которая может быть использована только один раз при взаимодействии (once). Часто используется в Initialization Vector (IV).
Symmetric encryption (симметричное шифрование)
Symmetric key cryptography is also known as preshared key cryptography (PSK)
Ключ для дешифрования = Ключ для шифрования (подробнее в общем разделе Криптография, шифр ROT13). Этот ключ должен держаться в секрете.
В сравнении с ассиметричным шифрованием легче для реализации, проще использовать, быстрее для шифрования большого количества данных. Кто-то (книги) говорит в 500 раз быстрее симметричное шифрование – по факту it depends (алгоритм, hardware offload), но понимание того, что быстрее однозначно есть. Но симметричность может быть неудобна и даже не безопасна – например
Ассиметричное шифрование позволяет безопасно обмениваться данными по незащищенному каналу без предварительной передачи общего ключа шифрования, как в симметричном шифровании
если пароль Wi-Fi украден, нужно менять пароль на всех устройствах
если нужно дать какой-то большой группе людей временный доступ, ты же не будешь им давать постоянный пароль, тебе нужен временный, но Virtual SSID не все роутеры поддерживают
Многие протоколы/схемы используют как симметричное шифрование, так и ассиметричное, на основе лучших качеств обоих:
для обмена симметричными ключами (symmetric encryption key/shared secret) используется ассимметричное шифрование (secure key exchange is a common application for assymetric algorithms)
для последующего обмена (шифрования/дешифрования) данными используется симметричное шифрование на основе полученных ключей
Симметричное шифрование бывает реализовано
блочным (block ciphers)шифрованием – несколько символов (статичное количество, притом, что если данных недостаточно – добавляются) шифруется в один. Обратное от поточных.
поточным (stream ciphers) шифрованием – один символ шифруется в один символ (1к1). Работают быстрее и проще для реализации, но обычно менее безопасны.
A stream cipher takes data in as a continuous stream, and outputs the ciphertext as a continuous stream, too. A block cipher encrypts the data in chunks, or blocks.
Примеры популярных симметричных алгоритмов
- DES, 3DES, RC4, and AES # are all symmetric encryption algorithms (все блочные) - Kerberos использует симметричное шифрование
Rivest Cipher 4 (RC4) – симметричных поточных алгоритм, поддерживает ключи от 40 бит до 2048 бит. Был очень широко распространен из -за простоты реализации и скорости работы. Сейчас не рекомендуется к использованию т.к. сам алгоритм (не длина ключа) признан слабым (например. RC4 NOMORE attack). RC4 используется во многих протоколах – TLS (старом), 802.11 WEP, 802.11 WPA. Многие браузеры отказались от поддержки RC4 (preferred secure browser/web server configuration: TLS 1.2 with AES GCM).
Data Encryption Standard (DES) (так же известен как ) – придуман в 1970 IBM + USA Nation Security Agency и принят как стандарт под названием Federal Information Processing Standard (FIPS) в USA (т.е. может использоваться для шифрования правительственных данных). Является симметричным блочным шифром (работает с блоками в 64 бита), использует 56-битный ключ (64 бита всего, из них 8 бит используются под проверку четности, parity checking – простейшую и малоэффективную проверку на ошибки). Длина ключа в 56 бит изначально закрывала все вопросы, но потом, с ростом вычислительных мощностей, то что предполагалось только в теории, произошло – в 1998 EEF дешифровала ключ DES всего за 56 часов.
Advanced Encryption Standard (AES или Rinjndael, рэндал) – замена DES. Единственный публичный алгоритм, который разрешено использовать для секретных данных USA Nation Security Agency. В текущий момент является по сути “стандартом” шифрования. Создан Винсент Рэймен, Йоан Даймен.
By default является симметричным блочным шифром (работает с блоками в 128 бит), использует ключи 128, 192 или 256 бит. Из-за размера ключа AES brute force атака на него в текущий момент только теоретически возможна (как в 70х годах с DES).
AES GCM (Galois/Counter Mode) – специальный режим работы AES, в котором блочный шифр по сути превращается в поточный. GSM супер-популярный из-за того что он безопасный, простой в реализации, очень быстрый и может быть запущен параллельно. Preferred secure browser/web server configuration: TLS 1.2 with AES GCM.
AES-128/256 (c WinRAR 5) активно используется для шифрования файлов в WinRAR, 7z. Они не хранят пароли, а хранят hash от них (на основе PBKDF2). Проверку пароля Winrar делает на основе hash HMAC-SHA256 от пароля (ключа) и, если hash от пароля совпадает с hash, хранимым в архиве – дешифруют данные на основе этого ключа.
В контексте шифрования RAR стоит отметить что – всегда лучше использовать шифрования и содержимого и методанных “encrypt file names” – это вытекает из реальных взломов старых версий и того, что там используются “спец” алгоритм by Winrar (даже в новой версии).
Assymetric encryption, public key cryptography (ассиметричное шифрование, Криптографическая система с открытым ключом)
Assymmetric key cryptography is also known as public key cryptography.
Ключ для дешфирования != Ключ для шифрования
Основное преимущество ассиметричного шифрования – оно позволяет организовать защищенную связь по незащищенному каналу
Симметричное шифрование более сложное для реализации/вычислений, поэтому медленнее работает
В отличии от симметричных алгоритмов шифрования ассиметричное шифрование предоставляет
конфиденциальность (см. базовый алгоритм шифрования/деширофвания)
аутентификацию и невозможность изменения данных (см. сертификат открытого ключа, цифровая подпись) (confidentiality, authenticity, non-repudiation)
Ассиметричное шифрование позволяет безопасно обмениваться данными по незащищенному каналу без предварительной передачи общего ключа шифрования, как в симметричном шифровании
Многие протоколы/схемы используют как симметричное шифрование, так и ассиметричное, на основе лучших качеств обоих:
для обмена симметричными ключами (symmetric encryption key/shared secret) используется ассимметричное шифрование (secure key exchange is a common application for assymetric algorithms)
для последующего обмена (шифрования/дешифрования) данными используется симметричное шифрование на основе полученных ключей
В assymetric encryption данные шифруются public key, причем он может быть и у злоумышленника, но расшифровать их можно только с помощью private key. Сила шифрования основывается на принципе односторонней функции (вычислительной сложности вычисления private key на основе public key).
Basic algorithm (Базовый алгоритм работы)
Оба участника генерируют (каждый свой) private key
Используя private key оба участника генерируют (каждый свой) public key
Участники обмениваются своими public key (а если быть точным – public key signature, см. ниже почему)
При передаче информации другому участнику
мы шифруем информацию полученным от участника public key
отсылаем участнику
участник, при приеме информации, дешифрует информацию используя свой private key
enjoy
Public Key infrastructure (PKI), Public Key Signature (Сертификат Открытого Ключа), Certification authority (ЦЕНТР СЕРТИФИКАЦИИ), Digital signature (ЦИФРОВАЯ ПОДПИСЬ)
Все бы хорошо в базовом алгоритме, только возможно такое, что злоумышленник выдаст свой public key представляясь тобой (dns spoofing, arp spoofing, reroute, все что угодно) и другой участник будет обмениваться данными с злоумышленником, думая, что обменивается с тобой.
Поэтому тут появляется Public Key Signature (Сертификат Открытого Ключа). Сертификат открытого ключа позволяет на получающей стороне сопоставить публичный ключ с отправителем, проверить неизменность сообщения.
Public Key Infrastructure (PKI) – это инфраструктура (Infrastructure) по работе с публичными ключами (Public Key).
PKI – критичная часть в безопасности соединений в интернете сегодня. PKI является системой, которая определяет создание, сохранение, распространение и отзыв/аннулирование (revocation) цифровых сертификатов для public/private keys. PKI позволяет реализовать authentication, confidentiality, non-repudiation, integrity.
Базовая схема PKI.
Digital Certificate (цифровой сертификат) – файл, который подтверждает что сущность (сервер или сервера) является владельцем определенного публичного ключа. Существуют разные типы сертификатов. Один сертификат может быть выдан на несколько hostname или даже wildcard, что обозначает любой хостнейм в одном домене.
SSL/TLS server certificate – сервер предоставляет клиенту во время начала SSL/TLS коннекта, клиент проверяет доверяет ли он CA и что субъект в сертификате совпадает с hostname к которому он подключается.
SSL/TLS client certificate (и чуть подробней вообще о client certificate) – опциональный компонент SSL/TLS коннекта и встречается реже чем серверный сертификат. Используются для аутентификации клиента на сервере (часто используется для аутентификации в VPN системах, Wi-Fi). Этот сертификат не выпускается public CA (обычно выпускается внутренним CA, например компании, для этого CA компании сначала добавляется в trust store, хранилище сертификатов на клиенте). Для проверки клиентского сертификата (сертификата открытого ключа) используется не схема с электронной подписью (как для серверных сертификатов), а challenge-response механизм (как в U2F) – сервер отсылает challenge клиенту, который клиент шифрует своим private key и отсылает обратно на сервер, тот его дешифрует public key клиента.
Code signing certificate – используются для подписи исполняемых программ, позволяет пользователям программ проверять подпись и убедиться, что программа не изменена/создана производителем (см. MD-5 и Flame Malware Microsoft case).
Сертификат состоит из открытого ключа отправителя, методанных (информация о владельце, времени действия, области применения ) и самое главное – электронной подписи от Certification Authority (CA), который сначала сам, используя Registration Authority (RA) (обычно CA и RA один сервер), проверяет принадлежность ключа владельцу (например, то что домен weril.me находится на том же веб-сервере, с которого идет запрос на сертификат), а потом, проверив, подтверждает принадлежность публичного ключа для других с помощью своей электронной подписи в сертификате. По сути сертификат устанавливает соответствие публичного ключа и владельца.
Сертификаты хранятся в central repository – это позволяет certificate management system (системе управления сертификатами) безопасно хранить и индексировать ключи, управлять ими (отзывать, выдавать).
Стандарт X.509 (x509 version 3) – представляет из себя сертификат, который включает ваш идентификатор (Subject: fqdn, mail), публичный ключ (Subject Public Key Info) вместе с доп. информацией (срок действия, адрес CRL, etc), который подписан УЦ (CA). Подробнее ниже поиском по “Пример сертификата”. Такой (в виде сертификата)способ передачи публичного ключа:
понимают все современные системы
масштабируется
описывает формат цифровых сертификатов, первично появился в 1988. Текущая версия номер 3 (RFC 2459 от 1999). Так же определяет certification revocation list (CRL) – способ распределения списка сертификатов, которые больше не валидны. CRL представляет собой список (по сути – файл) отозванных сертификатов (serial numbers сертификатов), который распространяется CA.
Пример сертификата, на основе моего сайта.
Version – 3 – версия x.509
Serial number – серийный номер сертификата назначенный CA (позволяет легко управлять им)
Certificate Signature Algorithm – 03 08 … – указывает какой алгоритм используется для шифрования публичного ключа и какой хеширующий алгоритм используется для подписи сертификата
Issuer Name – US Let’s Encrypt Authority X3 – кем выдан сертификат (кем подписан)
Validity – not valid before 08.01.2019, not valid after 08.04.2019 – когда сертификат валиден. Not valid before поле введено т.к. возможен выпуск сертификатов на будущее (заранее), которые не должны быть активны сейчас, а должны быть только в будушем, not valid after – стандартный expiration date.
Subject – weril.me – кому выдан сертификат
Subject Public Key Info – E8 43.., RSA – включает публичный ключ, алгоритм шифрования публичного ключа
Signature – 94 AE.. – подпись (по сути ID) сертификата от CA, используется для проверки сертификата
Certificate Signature Value – подпись CA
Certificate Fingerprint – не включается в сертификат, это значения, рассчитанные на клиенте при проверке сертификата (hash от сертификата)
CERTIFICATION AUTHORITY (ЦЕНТР СЕРТИФИКАЦИИ)
Электронная подпись открытого ключа делается Certification Authority. Certification Authority (Центр Сертификации, Удостоверяющий Центр) – заведомо доверенная организация. Мы, доверяя центру сертификации, устанавливаем сертификат открытого ключа получателя и начинаем с ним обмен. Валидация центра сертификации происходит по электронной подписи CA в сертификате открытого ключа. Аутентичность подписи сертификата проверяется с помощью открытого ключа CA, которой заранее (до обмена, чаще всего идет с дистрибутивом OS, причем они могут обновляться, а браузеры чаще всего используют сертификаты системы) есть в системе всех участников. Подробнее о калькуляции и работе с цифровой подписью ниже. Примером CA в мире WEB является просто крутейший Let’s Encrypt, который позволяет автоматизировать процесс получения сертификата SSL для сайта (здоровья тебе, let’s encrypt).
Корневой CA может (и делает, в случае WEB) делегировать полномочия по подписи нижестоящим CA (устанавливает в сертификате поле CA=true, что делает выданный сертификат intermediary/subordinate CA их может быть несколько по дереву) – он подписывает своим private ключем публичный ключ нижестоящему CA в виде сертификата, а тот может подписать своим клиентам (intermediary CA или end-entity/leaf certificate – сертификат без права CA, права выдачи сертификатов). Это “поведение” называется anchor of a trust в PKI. При этом широкоизвестный ключ нужно иметь только корневому CA, но честными должны быть все члены цепочки. Корневые сертификаты являются self-signed (самоподписанными), такой сертификат можно сделать и самому – например, сайт без доступа в интернет даже для возможности получения сертификата (по сути это подписание своего public ключа с помощью private ключа). Такой сертификат не будет считаться валидным до тех пор, пока ты не согласишься доверять этому сертификату (в случае корневых CA – по умолчанию).
Пример списка установленных корневых сертификатов в операционную систему.
Секретные ключи время от времени раскрываются, поэтому существует возможность отзыва сертификата у подчиненных.
OCSP – Online Certificate Status Protocol. Протокол проверки валидности сертификатов. Отвечает, в том числе, за CRL.
DIGITAL SIGNATURE (ЦИФРОВАЯ ПОДПИСЬ) или как работает Public Key Signature
Кратко
Цифровая подпись – это зашифрованный приватным ключем хеш от данных (напр. публичного ключа). Клиент такую подпись может легко проверить имея публичный ключ + сами данные.
К данным применяется hash алгоритм
Цифровая подпись расшифровывается на основе публичного ключа
Значения полученные на предыдущих шагах сравниваются, в случае валидной подписи и данных – будут совпадать
Подробнее
CA, при выдаче сертификата, применяет hash функцию со своим private ключем к данными сертификата (публичный ключ + методанные), который он выдает. Результатом является цифровая/электронная подпись в виде зашифрованного hash. По сути, тут обратный процесс от описанного Базового алгоритма работы ассиметричного шифрования:
формируется цифровая подпись сертификата у CA: данные, в нашем случае все данные (публичный ключ отправителя + методанные), шифруются private ключем на стороне CA, с применением HASH функции (SHA1, MD5) + алгоритма шифрования (если говорить последовательно – сначала берется hash, потом он шифруется)
получатель, используя public ключ CA, расшифровывает цифровую подпись и получает результат HASH функции для данных в сертификате, который рассчитан CA
расшифровав подпись, мы рассчитываем hash от данных (публичный ключ отправителя + методанные) в сертификате, применяя туже hash функцию, что CA
сравниваем значение hash из цифровой подписи, с результатом hash функции от данных в сертификате
если совпадает – все ок, если нет – подделка сертификата или данных
Все это прекрасно расписано в wiki (тут есть и вполне понятное формальное описание) и stackoverflow.
У внимательного человека появляется вопрос, почему то, что зашифровано private key, расшифруется public key. Ведь по идее то что зашифровано публичным ключем расшифруется приватным (как в базовом алгоритме работы).
Но ответ простой – это не ошибка и не симметричное шифрование. Так оно работает – то, что зашифровано публичным ключем, может быть расшифрованное приватным И НАОБОРОТ – то, что зашифровано приватным, может быть расшифровано публичным.
Web of Trust
Web of Trust является альтернативой системы PKI. Сами конечные люди (end-entity/leaf certificate в терминологии PKI) выдают сертификаты другим людям. Верификация identity при этом идет с помощью согласованного механизм (например, с помощью традиционных методов – паспорт, права, etc). После проверки ты подписываешь сертификат другого человека и ручаешься за него (схеме по сути аналогична PKI). Причем процесс обычно двунаправленный – оба партнера подтверждают ключи друг друга. В результате организуется Key Signing Parties (посиделка людей с подписанными друг дружкой ключами ;)). Причем как и в PKI, мы доверяем сертификатам, которым доверяют те, которым мы уже доверились (кого мы идентифицировали).
Message Authentication Codes (MACs)
Существуют разные коды с разной реализацией
HMAC – keyed-Hash Message Authentication Code. По сути это hashing with key (data + key на входе в hash функцию).
Хеш позволяет убедится в том, что данные те, что нужно (integrity)
а authentication позволяет убедится в том, что они пришли от проверенного источника и не подменены
Информация, которая позволяет аутентифицировать отправителя сообщения (authenticity) и проверить отсутствие модификации сообщения (data integrity). По сути это функциональный аналог public key signature. MAC отправляется вместе с сообщением.
В HMAC MAC генерируется на основе двух вещей:
Ключ – в технической реализации MAC отличается – в отличии от ассиметричного способа валидации public key, один ключ используется для шифрования и дешифрования MAC – т.е. используется симметричное шифрование.
Криптографическая hash-функция (SHA-1, MD-5). От него во многом зависит безопасность полученного MAC.
При приеме принимающая сторона вычисляет MAC на основе данных в сообщении и ключа сам и сравнивает с MAC в сообщении и по аналогии с public key signature: “если совпадает – все ок, если нет – подделка сертификата или данных”.
CMAC – Cipher-basedMessage Authentication Code. MAC на основе блочных/поточных симметричных шифров (AES/DES). Процесс очень похож на CMAC, просто вместо hash функции для генерации проверяемой на получении последовательности MAC используется шифр.
CBC-MAC – Cipher Block Chaining Message Authentication Code. Для генерации проверяемой на получении последовательности MAC используется блочный шифр, который работает в CBC режиме. CBC режим подразумевает включение предыдущего зашифрованного блока текста в следующий блок незашифрованного текста. В результате создается цепочка (Chain) зашифрованных блоков, которые требуют полной немодифицированной цепочки для расшифрования. Эта цель взаимосвязанно зашифрованных блоков подразумевает что любая модификация текста приведет к изменению вывода в конце цепочки, нарушив в результате целостность данных.
Примеры популярных ассимметричных алгоритмов
RSA – одна из первых ассиметричных криптографических систем. Название в честь создателей – Ron Rivest, Adi Shamir, Leonard Adleman. Запатентована в 1983, стало публичной в 2000. RSA система определяет как механизм генерации и обмена ключами, так и механизм шифрования и дешифрования этими ключами. RSA основан на серьезной математической базе. Генерация ключей зависит от выбора двух уникальных, обычно очень крупных числа.
DSA (Digital Signature Algorithm) – другой пример ассиметричной криптосистемы. Используется для подписания и проверки данных. Запатентован в 1991, является частью правительственного стандарта USA. Подобно RSA, DSA описывает процесс генерации ключей с подписью и проверку данных с использованием ключевых пар. Безопасность этой системы зависит от рандомного исходного значения, которое используется для подписания. Если об этом рандомном значении стало известно или его можно как-то вычислить/угадать (например, т.к. число, которое используется как значение, не является по настоящему random) – тогда у атакующего есть возможность выяснить private key. Это и произошло в 2010 у Sony с их PS3. Выяснилось, что они не обеспечили рандом этого значения для каждой подписи. Это позволило хакерам failOverflow восстановить private key, который Sony использовала для подписи софта в своей платформе. В результате стало возможно писать/подписывать и запускать софт на Sony, который она запустит, несмотря на то, что софт не из платформы. Это привело к пиратству игр в платформе Sony.
Diffie-Hellman
Diffie-Hellman (DH) – алгоритм безопасного обмена ключами. Предназначен изначально только для обмена ключами, не для шифрования данных (хотя для этого так же пытался использоваться). DH решает ту же задачу, что и ассиметричное шифрование, когда оно используется для обмена shared-key, который в последующем будет использоваться в симметричном алгоритме шифрования. Используется в PKI системе (Public Key Infrastructure System).
Пример работы DH (По описанию похож на симметричное шифрование):
Стороны обмены согласуют стартовое число (shared number). Оно должно быть рандомное, очень большое и отличаться для каждой сессии. Подразумевается небезопасным (т.е. от безопасности этого элемента не зависит система).
Каждая сторона выбирает еще одно крупное рандомное число, но это число уже хранится в тайне (secret number).
Каждая сторона складывает shared number со своим secret number, в результате получая общее число (combined number)
Стороны обмениваются результатом сложения между собой.
Далее стороны складывают полученные данные (combined number соседа) со своим secret number.
Результатом является shared number + secret numbet соседа + secret number свой. И это значение одинаково на обеих сторонах. При этом secret number обеих сторон остаются неизвестными (ну относительно неизвестными, т.к. операция вычитания из combined number потенциально украденного shared number приведет к получению secret number одной из сторон).
ECDH, ECDSA– вариации Diffie-Hellmen (DH) и Digital Signature Algorithm (DSA), которые работают с элиптическими кривыми
Elliptic curve cryptography (ECC, элиптическая криптография) – криптографическая система с открытым ключем, которая использует алгебраическую структуру эллиптических кривых над конечными полями для генерации безопасных ключей.
В отличии от традиционных систем с открытым ключем (RSA), которые используют факторизацию (разложение на множители) больших целых чисел, как сложность для инверсии public-private key системы на базе эллиптической криптографии используют дискретное логарифмирование.
Эллиптическая кривая состоит из набора координат, которые входят в алгебраическое уравнение. Такая кривая имеет несколько интересных и уникальных свойств:
Горизонтальная симметрия (кривая вверх от х равна отраженной кривой вниз от х)
Любая не-вертикальная линия пересечет кривую максимум в трех местах – именно это свойство используется в шифровании
Польза эллиптических кривых состоит в том, что они способны достигать такого же уровня безопасности, как традиционные системы с открытым ключем, при этом используя меньший размером ключ. Например, 256 битный elliptic curve key сопоставим с 3,072 битным RSA ключем. Это позволяет сильно сэкономить количество данных, которое нужно для хранения и передачи, при работе с ключами. Элиптические кривые с ключем 384 bit EC можно использовать для шифрования top secret данных в USA. Но так же в USA озабочены потенциальной уязвимостью EC к атакам на базе квантовых вычислений (однако тоже самое выше и про факторизацию числа, см. поиском factorization).
При этом производительность (на примере решения F5 Viprion) с элиптическим шифрованием пока значительно ниже “классического”.
Hashing
Hashing или hash function – тип функции, которая принимает набор данных произвольной длины на входе и выводит фиксированный набор данных (hash/digest) на выходе. Это константа. Криптографические hash функции похожи на симметричные блочные шифры т.к. работают с блоками данных (и даже больше – многие hash функции основаны на модифицированных блочных шифрах).
Идеальная hash функция
на разный набор входных данных производит всегда разный результат, т.е. hash от входящих данных уникален => нет вероятности коллизии, когда от разных данных будет одинhash (привет, DES-3028 и Broadcom)
криптографическое хеширование и hash’и похожи тем, что из понятного текста появляется какая-то хрень, но hash сильно отличается от шифрования тем, что hash функция должна быть однонаправленной – не должно быть возможно из результата hash получить исходный текст (one-way function).
один и тот же входящий набор данных всегда должен приводить к одному hash как результату
малое изменение во входных данных не должно содержать взаимосвязь в изменении соответствующих hash (не должно быть видно по hash, что это почти одни и те же данные, иначе можно поэтапно, понимая что движешься в нужном направлении, подбирать данные по результату hash)
функция должна быть быстрой
Hash используются во многих местах, например:
в криптографии для
уникальной идентификации данных. К примеру,
сохранение паролей пользователей в виде hash в базе/файле like .htdigusers. Причем пароль может прогоняться через hash функцию несколько раз, в некоторых случаях с тысячами итераций.
проверка на то, что файл не модифицирован (напр. совпадение hash для ISO образа ОС)
проверки целостности
цифровых сертификатах
Hash таблицы используются для ускорения lookup в таблице
для идентификации (для удаления, просто обнаружения, etc) дублирующихся данных
в оборудовании (например, сетевом), для экономии памяти
Так как применение абсолютно разное, существует огромное количество разных hash функций, в том числе “самописных” (привет еще раз DES-3028 и Broadcom).
rainbow tables (радужные таблицы) – используются хакерами для ускорения процесса восстановления паролей из украденных hash. Такая таблица представляет собой просто предрасчитанную таблицу из password – hash. С ней достаточно сделать lookup в таблице по hash, чтобы найти пароль, не рассчитывая пароль самому, как в случае с brute force.
Такие таблицы есть в интернете для популярных паролей и хеш-функций.
Защитой от таких таблиц является соль (salt) – дополнительные рандомные данные, которые добавляются к паролю перед применением к нему hash функции. В результате, в таблице, на основе которой происходит аутентификация, сохраняется и hash и salt. Поэтому общие таблицы из интернета тут не подойдут и нужно расчитывать пароль на основе hash самому, что сложно, особенно если соль большая по длине. Но и этим занимаются – например популярный в свое время http://gpuhash.me, который активно использовался для взлома Wi-Fi предлагал и предлагает даже бесплатные проверки на основе перехваченного вами handshake. Ранние UNIX системы использовали под разрядности соли 12 бит, что составляет 4096 возможных комбинаций соли. Получается для каждого пароля и соли в базе нужно генерировать hash для всех 4096 возможных salt. В новых системах типо Linux/BSD используется 128 бит под соль. Это бесконечность вариантов (340 + 36 нулей) и rainbow таблицы бесполезны тут.
Примеры hash функций
MD-5 – крайне популярная криптографическая hash функция. Разработана еще в далеком 1992. Она работает на блоки из 512 бит и генерирует 128-битный hash digest. Серьезные проблемы в MD-5 обнаружены уже в 1996, что привело к рекомендациям использования в качестве замены SHA-1. В 2004 обнаружено, что MD-5 подвержен коллизиям HASH, что позволяет хакеру создать зараженный файл, который будет иметь такой же MD-5 digest, что и настоящий файл. В 2008 так же смогли создать и fake SSL сертификат, с таким же MD-5 hash, что настоящий. С 2010 рекомендовано не использовать MD-5 в криптографических приложениях. В 2012 эта коллизионность была использована в Flame malware, что привело к тому, что вредоносное ПО было подписано сертификатом от Microsoft и система думала, что это софт Microsoft. Сам Flame вирус долгое время считался “произведением искусства” – он распространялся по сети, записывал аудио, клавиатурную активность, делал скриншоты и делал попытки скачивания контактной информации с блютус устройств, которые располагались рядом с зараженным компьютером.
SHA-1 (Secure Hash Algorithm) – набор функций для генерации hash. Создано мин. обороной США, NSA (National Security Agency). SHA-1 заменил MD-5 hash функцию. Является более безопасным в сравнении с MD-5. Но признан устаревшим с 2010 года. Современные браузеры не используют с 2017 года и пометят сайт с sha-1 подписью в сертификате небезопасным. SHA-1 работает на блоки из 512 бит и генерирует 160-битный hash digest. Используется в TLS/SSL , PGP SSH, IPSec, GIT/SVN VCS (для определения ревизий и обеспечения целостности данных). Имеет уязвимости (обнаружены в том числе Винсентом Рейменом, создателем AES), хотя и полную коллизию можно получить только с использованием больших вычислений с CPU (первоначально 2.7кк$), но при изменении способа атаки и добавлении GPU, что выяснилось в последствии, результат можно получить уже за 100-100к$ ресурсов cloud cpu+gpu. В 2017 получена первая коллизия на базе двух разных PDF при использовании CPU+GPU, на это потребовалось огромные вычислительные ресурсы – примерный эквивалент в 6500 лет одного CPU + 110 лет одного GPU.
SHA-2/SHA-3/SHA-256 – наследники SHA-1. Рекомендуются (особенно SHA-3/SHA-256) к использованию вместо SHA-1 с 2010 года.
MD5SUM, SHASUM В первой части, используя MD5SUM/SHASUM рассчитываем hash для входных данных, а так же проверяем корректность рассчитанного hash. Во второй части, сначала копируем содержимое предыдущего файла в файл с новым именем, видим, что hash для нового файла не отличается от hash предыдущего – hash берется от содержимого, а не от методанных (напр. имени). Далее, добавив пробел в исходный текст, мы проверяем, что hash меняется и проверка относительно старого hash не проходит. Видим, что hash меняется кардинально, даже из-за изменения/добавления одного символа.
Все тоже самое справедливо для SHA. По умолчанию генерируется SHA-1 hash, поведение можно изменить задав алгоритм через опцию -a (-a 256 для SHA-256).
MIC (Message Integrity Check) – hash/digest от сообщения. По сути checksum для сообщения, который обеспечивает только целостность данных (аналог CRC) и при этом не предоставляет никакой защиты. Не путать с MAC (как с MAC address, так и с Message Authentication Check). В отличии от MAC, MIC не использует секретные ключи (т.е. не требует аутентификации) -> MIC не может никак защитить от того, атакующий изменит сообщение, пересчитает checksum и модифицирует MIC для сообщения.
Applications
HTTPS – HTTP over SSL (old, 3.0 deprecated from 2015)/TLS (secure from 1.2). TLS инкапсулирует данные HTTP для их защиты, аутентификации (обычно только сервера) и проверки целостности.
TLS – Transport Layer Security. Используется не только для защиты/аутентификации в HTTP (HTTPS), но и во многих других местах – VoIP звонки, такие как Skype или Google Hangouts, API, SSL/TLS VPN, email, instant messaging, Wi-Fi network security. Использует как asymmetric encryption (ключи), так и symmetric (данные).
Быстрее за счет меньшего количества пакетов, которыми нужно обменяться для handshake
Performance has a major impact on user experience. TLS 1.3 represents a pivotal turning point for HTTPS performance.
Modern mobile networks will routinely add over 100ms of latency to each request. TLS 1.3 makes page load times significantly faster for mobile devices, improving the user experience for your visitors.
Utilizing Cloudflare’s global content delivery decreases the physical distance between your content and your visitors resulting in shorter physical round trip connection times (latency). The combination of reduced round trip connections and shorter distance results in enormous performance gains when establishing a secure connection.
Безопаснее за счет
удаления старых протоколов и подходов, которые делали протокол уязвимым к ряду атак
добавления новых протоколов и подходов, которые призваны сделать протокол более безопасным
Data integrity is critical to your entire community. TLS 1.3 represents a significant leap forward for security. TLS 1.3 removes all primitives and features that have contribute to a weak configurations and enabled common vulnerability exploits like DROWN, Vaudenay, Lucky 13, POODLE, SLOTH, CRIME and more. TLS 1.3 has also introduced more improvements than any previous version of the protocol. Additional features have been added to enhance the security and robustness of the protocol.
TLS предоставляет три вещи:
Безопасный канал связи (encryption) – передаваемые по каналу данные защищены от подслушивания
Аутентификация (authentication) – возможность аутентификации одной (1-way/simple) и/или обеих сторон (2-way/mutual) во взаимодействии используя сертификаты (часто) или пароль (крайне редко)
1-way/simple обычно при использовании SSL/TLS только сервер аутентифицируется клиентом.
2-way/mutual в некоторых случаях помимо проверки сертификата сервера клиентом, аналогичную проверку может делать сервер по отношению к клиенту (проверка сертификата клиента)
TLS-SRP (Secure Remote Password) – аутентификация клиента сервером путем запроса пароля (не проверки сертификата), не используется сейчас почти нигде
Целостность сообщений(integrity) – есть проверка на то, что данные не потерялись и не изменены при передаче
Для организации безопасного канала связи используется TLS handshake – (пример однонаправленной проверки, только сервера):
клиент устанавливает соединение по TCP (TCP handshake),
отсылает TLS Client Hello (client info: максимальная поддерживаемая версия TLS, список поддерживаемых шифров, опции),
далее происходит отправка сервером TLS Server Hello сертификата+шифров+hello (server info: максимальная версия TLS на основе версии клиента и поддерживаемой сервером, выбранные список шифров, цифровой сертификат),
проверка сертификата на клиенте выбор метода обмена ключами (для последующего согласования shared secret в виде session key, который будет использоваться с symmetric encryption cipher для шифрования последующих данных)
ChangeCipherSpec сигнализирует начало обмена с применением шифрования (смена с незащищенного на защищенное)
обмен данными
Session key получается из public-private key и в случае компрометации private key у атакующего есть возможность декодировать все предыдущие сообщения, связанные этим private key. Для защиты от этого есть концепция forward secrecy, это свойство криптографической системы, который обеспечивает защиту session key в условиях компрометации private key.
Heartbleed – бага в OpenSSL библиотеке (реализует TLS) состоящая в обработке TLS сообщений hearbeat (сообщение одной стороны, что оно хочет сохранять сессию живой). heartbleed – пример уязвимости, которая находится прямо в ядре софта. Просто отключить такой софт до патча не получится т.к. он мега критичный. Одним из вариантов, до патча, был пересбор (перекомпиляция) OpenSSL с флагом, отключающим hearbeat сообщения.
Атака подразумевает отправку TLS hearbeat request и 1) аллоцирование на получающей стороне памяти под каждый такой request – это так и должно быть 2) использовании баги реализации обработки hearbeat сообщений в OpenSSL – он аллоцировал память (потом это исправили патчем) на основе значения в поле lenght, не на основе фактических данных. При такой аллокации (п2) уязвимые версии OpenSSL могли выдавать любую информацию (равную длине, запрашиваемой в поддельном heartbeat сообщении, которые называют heartbleed сообщениями) за пределами отведенного буфера – включая закрытые ключи/куки/данные других соединений и проч
Пример установления реального TLS соединения с данным сайтом weril.me при использовании TLS 1.2.
$ openssl s_client -connect weril.me:443 -tls1_2 CONNECTED(00000005) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = weril.me verify return:1 --- Certificate chain 0 s:/CN=weril.me i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- ......cert..... -----END CERTIFICATE----- subject=/CN=weril.me issuer=/C=US/O=Let's Encrypt/CN=R3 --- No client certificate CA names sent Server Temp Key: ECDH, X25519, 253 bits --- SSL handshake has read 3094 bytes and written 285 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-CHACHA20-POLY1305 Session-ID: 029032CEE7FD53C3CDB33617835C93771E73025890D21C0E226FA2828A3DBEA4 Session-ID-ctx: Master-Key: 1CD8D38AAAAC963BEF6A79EB75B242181439163DE964AE8951BB4F77B0975B26E28FDA99D3CD5ECD3112B97232D12DFD TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 5b 65 8d b9 6e b3 2f fe-f8 fa 17 1e 75 82 60 9a [e..n./.....u.`. 0010 - f9 0d 90 d5 c9 57 d6 49-df e6 1c 15 04 e8 cf c8 .....W.I........ 0020 - 3f b8 a4 a0 56 60 5b af-64 2a 46 cb ea 3f 64 b9 ?...V`[.d*F..?d. 0030 - 28 f0 e6 7b 8b 38 ac 55-95 1f b6 86 80 a9 bc a9 (..{.8.U........ 0040 - 36 7d 5c db 93 91 bf 5b-ed c7 d1 06 0f 6b ca e9 6}\....[.....k.. 0050 - 61 9d 66 c4 76 3d 56 8f-f1 fa d7 e7 58 1f 03 0b a.f.v=V.....X... 0060 - 99 eb 24 b8 7e 78 bb 63-1d 44 61 10 2a 60 5b 16 ..$.~x.c.Da.*`[. 0070 - 5c ad 5d 5c d8 60 38 59-f2 13 65 f5 24 f5 6d ca \.]\.`8Y..e.$.m. 0080 - 78 f6 8c e9 86 dd 55 34-c1 f8 a4 9e 9b 2f 2f 6b x.....U4.....//k 0090 - 43 33 61 30 17 2c 75 47-d9 49 0b d5 f6 64 76 82 C3a0.,uG.I...dv. 00a0 - 27 3c 6a e8 e5 2c ad d4-b6 00 2f e1 17 9c 1f db '<j..,..../..... 00b0 - 75 e8 7d 74 93 18 e0 76-95 0d 53 d8 d3 e4 fd 56 u.}t...v..S....V
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> <hr> <address>Apache/2.4.38 (Debian) Server at weril.me Port 443</address> </body></html> closed
Попытка подключения с TLS 1.1 безуспешна.
$ openssl s_client -connect weril.me:443 -tls1_1 CONNECTED(00000005) write:errno=54 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Start Time: 1619120086 Timeout : 7200 (sec) Verify return code: 0 (ok) ---
Пример успешного подключения по TLS 1.1 к ya.ru.
$ openssl s_client -connect ya.ru:443 -tls1_1 CONNECTED(00000005) depth=3 C = PL, O = Unizeto Sp. z o.o., CN = Certum CA verify return:1 depth=2 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA verify return:1 depth=1 C = RU, O = Yandex LLC, OU = Yandex Certification Authority, CN = Yandex CA verify return:1 depth=0 C = RU, L = Moscow, OU = ITO, O = Yandex LLC, CN = *.yandex.az verify return:1 r --- Certificate chain 0 s:/C=RU/L=Moscow/OU=ITO/O=Yandex LLC/CN=*.yandex.az i:/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA 1 s:/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA i:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA 2 s:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA i:/C=PL/O=Unizeto Sp. z o.o./CN=Certum CA --- Server certificate -----BEGIN CERTIFICATE----- ......cert..... -----END CERTIFICATE----- subject=/C=RU/L=Moscow/OU=ITO/O=Yandex LLC/CN=*.yandex.az issuer=/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA --- No client certificate CA names sent Server Temp Key: ECDH, X25519, 253 bits --- SSL handshake has read 5352 bytes and written 239 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : ECDHE-RSA-AES128-SHA Session-ID: B554589EA58D3797C47A1E1F770312674833D7A03C558DEDC0D6EB5D24116E03 Session-ID-ctx: Master-Key: FECED800BB7BE9A90016DB206D3DCF8FB76026C0A2B329491C8426AACC3030B044E150FF597FB553595796CDCA14FC7D TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - 2c 4d ae b5 f3 0d 94 86-dc 46 85 ee 73 ea ad fc ,M.......F..s... 0010 - 63 0e 62 d4 cc 21 01 0b-13 ec ef a1 6a 84 2c 8f c.b..!......j.,. 0020 - cc 87 a8 86 9d a5 cc e0-27 12 5f a2 26 22 39 75 ........'._.&"9u 0030 - 46 59 1d 57 88 e5 ef 8b-f1 2e 25 a3 b8 86 54 e9 FY.W......%...T. 0040 - 6a ec f1 e4 aa 69 5d 16-36 68 1f a5 91 d7 e6 51 j....i].6h.....Q 0050 - 6c 9d bc 8e 24 33 70 70-e3 c0 26 54 9d 3e 63 00 l...$3pp..&T.>c. 0060 - 7d 39 b1 4d 5d 59 2e d2-81 d8 c9 69 71 55 c9 23 }9.M]Y.....iqU.# 0070 - 40 ac 14 3d 56 b0 b2 45-40 2c e1 8d 38 0d 73 70 @..=V..E@,..8.sp 0080 - d8 8a fd 2b 11 91 92 0d-0b 97 76 79 c8 e5 af 0a ...+......vy.... 0090 - 15 52 94 b1 1a 56 14 59-41 23 92 b9 e6 33 ef 8c .R...V.YA#...3..
Secure Shell (SSH) – безопасный сетевой протокол, который использует шифрование для предоставление доступа к сетевому ресурсу по небезопасной сети. Является гибким и модульным – поддерживает различные алгоритмы обмена ключами (DH), различные симметричные протоколы шифрования данных, различные методы аутентификации (включая даже кастомные).
Изначально задуман как замена небезопасным telnet/rlogin/r-exec, поэтому чаще всего используется для безопасного доступа к командной строке (remote login to command-line based systems). Но может использоваться и для других вещей, включая, например, туннелирование/проксирование трафика через SSH.
В общем случае SSH использует public key cryptography для аутентификации удаленной машины, к которой подключается клиент.
Кроме того, SSH опционально поддерживает и клиентскую аутентификацию через client certificates (двухстронняя проверка). В таком случае Пользователь генерирует ключевую пару public key/private key, public ключ затем передается на те системы, на которые пользователь хочет подключиться. В последующем сервер при авторизации проверяет private ключ пользователя (который находится только у пользователя) по его открытому ключу (который хранится на сервере).
Pretty Good Privacy (PGP) – приложение по ассиметричному шифрованию, которое позволяет аутентифицировать данные, обеспечивать приватность от третих лиц.
Разработан PGP Phil Zimmerman в 1991, и распространялось (soft + source code) бесплатно, несмотря на требования об экспорте усиленного шифрования (key larger then 40 bits, в то время как в PGP минимальным размером ключа было 128 бит) от регулятора в USA. Зиммерман обошел это требование опубликовав source code в виде книги (воспользовался первой поправкой к конституции).
Несмотря на свою относительную старость PGP считается безопасным приложением – явные уязвимости до сих пор не найдены, хотя многие (в том числе ведущие криптографы) рекомендуют отказаться от него. Он сопоставим с военным шифрованием. Существует огромное количество кейсов, когда полиция и правительство не могло получить доступ к данным, зашифрованным PGP. PGP полагается на ассиметричное шифрование. Чаще всего используется для encrypted email communications, но так же может шифровать данные в системе – файлы, папки или даже весь диск.
PGP первоначально использовал RSA алгоритм, но потом, во избежание проблем с лицензированием, стал использовать DSA.
VPN
VPN (Virtual Private Network) – механизм, который позволяет хосту (remote access VPN) или сети (site-to-site VPN) удаленно подключится к частной сети, для передачи данных по публичному каналу, такому как Internet. Своего рода зашифрованный туннель. Существует огромное количество VPN решений, каждое со своими плюсами и минусами. Под VPN обычно используется отдельная сеть/vlan и возможно отдельные правила мониторинга/ограничения безопасности этой сети – это менее безопасная среда (дополнительная потенциальный вектор атаки), чем обычная корпоративная LAN. Изначально VPN решения развивались для замены leased lines – отдельный физических каналов между объектами, но сейчас он используется не только для задачи site-to-site.
Существует огромное количество протоколов, реализующих VPN, самые популярные:
PPTP – разработка Cisco, использовал MPPE протокол на базе deprecated шифрования RC4
L2F – разработка Cisco, не обеспечивает шифрование
L2TP – не обеспечивает шифрование
GRE – используется site-to-site, не обеспечивает шифрование
MPLS VPNs – используется site-to-site, не обеспечивает шифрование
IPSec – используется site-to-site и remote-access (реже), крайне популярен сейчас; обеспечивает шифрование
SSL/TLS – remote-access, крайне популярен сейчас; обеспечивает шифрование
Базовая настройка IPsec и GRE есть уже даже в CCNA R&S (enterprise)
IPSec используется OSPF/EIGRP для IPv6 в качестве замены md5
IPSec использует поточные алгоритмы шифрования
IPSec очень широко используется в enterprise, ISP, mobile решениях
Уязвим IPsec только IPSec IKEv1 в Aggressive Mode (поэтому лучше использовать MAIN Mode), уязвимость состоит в том, что существует возможность подбора PSK ключа при перехвате трафика Phase 1 посредством инструментов IKE-scan, PSK-crack, Cain и таким образом можно получить доступ к туннелю. В случае действительной необходимости использования Aggressive Mode рекомендуется использовать сертификаты, дополнительную аутентификацию XAUTH.
IPSec нативно не поддерживает NAT – AH и ESP L3 протоколы (инкапсулируются напрямую в IP) без L4-портовой информации в нативном исполнении:
Для NAT есть разные костыли у роутеров (IPSec/VPN passthrough), которые идентифицируют IPSec в проходящих пакетах (на основе значений SPI) и делают на его основе трансляцию через NAT (иногда даже успешно, например, на Cisco ASA такая функция есть). В итоге не требуется использовать версии протоколов ESP/AH, работающие через IPSec (UDP 500, UDP 4500) и “платить” за дополнительный оверхед.
Так же для работы через NAT: для management session IKE v1/v2 (ISAKMP SA) при шифровании IPSec на основе ESP (не AH, AH не поддерживает NAT-T) есть версия IPSec (она чаще всего на практике и используется) в которой IKE сообщения вкладываются в UDP 500 (так же бывают реализации на базе TCP 500).
Так же для работы через NAT: для data session ESP (IPSec SA) есть версия IPSec NAT-T в которой ESP сообщения вкладываются в UDP 4500.
Wireshark может расшифровать зашифрованные данные, если дать ему нужную ключевую информацию (например, дав ему пароль от Wi-Fi для WEP/WPA сети, IPsec, SSL/TLS-сессии).
IPSec (сокращение от Internet Protocol Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет. В основном, применяется для организации vpn-соединений (как site-to-site, так и remote-access).
В оригинале IPv6 требовал обязательной поддержки IPsec для полного соответствия требованиям IPv6 (поэтому многие CPE роутеры были только IPv6 ready), в последующем это требование убрали из обязательных.
IPsec работает путем шифрования и инкапсуляции оригинального IP пакета в пакет IPsec.
Использование IPSec в продуктах Cisco
Traditional site-to-site (crypto-maps static/dynamic based)
static – на пирах настраивается статически адресация второй стороны
dynamic – на одной из сторон не требуется адресация второй стороны (hub-spoke, BRAS)
EZ VPN – legacy продукт Cisco, клиенты были hardware железками, подключающимися к site (remote access), полагался в своей работе на crypto-maps
Get VPN – Group Encrypted Transport VPN. MPLS + PKI.
Flex VPN – for site-to-site IKEv2
IPSEC framework
Подробно про вариации используемых протоколов можно почитать тут.
Internet Key Exchange (IKE) – это основа IPSec, именно IKE обеспечивает согласование протоколов и безопасный обмен ключами. IKE базируется на ISAKMP. Бывает первой и второй версии – IKEv1 (RFC 2409), IKEv2 (RFC 5996). В IKEv1 эта сессия может быть установлена в двух режимах – main и aggressive. Подробнее о версиях можно прочитать ниже в “IKEv1 & IKEv2”
Authentication Header (AH) – L3 протокол, обеспечивает целостность передаваемых данных, аутентификацию источника информации и replay protection.
Encapsulating Security Payload (ESP) – L3 протокол, обеспечивает шифрование, целостность передаваемых данных, аутентификацию источника информации и repay protection. ESP так же как и AH имеет разную последовательность инкапсуляции своего заголовка, в зависимости от типа IPsec.
DES, 3DES, AES – шифрование данных
MD5, SHA – проверка целостности на основе хэша (подробнее в хешировании). IPSec использует как MD5 хэш-алгоритм (128 бит на выходе), так и SHA-1 (160 бит на выходе), а для того чтобы не делать два разных формата пакета для каждого хэш-алгоритма используются только последние 96 бит полученного алгоритмом хэша.
Diffie-Hellman (DH) – алгоритм обмена ключами (подробнее в шифровании > несимметричные алгоритмы).
Независимо от использования AH/ESP IPsec может использовать два разных режима шифрования:
Туннельный (tunnel mode) – шифруется и payload и IP header, IP packet весь инкапсулируется в новый IP пакет. Режим по умолчанию в большинстве реализаций IPsec Cisco. Часто используется для защиты хостов, которые находятся за VPN.
Tunnel mode - protects the entire IP packet.
Транспортный (transport mode; используется, например, в Windows или в GRE over IPSEC) – шифруется только payload оригинального пакета, IP header сохраняется оригинальный, но используется authentication header, который включает hash от данных IP пакета (включая header IP, transport, application data). Это защищает от подмены данных (включая NAT/PAT), включая данные не зашифрованного IP header. Типичное применение Transport mode – GRE over IPsec.
Transport mode - protects upper layer protocols, such as UDP and TCP.
IKEv1 & IKEv2
Отличия IKEv2 от IKEv1. Если вкратце – IKEv2 лучше и проще, поддерживает из коробки RA VPN (remote access), NAT, DPD, DoS protection.
улучшение/упрощение функции обмена ключами и аутентификации
исправление уязвимостей в IKEv1
поддержка самых новых протоколов шифрования
встроенные возможности anti-DoS
IKEv2 поддерживает использование EAP (Extensible Authentication Protocol), например, для использования IPSec на базе IKEv2 для задачи remote access VPN
IKEv2 и IKEv1 несовместимы
Установка защищенного соединения IPsec независимо от версии IKE (IKEv1, IKEv2) происходит два этапа – фаза I и фаза II. За две ключевые фазы установки IPSEC туннеля/сессии отвечает Internet Key Exchange (IKE) протокол. Пример разбора работы фаз ниже и в документации Huawei.
В первой фазе происходит согласование IKE SA (Security Associations), при NAT-T работает на порту UDP 500.
согласование методов шифрования/хеширования/групп DH/аутентификации (proposal-choice; 1-2 на слайде ниже)
генерация и обмен ключевой информацией по алгоритму Diffie-Hellman для формирования SKEYID (строка, полученная на основе secret material) – клиенты аутентифицируют друг друга по PSK ключу без передачи непосредственно ключей PSK, а nonce к которому применяется PSK и сравнивается между сторонами; 3-4 на слайде ниже
передается информация о ID устройств и проверяется на противоположных сторонах в зашифрованном виде (ключи шифрования сформированы на основе SKEYID), защищенное соединение для установки второй фазы установлено (5-6 на слайде ниже)
IKEv1 only: Фаза может происходить либо в Main Mode, либо в Aggressive Mode.
Main Mode является более безопасным т.к. в его случае шифруются все сообщения, тогда как в Aggressive Mode не шифруется идентификатор сайта. Обычно используется для site-to-site.
Aggressive mode используется в случае если на VPN концентраторе не прописываются в явном виде IP адреса удаленных точек (т.е. используется адрес по типу 0.0.0.0 разрешающий все соединения) или на удаленных адресах есть NAT трансляция.
Во второй фазе происходитсогласование IPSec (IKEv1) или Child (IKEv2) SA (Security Associations), при NAT-T работает на порту UDP 4500. Так же фаза известна как “quick mode”, ipsec proposal с использованием transform set. Предыдущая фаза (ISAKMP, IKE ISA) обеспечивает защиту IPSec SA потому что весь payload кроме ISAKMP header шифруется. Одно согласованное IPSec SA всегда включает две security associations – входящее и исходящее. Обеим ассоциациям присваивается уникальное значение SPI (security parameter index). Опционально в этой фазе передается информация о PFS (perfect forward secrecy, подробнее выше) и может дополнительная информация при использовании Child SA (IKEv2).
Опционально может так же быть фаза I.5. в которой может происходить дополнительная аутентификация – например, для задачи решения Remote Access VPN с использованием IKEv1. XAUTH и назначение IP адреса туннельному интерфейсу Mode Config.
GRE over IPSec
Зачем нужны туннели GRE over IPSec: GRE поддерживает передачу мультикастовых (и бродкастовых) сообщений и разных L3 протоколов через GRE туннель, но не поддерживает шифрование. Это поддерживается в силу того, что роутер рассматривает gre-туннельные интерфейсы как подвид Serial. В тоже время IPSEC не поддерживает передачу мультикаста и других протоколов кроме IP. Поэтому использование GRE over IPSEC является нормальной практикой для предприятий – GRE позволяет работать routing протоколам через туннель, а IPSEC позволяет зашифровывать весь трафик GRE, обеспечивая безопасность. Так же в таком сценарии возможен полный отказ от GRE, если использовать BGP. т.к. он работает не используя мультикаст, но это уже другая история.
GRE over IPSec – over означает, что именно GRE инкапсулируется в IPSec, а не наоборот. Таким образом, GRE туннель работает внутри IPSEC.
Основные шаги по настройке GRE over IPSec (static crypto-maps)
Определить tunnel endpoint интерфейс (интерфейс, на который ставится туннель). Чаще всего это loopback роутера.
Создать GRE-туннель (gre tunnel interfaces). Туннельный интерфейс переходит в UP/UP как только будет сконфигурированы tunnel source/destination + будет маршрут в таблице маршрутизации до tunnel destination (сойдет даже default route, tunnel destination не обязательно должен даже пигноваться (GNS)).
3. Добавить туннельную сетку в процесс маршрутизации, чтобы начался обмен маршрутными сообщениями
4. Сконфигрурировать IPSEC и отдать трафик GRE в crypto access-list, для шифрования его посредством IPSEC
CRYPTOMAP GRE over IPSEC туннеля должен иметь три разрешающих ACL: GRE, ISAKMP, ESP
CRYPTO-шифрование GRE over IPSEC туннеля и TUNNEL destination должны ставится на физ. адрес, а не на tunnel адрес соседа
L2TP (Layer 2 Tunneling Protocol) – по сути не VPN решение и не обеспечивает шифрование, но позволяет передать модифицированные пакеты из одной сети в другую инкапсулируя эти пакеты. Чаще всего реализовывается в связке L2TP over IPsec (RFC 3193). Так же может использоваться без VPN – например ISP могут предоставлять доступ в сеть на основе L2TP ;).
У крупных провайдеров, использующих L2TP как основной способ организации связи клиент-BRAS, чаще всего IPSec отключен. т.е. туннель создается, но он не шифруется и промежуточные устройства (DPI/СОРМ/хакеры) могут перехватить и прочитать трафик, если он не зашифрован еще каким-то образом (напр. перехваченный трафик содержит взаимодействие с google по HTTPS).
Работа L2TP over IPsec:
устанавливается IPSec туннель в соответствии с фазами (подробнее в IPSec)
устанавливается L2TP туннель, в результате L2TP пакеты упаковываются в IPsec
SSL/TLS
SSL/TLS так же могут использоваться для создания VPN tunnel. Например, Cisco clientless VPN на базе Cisco ASA.
OpenVPN
Может работать как на базе TCP, так и UDP, обычно на 1194 порту.
Поддерживает разливку конфигурации с сервера клиентам.
Работает от прав пользователя (что хорошо для безопасности).
Может пробрасывать как L3 (Layer 3 IP tunnel), так и L2 (Layer 2 Ethernet tap).
Сервер может разворачиваться в виртуалке как решение
в AWS/Azure/GCP
на вашем гипервизоре ESXi/Hyper-V
как традиционное приложение на сервере Ubuntu/Centos/Rhel
Так же как пример OpenVPN, который использует OpenSSL (практику работы с ней – по генерации private ключа на базе RSA и созданию public ключа на базе private, шифрования/дешифрования данных, генерации hash и его проверке смотри ниже) библиотеку для обмена ключами, шифрования данных. OpenVPN поддерживает шифрование до 256-бит с помощью OpenSSL. Использование OpenSSL так же позволяет OpenVPN выбирать любые шифры, которые реализованы в OpenSSL.
OpenVPN поддерживает разные типы аутентификации (Pre-shared secret PSK, certificate based, username-password). Username-password способ не встроен непосредственно в OpenVPN, а реализуется с помощью модуля. Certificate based считается наиболее безопасной опцией, но требует большей поддержки т.к. у каждого клиента должен быть свой сертификат. Если хочется мега безопасности то можно к certificate-based добавить еще проверку по username-password.
Cryptographic Hardware
TPM (Trusted Platform Module), TAM (Trust Anchor Module), АПМДЗ (Аппаратно-программный модуль доверенной загрузки) – аппаратное устройство, обычно интегрированное аппаратно в компьютер(ную систему). Есть стандарт, описывающий TPM. TPM по сути выступает как выделенный крипто-процессор для системы. TPM имеет свой RSA (или другой) ключ, который зашит в hardware во время производства (это основной недостаток TPM, производитель может знать ключ и прошить его на другое устройство). TPM бывают различных версий, Microsoft со своим решением BitLocker для FDE рекомендует использовать TPM 1.2 и выше для шифрования диска.
Может быть реализован:
как отдельный чип – классическим TPM, наиболее безопасная реализация т.к. в таком случае есть защита от физического взлома в виде tamper protection. Пример реализации – Trusted Anchor module (TAm) Cisco на базе FPGA, который недавно поломали :D. На его основе весь сок железа работает, включая Security Devices типо ASA/Firepower.
интегрирован в другой чип – на мобильных устройствах чаще всего сделано так, встроен в процессор или материнскую плату, несет название secure element
виртуализирован на гипервизоре
реализован в качестве прошики/софта
TPM предоставляют:
Platform integrity – TPM оценивают целостность платформы и предотвращают неавторизованные изменения системы как с точки зрения hardware, так и с точки зрения software (воровство диска, клонирование диска, изменение других hardware)
Hardware authentication (с использованием зашитого RSA ключа) – TPM может обнаружить неавторизованные изменения hardware с системой.
Remote attestation – система аутентифицирует свой софт и аппаратную конфигурацию для удаленной системы (отдает результат, например, в виде hash на основе зашитого ключа RSA), что дает понять удаленной системе целостна ли наша (Playstation, Xbox)
FBE (File Based Encryption) – шифрование конкретных файлов/папок (HOMEDIR) на диске.
FDE (Full Disk Encryption) – TPM часто используется для шифрования всего содержимого диска (не отдельных файлов). Подробнее о TPM отдельно ниже.
Secure generation of keys
Random number generation
Data binding and sealing – использование секретного зашитого ключа RSA для получения уникального ключа, который используется для шифрования данных. По сути это привязывает зашифрованные данные к TPM (к системе на которой находится эта TPM), т. к. только аппаратный ключ сможет дешифровать данные. В случае sealing все аналогично с описанным выше для случая binding, только TPM должен находится в специальном состоянии.
Trusted Execution Environment (TEE) – новая концепция в secure elements. TEE предоставляет полномасштабную изолируемую среду для исполнения, которая позволяет изолировать приложения от основной OS и других приложений, которые установлены в OS. Так же изолируются и безопасные процессы друг от друга, которые запущены в TEE.
FDE
FDE (Full Disk Encryption) – шифрование всего содержимого диска (не отдельных файлов) для защиты от воровства/изменения данных. Решения бывают разные, так же возможны разные способы миграции между этими решениями, в большинстве решений есть возможноcть восстановления доступа к данным при забытых паролях (key escrow, ниже о нем). Получить доступ к данным обычно можно с помощью пароля или ключа. Но сами данные, в “back end”, всегда шифруются/дешифруется ключами (при пароле – получение доступа к ключу). Чаще всего операция делается незаметно для пользователя – пароль для дешифрования (для ключа дешифрования) = пароль входа в систему.
FDE повсеместно используется во многих мобильных устройствах – ноутбуки, телефоны, планшетники. Но рекомендуется и для декстопов/серверов.
Возможные реализации FDE:
TPM – причем TPM может запрещать unlock диска если system configuration изменился (см. TPM platform integrity)
PGP
Bitlocker от Microsoft (Windows 10), интегрируется с TPM/USB drive или просто по паролю пользователя в систему (XTS-AES with 128 bit key)
Filevault 2 от Apple (XTS-AES-128 with 256 bit key)
dm-crypt – open source для Linux
FDE конфигурация включает один физический/логический раздел, который включает данные для мест, которые требуют шифрования (обычно root volume, где установлена OS). Данные шифруются не полностью – boot partition (kernel, bootloader, netRD) (чтобы BIOS смог запустить его) и окно авторизации (чтобы дешифровать данные) остаются незашифрованными. Чаще всего при использовании FDE невозможно по сети (если только это не IP-KVM) перезагрузить машину и ввести пароль после перезагрузки – сетевые службы чаще всего не стартуют до дешифрования FDE.
В теории, через подмену незашифрованных данных (kernel, bootloader, netRD), можно атаковать зашифрованные данные, но подобная атака сложна и кроме того есть защита от атаких атак в UEFI в виде реализации протокола SBP (Secure Boot Protocol). SBP использует public key cryptography для шифрования/дешифрования этих элементов boot процесса. Изначально SBP настроен для использования platform key (зашит в прошивку UEFI) – публичный ключ, соответствующий приватному, который используется для шифрования файлов. В момент загрузки с помощью этого ключа происходит дешифрование (проверка подписи) файлов и только корректно подписанные файлы будут запущены в итоге.
key escrow – позволяет восстановить ключ шифрования без пользовательского пароля авторизованному лицу. У авторизованного лица (админа) может быть для этого специальный ключ (escrow key), админский пароль, вход в учетную запись (icloud).
Использование OpenSSL
OpenSSL поддерживает ГОСТ шифрование, в том числе 2012 года.
OpenSSL библиотеку использовали в lab’е ниже для
генерации private key на базе RSA и создания public key на основе private key (key pair)
шифрования/деширования данных
генерации hash от данных и проверки на основе hash
OpenSSL is a commercial-grade utility toolkit for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It’s also a general-purpose cryptography library. OpenSSL is licensed under an Apache-style license, which means that you’re free to get it and use it for commercial and non-commercial purposes (subject to some simple license conditions).
Generate RSA private and public key pairs using the OpenSSL utility.
Before you can encrypt or decrypt anything, you need a private and a public key, so let’s generate those first!
Remember, a key pair consists of a public key that you can make publicly available, and a private key that you need to keep secret. Shhhh. 🙂 When someone wants to send you data and make sure that no one else can view it, they can encrypt it with your public key. Data that’s encrypted with your public key can only be decrypted with your private key, to ensure that only you can view the original data. This is why it’s important to keep private keys a secret! If someone else had a copy of your private key, they’d be able to decrypt data that’s meant for you. Not good!
First, let’s generate a 2048-bit RSA private key, and take a look at it. To generate the key, enter command “openssl genrsa -out private_key.pem 2048” into the terminal. This command creates a 2048-bit RSA key, called “private_key.pem”. The name of the key is specified after the “-out” flag, and typically ends in “.pem”. The number of bits is specified with the last argument.
Now, let’s generate the public key from the private key, and inspect that one, too. Now that you have a private key, you need to generate a public key that goes along with it. You can give that to anyone who wants to send you encrypted data. When data is hashed using your public key, nobody will be able to decrypt it unless they have your private key. To create a public key based on a private key, enter the command below.
Use the key pair to encrypt and decrypt some small amount of data.
You’ll simulate someone encrypting a file using your public key and sending it to you, which allows you (and only you!) to decrypt it using your private key. Similarly, you can encrypt files using other people’s public keys, knowing that only they will be able to decrypt them. echo ‘This is a secret message, for authorized parties only’ > secret.txt
This creates the file “secret.enc”, which is an encrypted version of “secret.txt”. Notice that if you try to view the contents of the encrypted file, the output is garbled. This is totally normal for encrypted messages because they’re not meant to have their contents displayed visually. To encrypt the file using your public key, enter this command:
The encrypted file will now be ready to send to whoever holds the matching private key. Since that’s you, you can decrypt it and get the original contents back. Remember that we must use the private key to decrypt the message, since it was encrypted using the public key. Go ahead and decrypt the file, using this command:
Use the key pair to sign and verify data to ensure its accuracy.
Now, you’ll create a hash digest of the message, then create a digital signature of this digest. Once that’s done, you’ll verify the signature of the digest. This allows you to ensure that your message wasn’t modified or forged. If the message was modified, the hash would be different from the signed one, and the verification would fail.
This creates a file called “secret.txt.sha256” using your private key, which contains the hash digest of your secret text file. To create a hash digest of the message, enter this command:
With this file, anyone can use your public key and the hash digest to verify that the file hasn’t been modified since you created and hashed it. To perform this verification, enter this command:
Authentication (authn) – проверяем что аутентифицируемый объект (клиент/сервер) является тем, кем он говорит, что он является.
Идентификация и аутентификация это разные вещи, несмотря на то, что они осуществляются (чаще всего) вместе.
Идентификация – ты говоришь, кто ты.
Аутентификация – проверяется что ты являешься тем, кем представляешься.
Аутентификация включает идентификацию и проверку личности. Идентификация включена в процесс аутентификации, она позволяет описать объект уникально (например, адрес почты уникально идентифицирует объект).
Идентификация является первым шагом при аутентификации – пользователь (аутентифицируемый) предоставляет данные, которые его идентифицируют (логин и пароль, IP адрес, имя, токен, почта, паспорт и проч.). При правильной реализации аутентифицируемые данные должны быть уникальны.
Аутентифицируемые данные так же:
не должны быть предсказуемыми и речь не только о парольных данных, это относится и к логину (напр. использование логина admin не рекомендуется)
выданы безопасным образом (secure issuance)
отозваны при необходимости
Аутентификация должна быть реализована правильно, некорректная реализация может привести к компрометации учетных записей, токенов/ключей сессий и прочим проблемам. Такой кейс частый, поэтому Broken Authentication problem является вторым в топ 10 OWASP для WEB applications.
Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
Примеры систем, которые аутентифицируют клиента (и не только – чаще всего используются для полного перечня AAA):
Могут контролировать доступ к любым ресурсам – сети (802.1x, VPN, Wi-Fi), серверам, ресурсам.
Многие из них используют EAP (Extensible Authentication Protocol), для согласования наиболее безопасных протоколов аутентификации для работы между клиентом и сервером. Данные пользователей зачастую хранятся в базе (иногда база и RADIUS – отдельные сущности), но некоторые системы могут работать и с обычными файлами (.htdigusers). RADIUS и TACACS, помимо задач аутентификации (пользователь тот, за кого себя выдает), решают и задачи авторизации (дать доступ туда/к тем командам, но не дать туда/к этим командам).
Clients don't actually interact directly with the RADIUS server; the authentication is relayed via the Network Access Server.
Электронные КАРТЫ (SMART CARDS)
«Классические» Memory card/bank ATM card содержат пользовательскую информацию на магнитной ленте, принцип работы:
карта вставляется в читатель кард,
далее читатель извлекает данные с карты,
запрашивает от пользователя пароль/pin,
пользователь вводит пароль/pin,
читатель путем применения операции хеша к паролю сравнивает пароль пользователя и хешированный пароль/pin, сохраненный на карте
На карте может храниться
user private key
генератор OTP
карта может отвечать на challenge-response
В smartcard и современных atm card принцип работы похож, но более безопасен в сранении с картами, работающими на магнтиной ленте:
вместо магнитной ленты на карте используется чип
карта сама проверяет пользовательские данные, а не читатель – на чипе находится микропроцессор, который получает питание при инсерте карты в читатель
Токены (Tokens)
Токены обычно ротируют коды (пароли) каждые n секунд (60 секунд для RSA SecureID), коды являются одноразовыми (OTP – One Time Password/Pad). СМС считаются менее надежными в сравнении с токенами – они не шифруются по умолчанию, их зачастую можно перехватить при хорошей тех. подготовке (или даже просто звонке оператору), сильная зависимость от организации безопасности у оператора связи.
One-Time Pad (OTP) - a key used only one time.
Примеры токенов на основе того с какими токенами работает Cisco Duo.
TOTP (RSA, time-based one time password/token) – в токен и на сервер включается одинаковое seed value (рандомно изначально сгенерированное значение ключа, которое хранится на сервере и на токене), далее на основе времени (которое 1) всем известно 2) должно быть относительно синхронизировано) происходит ротация ключа, причем
сервер может учитывать смещение во времени у токена в рамках нескольких минут
перехват кода OTP не так страшен т.к. он валиден только на одну попытку аутентификации ((проверено на данном блоге)).
COTP (counter-based one time password/token) – так же как и в OTP токен и на сервер включается одинаковое seed value, но вместо времени включается секретное значение счетчика, которое меняется каждый раз, когда пароль генерируется на устройстве. Считается более безопасной реализацией токена т.к. атакующему нужно выявить не только seed value, но и counter. Кроме того, если жертва продолжает пользоваться токеном, то быстро выявится взлом (токен перестанет работать т.к. значение счетчика на сервере != значению счетчика на токене).
U2F (Universal 2nd Factor, security keys) – эволюция физических токенов. Поддерживается браузерами (Google Chrome), большим количеством сервисов:
Браузер (Google Chrome) имеет встроенную поддержку протокола U2F - Браузер "знает", что полученный запрос на U2F-аутентификацию надо направить на U2F-токен - Браузер "умеет" это делать безо всяких дополнительных плагинов и пр.
Google все сервисы (Drive, Cloud, Gmail, YouTube, Wallet, Google+) GitHub WordPress Dropbox Linux PAM OpenSSH
Представляют собой маленькие устройства или встроенные в устройства криптопроцессоры (по сути TPM, в котором хранятся ассиметричные ключи и дополнительное пространство для запуска встроенного кода). Включает challenge-response, механизм вместе с криптографией на базе публичного ключа, для реализации более безопасного и, как ни странно, удобного решения second-factor authentication. Поддержка U2F встроена в Chrome/Opera браузеры. Защищает от клонирования или подделки т.к. внутри них есть уникальный секретный ключ, который защищен. Не защищает напрямую от Man-in-the-middle атак, но подразумевается, что использование U2F (аутентификация посредством U2F), должно проходить поверх TLS, который эту защиту обеспечит. Как работает secure key:
Регистрация ключа для сайта или сервиса. Во время регистрации secure key генерирует пару ключей private/public key для этого сайта (уникальных для этого сайта, на случай компрометации сайта) и отправляет public key на сайт для регистрации. Он так же идентифицирует сайт и сохраняет его public key.
После регистрации, во время аутентификации, сайт запросит логин/пароль, как обычно. Но после авторизации сайт так же запросит security key (например, в виде USB drive с кнопкой или подключения телефона и нажатия кнопки – гарантия что вирус не авторизуется за вас без вашего знания). Challenge-response подразумевает уникальную сессию, которую нельзя повторить (repay attack), в рамках каждой аутентификации – клиент шифрует challenge сервера своим private ключем при каждой аутентификации и отправляет на сервер, сервер проверяет challenge, дешифруя его public key клиента. Что делает схему крайне безопасной.
SSO (Single Sign-On) – один раз авторизовался, а далее успешная авторизация позволяет заходить в сервисы, проходя окно авторизации (OpenID, Citrix SSO, SAML, LTPA IBM). Очень удобно – позволяет не хранить кучу разных паролей, не терять время пользователя на постоянные реавторизации и обслуживание систем с паролями. Недостаток в безопасности – один взлом (напр. традиционный или новый – воровство session cookie/token/ticket) потенциально дает доступ ко всему . Поэтому SSO обычно используется только в схеме 2FA/MFA.
SSO может быть реализован по разному, например:
путем аутентификации на центральном сервере аутентификации (напр. LDAP, Kerberos), далее LDAP/Kerberos предоставляет cookie/token/ticket, который может использоваться чтобы получить доступ к приложениям, которые сконфигурированы с возможностью использования SSO.
с использованием SAML (WEB SSO) и identity providers (подробнее ниже).
Работа без SSO. На схеме юзер последовательно аутентифицируется к application 1, затем в application 2.
Работа с SSO. Схема подключения к двум application при использовании SSO. Несмотря на то, что картинка выглядит значительно сложнее первой, пользовательский опыт по факту в схеме с SSO лучше, чем без SSO т.к. пользователю только один раз (напр. в первом приложении одного SSO домена) нужно пройти аутентификацию, а далее он передает сохраненные куки/токен второму (в том же SSO домене).
Понятия в SSO:
Relaying Parties – приложения/сайты, к которым пользователь получает доступ
Federated Identify (ID) or Centralized Identity or Linked Identity – пользовательские данные, хранящиеся на центральном сервере (federated identity system)
Federated Identity System/Provider – система, которая обрабатывает запросы SSO на аутентификацию/авторизацию, так же передает/обменивается пользовательскими атрибутами между identity providers и relaying parties. В ней можно управлять пользователями. Identity provider (IdP) – сервис (application, web site) ответственный за координацию identities между пользователями и клиентами. IdP может обеспечить пользователя идентифицируемой информацией и передавать эту информацию сервисам, когда пользователь запрашивает доступ.
Federated identity management – совокупность разделяемых протоколов, которые позволяют управлять пользовательскими id в организации
Delegation – SSO использует его для вызова внешнего api для аутентификации/авторизации пользователей, используется чтобы в приложении не хранились пользовательские данные (user/pass)
Domain – сеть, в которой все пользователи и ресурсы (приложения) подключены к одной центральной базе (Federated identity system)
Factor – вектор, посредством которого может быть подтверждена личность при аутентификации
Forest – коллекция доменов, управляемых централизованной системой
Multitenancy – термин, который обозначает то, что в архитектуре предусмотрена возможность полного логического разделения, которая позволяет использовать сервис/приложение/устройство разными пользователями независимо друг от друга. Пример multitenancy – SAAS (microsoft 365, google docs, yandex music).
Passwordless – метод доступа без использования пароля, обычно на основе токена/смс/email/biometric sensors
Social ID provider (social IDp) – тип identity provider на основе социальной сети (google, facebook, twitter)
webID – идентифицируемые данные обычно получаются из http запроса, часто они получаются из аутентифицированного email
Windows ID – пользовательская информация в active directory
ws-federation – стандарт для информации о identity используемый в веб приложениях и браузерах, используемый в windows identity foundation (фреймворк созданный microsoft для создания identity aware applications)
WS-Federation defines mechanisms for allowing different security realms to broker information on identities, identity attributes and authentication.
Методы аутентификации в WEB (кратко, подробно поиском по каждому в этой статье):
SSL/TLS authentication на базе digital certificate PKI (подробнее PKI)
HTTP Basic Auth – крайне простая аутентификация: никаких handshake, никаких cookie, никакого шифрования (нужно использовать SSL/TLS). В каждом запросе в HTTP header к серверу клиент в открытом виде передает закешированные учетные данные. Недостатки крайне серьезные: нет стандартного логаута, не кастомизируется форма по вводу логин-пароль (или других credentials), существующие реализации имеют уязвимости, несмотря на простоту самой концепции.
HTTP Form-based Auth – самый популярный способ аутентификации. В сравнении с Basic Auth
форма по вводу учетных данных кастомизируется как угодно, но при этом стандартизации в реализации нет
данные так же передаются в открытом виде и требуется использование шифрования SSL/TLS
DAA (Digest Access Authentication) – по сути аналог Basic Auth, но вместо передачи в открытом виде каждый раз учетных данных передается MD5 hash от этих данных и так же nonce для защиты от атак на повторение (repay). Нужно учитывать, что MD5 небезопасен (уязвим для атак на коллизии хеша), поэтому хоть это и лучше чем в clear-text, но полагаться на эту защиту вообще не стоит.
LTPA (Lightweight Third-Party Authentication) – IBM proprietory метод для SSO.
OAuth, OAuth2
OpenID, OpenID Connect (OID)
SAML (security assertion markup language) – открытый стандарт аутентификации и авторизации на основе XML, так же как OpenID есть возможность передавать Attribute пользователя (напр. email/phone). Используется для обмена аутентификационными/авторизационными данными между identity providers. Раньше требовал использования SOAP over HTTP, но в версии SAML2 это больше не требуется. SAML широко используется для реализации SSO.
OpenID (OID) – open decentralized authentication system. Используется обычно в связке с OAuth. Открытый стандарт, который позволяет участвующим сайтам, известным как Relying Parties, аутентифицировать пользователей используя третью сторону (какой-то сервер аутентификации, Identity Provider – Google, Microsoft, Yahoo, FaceBook, etc). Похожая на SSO вещь, но аутентификация зачастую не сквозная. В результате сайты аутентифицирует пользователей, не требуя от пользователя данных и не требуя реализации аутентифиции на самом сайте. Так же пользователи могут посещать сайт, не создавая аккаунт. Хотя это зачастую и сложно реализовать/поддерживать, это очень удобно для клиента, который не хочет плодить сущности без нужды. Для работы сайту нужно создать shared secret с провайдером и все (используется для обмена сообщениями). После редиректа клиента, в результате успешной авторизации у третьего лица и подтверждения что клиента хочет авторизоваться на сайте, сайт получает факт успешной аутентификации и какие-то данные (Attribute Exchange Extension – напр. email/phone) + токен (не пароль).
OAuth2 – открытый протокол/стандарт авторизации, используемый многими API и современными приложениями. Является крайне популярным методом авторизации, похожий на OpenID. Самый главный плюс OAuth – пользовательские учетные данные никогда не передаются непосредственно приложению. Приложению передается только временный token (должен быть временным, по факту конечно можно реализовать и “криво”) который сопоставляется с пользователем и может быть отозван провайдером OAuth/пользователем. OAuth2 требует использования TLS для шифрования данных.
Схема работы OAuth очень похожа на OpenID, только вместо аутентификации, сайт получает какой-либо доступ от имени пользователя (например, отправлять сообщения/почту). Обычно OpenID используется совместно с OAuth – OpenID Connect это уровень аутентификации, встроенный в OAuth 2.0. По сути как RADIUS и TACACS, объединение задач аутентификации и авторизации. Для relaying parties/third party services позволяет аутентифицировать пользователей и при этом не хранить у себя пользовательские учетные данные, что зачастую является очень весомым аргументом (правовые аспекты).
В отличии от чистого OpenID провайдер OAuth авторизации знает все о том, кто решил проверить клиента, так же OAuth привязан к конкретному провайдеру, в отличии от OpenID. И это огромный плюс для таких крупных игроков как google/facebook/vk. Полезно для небольших сайтов, например блогов – можно только таким пользователям давать возможность комментирования. В OAuth встроена поддержка Redirect URI – после авторизации OAuth (напр. в Google) происходит перенаправление “обратно” на исходный сайт это как удобно, так и позволяет избежать определенных векторов атак.
Пример совместной работы OAuth и OpenID. Так же OAuth работает и с SAML.
Authorization (authz) – выдача полномочий на основе аутентификации (куда имеет доступ аутентифицированный entity). Авторизация (так же как и аутентификация) должна быть реализована правильно, некорректная реализация может привести к компрометации учетных записей, токенов/ключей сессий и прочим проблемам. Такой кейс частый, поэтому Broken Access Control является пятым в топ 10 OWASP для WEB applications. Подходом к контролю доступа (access control) называют политикой безопасности (security posture). Есть два основных подхода к контролю доступа:
по умолчанию запретить (implicit deny/default deny, в то числе zero trust) – доступ который не разрешен = запрещен, подход чаще всего используемый на устройствах реализующих безопасность ((подробнее о implicit deny выше))
по умолчанию разрешить (default allow) – доступ который не запрещен = разрешен, подход чаще всего используемый когда безопасность или не нужна или не является критичным фактором (в сравнении со скоростью deploy, например), примером устройства можно считать коммутатор
Так же в контексте контроля доступа существуют принципы безопасности:
обоснованность доступа (need to know, need-to-know) – есть причины, по которым нужен доступ к информации/системе
наименьшие привелегии (least privilege) – нужно предоставлять минимально необходимый уровень доступа требуемый для выполнения работы
Контроль авторизации бывает на основе разных схем:
Mandatory Access Control (MAC) – политики, которые не может поменять владелец информации (как понимаю, напр. требования регулятора). В MAC объектам назначается security label с категорией объекта. Субъектам назначается уровень видимости в соответствии с принципами need to know (категория), least privilege (уровень доступа) используемыми категориями объектов. При попытке доступа субъекта к объекту происходит сравнение (напр. на базе ОС) уровня видимости/доступа и категории объекта. Уровень субъекта должен быть не ниже уровня объекта и у субъекта должен быть доступ к категории объекта. Реализуется зачастую по требованиям регулятора (правительственные/военные системы).
Discretionary Access Controls (DAC) – политики, заданные владельцем информации/ресурса. Широко используются в коммерческих операционных системах. Владелец информации создает ACL, в котором описывает какие пользовательские id/групповые id имеют доступ к каким данным. Разрешения при использовании групп кумулятивные – если группа имеет права только read, а учетная запись в этой группе write – то в итоге пользователь сможет и читать и записывать.
Role-Based Access Control (RBAC, так же называют non discretionary controls) – политики на основе роли или функции. Права не назначаются на группу или пользователя. Администраторы выдают разрешения для роли, пользователям присваиваются роли (одна роль на пользователя, без возможности кастомизации под учетные записи). Для кастомизации создаем новую роль и применяем ее к пользователю. В итоге это очень гибкая система.
Rule-Based Access Control – доступ осуществляется независимо от пользователя или группы (напр. время суток, местоположение, src/dst address, workstation). Критерий и правила определяются владельцем ресурса. Правила можно комбинировать с другими методами доступа – напр. DAC/RBAC
Attribute-Based Access Controll (ABAC) – модель контроля доступа на основе оценки атрибутов объекта и субъекта, который получает доступ к объекту, с использованием кастомизированной логики. ABAC имею поддержку булевой логики, которая может оценивать большое количество атрибутов. Такие правила могут быть очень гибкими и сложными. Пример access control фреймворка, который включает ABAC – extensible access control markup language (XACML).
Authorization model – определяет то, как предоставляются авторизационные права.
Object capability – на базе характеристик объекта, к которому организуется доступ.
Security labels – на базе лейбла безопасности, такого как confidential, secret, top secret.
ACL – на базе критерия, который можно задать в access control list (user id, group, location, day)
Object capability used programmatically and is based on a combination of unforgible reference and an operational message Security labels are mandatory access controls embedded in object and subject properties Acls are used to determine access based on some combination of specific criteria such as a user id, group membership, classification, location, address, day.
Примеры двух уязвимостей в WEB приложениях, относящихся к авторизации:
HTTP Parameter Pollution (HPP) – уязвимость возможна, когда несколько HTTP параметров имеют одно имя. Атакующий при эксплуатации уязвимости может обойти проверку ввода, вызывать ошибки в приложения или модифицировать значения внутренних переменных. Атакующий может найти уязвимость анализируя формы и действия которые доступны для пользовательского ввода в веб-приложении, в последующем атакующий может добавить в GET/POST данные несколько переменных с одним именем, но разным значением и посмотреть на поведение приложения – если ответы отличаются (impedance mismatch), то потенциально возможно наличие уязвимости.
Insecure Direct Object Reference – приложение предоставляет доступ к объекту на основе пользовательского ввода, что в итоге может приводить к authorization bypass и доступ к sensitive data (база/файлы и проч). Сделать тестовую атаку можно используя OWASPWEBGOAT + OWASP ZAP (линки на них поиском по OWASP). Приложение не делает input validation/sanitation/escape technique и не реализует корректную авторизацию. К примеру – по ID пользователя мы получаем информацию о нем, хотя этим пользователем не являемся или меняем ему пароль.
ACL (Access Control Lists) – бывают не только на сетевом оборудовании, но например в файловой системе (разграничение по правам в Windows тоже делаются через Access Control Lists). Папка или отдельный файл может иметь список лиц/групп-лиц, которые могут иметь те или иные (R/W/E) права к папке/файлу. Индивидуальные разрешения для объекта называются Access Control Entries, они составляют ACL.
Accounting
Accounting-ом зачастую пренебрегают, но он крайне важен для обнаружения/расследования взломов.
Нужно защищать данные аккаунтинга – там зачастую содержаться сенситив данные, поэтому доступ к ним должен быть ограничен.
Нужно учитывать желание хакеров замести следы путем манипуляции/уничтожения аккаунтинг данных.
Обмен в случае RADIUS защищается путем использования разделяемого ключа между клиентом и сервером. Можно настроить периодические RADIUS аккаунтинг пакеты между клиентом и сервером (напр. Cisco ISE) для отслеживания активных сессий на текущий момент.
Accounting – сохранение данных о том, куда ходил/что делал пользователь в системе. Критичным компонентом accounting является Аудит, потому что сам запись в accounting не означает, что кто-то его смотрит (как с мониторингом). “Классический” TACACS используется как syslog – по сути кто, что ввел в консоли устройства. “Классический” RADIUS accounting часто используется для биллинга ISP – он записывает большое количество данных, которые могут использоваться для анализа достижения квоты (ограничить доступ в это время, ограничить полосу когда выкачал столько то):
длину сессии (как долго пользователь был подключен к сети),
начало и окончание сессии,
местоположение клиента,
bandwidth (или другие выделенные сетевые ресурсы),
количество переданных/полученных данных,
информацию клиента (напр. логин, локальный IP) и выделенные сервером ресурсы (политики, внешние адреса),
прочие параметры
Network security
Network hardening – процесс улучшения безопасности сети путем уменьшения потенциальных рисков через конфигурационные изменения и соблюдение политик. Implicit deny, monitoring & analyzing traffic.
Мониторинг трафика (в том числе возможно и с клиентских устройств и приложений, не только логов с файрвола и аутентификаций; полезно и при разборе уже состоявшихся взломов в рамках post-fail analysis/post-mortem, чтобы предотвратить повтор/понять масштаб взлома) и анализ логов (причем чаще всего автоматический анализ, не ручной) крайне важен т.к. сначала нужно понять корректные паттерны поведения пользователей в сети, чтобы потом понять нетипичные, которые возможно говорят о взломе/заражении.
Логи должны собираться со многих устройств (зачастую вплоть до конечных устройств) в одну систему, анализироваться (автоматизировано и вручную), защищаться (чтобы не могли замести следы).
В контексте того, что нужно логгировать и сколько хранить, нужно найти середину:
слишком много данных очень часто плохо – во первых дорого для хранения, во вторых избыточные “мусорные” данные зачастую не позволяют найти важное
слишком мало – тоже плохо, можно не слоггировать то, что нужно было логгировать
SIEMS – Security Information and Event Management System – по сути централизованный сервер логов для СБ, с возможностью анализа логов. Примеры: rsyslog, Splunk Enterprise Security, IBM Security Qradar, RSA Security analytics.
Системы по автоматическому анализу логов (logs analysis system, например Splunk):
часто лог системы позволяют нормализировать данные из разных источников (например на входе поменять YYYY-MM-DD на DD.MM.YYYY), зачастую позволяя реализовать correlation analysis (анализ взаимосвязей событий) между разными системами
могут алармить на преднастроенные правила (после стольких то попыток неудачных аутентификаций слать аларм), но лучше правила задавать и самому – только ты знаешь где у тебя критичная БД и кто должен к ней обращаться, какие протоколы могут быть использованы для подключения, а какие (даже попытки) – не должны происходить вовсе. На эти настроенные правила можно настраивать оповещения в зависимости от категории/приоритета.
802.1x – IEEE стандарт использующий EAP (Extensible Authentication Protocol). Поэтому часто называется EAP over LAN (EAPOL). Не защищает от подслушивания, для этого надо использовать PEAP (Protected EAP), EAP-TLS или MACsec (802.11ae). Изначально придуман для Ethernet, но поддерживает и другие типы среды (Wi-Fi, fiber). EAP по своей природе поддерживает огромное количество разных методов аутентификации, один из самых часто используемых в 802.1x является EAP-TLS. EAP-TLS предоставляет mutual authentication (cleint & server). Часто используется в enterprise WLAN.
Схема работы 802.1x похожа на схему работы обычного RADIUS – клиент (EAP supplicant) взаимодействует с сервером через relay (switch/AP). Relay на основе ответа сервера предоставляет доступ. При этом relay взаимодействует с клиентом по 802.1x (и для клиента является по сути сервером), а с сервером аутентификации по RADIUS. При аутентификации может использоваться сертификаты (софтовый или даже ключи в TPM), пароль (ISP), сертификат + пароль, токен и все что угодно.
Пример кейса применения macsec – шифрование между своими стойками в арендном ДЦ.
Macsec, 802.1ae (в cisco – cisco trustec, cts) – Media Access Control Security, реализует шифрование на канально уровне.
Поддерживает работу (шифрование) в двух режимах:
uplink macsec – switch-switch
downlink macsec – host-switch с использованием MKA (macsec key agreement)
SAP (security association protocol) используется для обмена ключами при шифровании switch-switch.
Аутентификация возможна по manual admin shared key (SAP PMK), но так же возможна и с использованием 802.1x
Режимы работы macsec:
Auth only
Auth + encryption
Encryption only
Network separation – разделение сети на разные элементы, полезно в сетевой безопасности (разные vlan, подсети, vrf, контексты) – можно изолировать проблемы, проще мониторить трафик между элементами и проч.
Proxy и Reverse Proxy – подробнее в статье про proxy.
HoneyPot – приманки для атакующих. Их огромное количество. Бывают универсальные, а бывают под конкретное направление – могут например даже эмулировать industrial сеть с SCADA контроллерами и управляющими сообщениями, передаваемыми посредством Modbus.
Или могут предоставлять функционал, которые расписывает подробно все действия вирусов в системе используя sandboxing – какой код запускался, какой файл/регистр изменился, состояние памяти, чем обменивался с сетью и проч. И самое главное безопасно для того, кто этим занимается. Примеры sandbox решений – Cisco Threat Grid, Cuckoo Sandbox.
Создать своего рода sandbox можно вручную, главное защитится от ситуации, когда вирус из виртуальной среды инфицирует host машину – нужна полная изоляци и отключение всех шарингов между host машиной и виртуальной.
Вообще не любой malware код запустится в sandbox среде – вирусописатели люди тоже не глупые и зачастую реализовывают методы проверки. malware код не стартует:
Если обнаружено, что запуск произведен в VM среде (напр. по коду OUI извлеченного из MAC адреса).
Если обнаружено, что на хосте отсутствует сетевое подключение (тут может помочь утилита FakeNet)
Wi-Fi Security
В контексте безопасности лучше всего использовать WPA3
Покрытие беспроводной сети должно быть минимально необходимым, не заходя за пределы помещения/объекта
Сюда все из IT раздела.
WEP (Wired Equivalent Privacy) – уже через после нескольких лет использования перевод звучит как стеб. Разбирать как он работает нет смысла – его нельзя использовать (если только в качестве honey pot)
WPA (Wi-Fi Protected Access) – изначально придумывался как временное решение, которое позволит заменить WEP на том же оборудовании, на котором работает WEP, через простую перепрошивку. Тут появился TKIP – temporary key integrity protocol, в нем реализованы новые (по сравнению с WEP) фичи:
WPA3 – самая безопасная версия WPA.
Более безопасный способ генерации ключа (используется и в WPA2)
позволил более безопасно реализовать добавление IV (initialization vector) к per packet encryption key (не простой конкатенацией, а применением hash-функции).
Pre-shared key не используется напрямую для шифрования трафика – PSK передается PBKDF2 (password-based key derivation function 2) вместе с SSID (как соль для защиты от rainbow table атак) и поверх этого прогоняется HMAC-SHA1 функция 4094 раз
Добавлен sequence счетчик (TSC), для защиты от атак повтора (отброс пакетов, которые непоследовательны)
64-битный MIC использовался для защиты от подделки/изменения пакетов
Большая разрядность ключа (256 бит)
При этом TKIP так же продолжает использовать RC4 алгоритм, но на каждый пакет генерируется свой уникальный ключ, в отличии от WEP.
WPA ввел возможность использовать разные методы авторизаций:
WPA/WPA2 personal/PSK – на основе PSK
WPA/WPA2 enterprise – на основе 802.1x. WPA2 enterprise считается самым защищенным вариантом. PMK в таком случае генерируется на основе выбранного метода EAP, например EAP-TLS mutual auth – требует полноценного и правильно реализованного PKI, RADIUS сервера и AP. Обычно в качестве RADIUS сервера для аутентификации используются Microsoft Network Policy Server (NPS), Cisco Secure Access Control Server (ACS) или FreeRADIUS.
WPA2 – добавил еще безопасности, во первых он отказался от RC4 в пользу AES (TKIP WPA2 – неполноценный WPA, по сути). CCMP (AES GCM – Counter Mode CBC-MAC Protocol) – он позволил реализовать аутентифицированное шифрование (данные конфиденциальны и аутентифицированы), через механизм authenticate & encrypt.
Довольно безопасный стандарт, но все таки его можно взломать в версии PSK через offline bruteforce attack процесса four way handshake. Если атакующий перехватывает все пакеты four way handshake (Nonce и MAC получаются из этих пакетов), то можно brute-force пытаться угадать PMK (см. утилиты типо aircrack). Для защиты нужен хороший пароль + необычный SSID. Для взлома GPU-cloud (прогонять 4094 раз через hash SHA-1 функцию) или ranbow table. Иначе, если SSID какой-то стандартный и предполагается что и пароль стандартный – для 1k top most SSID и 1kk top most password есть таблицы.
Сначала рассчитывается CBC-MAC digest, затем результирующий authentication code шифруется вместе с сообщением, используя блочный шифр (напр. AES в режиме counter, что превращает его в stream cipher, используется seed value с инкрементирующимся counter для создания key stream, который шифруются данные).
Как клиент проходит аутентификацию (four-way handshake).
AP отправляет nonce клиенту
клиент отправляет nonce AP
AP отправляет GTK
клиент отправляет ACK
В результате успешной аутентификации (AP понимает, что у клиента есть Preshared Master Key PMK, без непосредственного обмена им) генерируется временный ключ шифрования (Pairwise Transient Key PTK), который будет использоваться для шифрования данных от клиента и к нему. PTK генерируется из многих вещей – PMK, AP nonce, Client nonce (рандомные данные), AP MAC addr, Client MAC addr (конкатинируются и прогоняются через hash). PTK состоит из 5-ти ключей – два ключа для encryption и подтверждения EAPoL, два ключа для отправки/приема integrity check, ключ для шифрования данных (temporal key). Так же AP передает GTK – Groupwise Transient Key (шифруется EAPoL encryption key из PTK), который используется для broadcast/multicast пакетов (поэтому GTK разделяется между всеми клиентами одной сети), он периодично обновляется и переотправляется клиентам (или по событию отключения клиента).
WPS в любой его форме рекомендуют отключать. Скан утилита для проверки что WPS везде выкл – wash.
WPS бывает не только по кнопке:
PIN entry authentication
клиент генерирует PIN и вводит его на AP
PIN зашит в прошивку AP
NFC/USB
push-button
Зашитый PIN в прошивку чаще всего ругают в контексте ругани WPS – его легко ломают brute force, причем метод вообще говно т.к. двумя частями отправляется pin (сначала первая часть и если она ок!!!!!!, то вторая). В результате за 11к попыток можно перебрать все варианты (без rate limit можно было взломать меньше чем за 4 часа, пока в спецификации не сделали тресхолд 3 неправильные попытки в минуту, но даже это воркэраунд = 3 дня).
Обычно это происходит автоматически при запуске инструментов для снифинга, но перехват трафика требует помещение интерфейса в promiscuous (неразборчивый) режим, чтобы сетевая карта не дропала пакеты, которые не предназначены ей. В Wi-Fi карточку так же можно переместить в Monitor mode – она будет слушать даже пакеты в других (не только в подключенном) SSID и на других частотах.
В контексте атак типо OpenSSL heartbleed и множества других подобных проблем с безопасностью софта (например баги с Java, Adobe Flash Player, ОС или даже драйверами устройств) крайне важны инструменты, которые будут уведомлять о новых патчах/новых версиях софта. Зачастую это встроено в антивирусы, но есть и специализируемые инструменты типо Microsoft SCCM, Puppet Labs, которые позволяют изучить какой софт глобально установлен на всех ПК и обновить его при необходимости.
Общая практика – поддерживать работу только последней версии софта и запрещать явно ненужное/разрешать явно нужное. Под последней версией часто подразумевается именно стабильная последняя версия т.к. самая последняя версия может быть с багами.
Разрешенное унифицировано обновлять (унифицировано – чтобы иметь единообразный софт везде, упростив эксплуатацию и уменьшив attack surface). Ограничить использования софта определенной версией/запретить использование определенного софта (blacklist)/разрешить использования определенного софта (whitelist) можно через политики AD. Причем под софтом подразумеваются даже расширения в браузере – которые часто недооценивают в контексте безопасности. Они могут собирать/подменять информацию на сайтах, на которые пользователь ходит, отправлять на удаленные сервера user input и прочее.
Безопасность в Chrome OS Under the hood ядро Linux (как и во многих других новых ОС).
Отличительная особенность Crome OS – простота и безопасность:
Основным приложением является Chrome Browser.
Chrome browser запускается из под пользователя и не может нарушить работу системы. При этом extension в CromeOS Chrome Browser так же опасны, как и в Chrome Browser на Windows – не нужно ставить непроверенные.
Большая часть данных пользователя хранится в облаке. Но часть (downloaded files, cookies, bookmarks, caches), для ускорения работы или offline использования – локально. Информация, которая хранится локально, шифруется паролем пользователя + крипто-ключами с TPM (в новых версиях ChromeOS – H1, защита, например, от воровства диска и попытки подобрать пароль на другом устройстве). Так происходит для каждой пользовательской директории – это называется vault.
По умолчанию все настройки выставлены “безопасными” и не нужно ничего делать – например, апдейты автоматически скачиваются и устанавливаются.
Так же Chrome OS состоит из нескольких уровней безопасности, реализуя модель defence in depth (если один уровень не отрабатывает – есть другие).
Каждый процесс и вкладка Chrome является уникальным процессом, изолированы на уровне ОС от остальных (sandboxing). Исключением является только данные на HDD под эти вкладки/процессы (cookie, cache, bookmarks), причем к данным одной вкладки безусловно не может обратится процесс другой вкладки.
OS Recovery Mode – У Chrome OS простой процесс восстановления, в случае повреждения/изменения системных файлов система входит в режим восстановления и помогает пользователю восстановить ее.
Powerwash – позволяет легко сбросить ОС к заводским настройкам (как телефон), персональные данные восстанавливаются из облака. Причем powerwash стирает ключи пользователей отчищаемой системы из памяти, делая невозможным восстановление данных с ЖД (т.к. они шифруются данными пароля пользователя + ключами с TPM – см. ниже).
Verified Boot
Verified Boot – проверяет целостность системы при загрузке. Если в с систему были внесены изменения – она не загрузится, вместо этого запустится процесс восстановления. Так же Verified Boot не даст загрузить систему, версия которой помечена как уязвимая.
Состоит из четырех компонентов:
read-only firmware – прошивка с которой поставляется Chrome OS устройство. Изменить прошивку без физических изменений машины невозможно – прошивка защищена от удаленных атак. В прошивку включаются криптографические ключи, которые проверяет что последующий компонент (read-write fw) при загрузке из доверенного источника и что в последующем компоненте нет лишнего кода. Если проверка завершена успешна – исполняется код из read-write fw, если не успешна – read-only fw попытается восстановить систему из последнего backup read-write fw (предварительно проверив, что он валиден). Если и в backup какая то дрянь – система будет загружена в режиме восстановления (recovery mode).
read-write firmware – прошивка, которая может автоматически обновляться по необходимости. Проверяет непосредственно ОС (ядро ОС из доверенного источника) примерно таким же алгоритмом, что и read-only fw (алгоритм точно такой же – если найдено несоответствие – загружаем другой OS kernel или уходим в восстановление ОС).
OS kernel – при загрузке kernel проверит целостность root file system, которую использует. Алгоритм точно такой же – если найдено несоответствие – загружаем другую Root File System или уходим в восстановление ОС.
Root file system – хранит непосредственно данные ОС и пользователя.
Причем Kernel и Root File System хранятся на разных разделах. И их два – read only (который используется при обычной работе), read-write (меняется софтом при обновлениях).
Vulnerability scanners (сканеры на уязвимости)
Пример утилит – Nessus (Tenable), OpenVAS, Qualys.
Примерный алгоритм работы:
Сканят сеть на хосты с помощью разных способов – ping sweep, port scanning
Детальный скан запускается на каждый обнаруженный хост
Делается попытка определения сервисов за портами
Делается попытка взлома сервисов на основе баз известных уязвимостей и мисконфигураций (напр. неоптимальные ciphers, пароли по умолчанию. Nessus проверяет как понимаю не реальными атаками, а их моделированием на основе Nessus attack scripting language. Базу с уязвимостями нужно регулярно обновлять (ничего нового), иначе не будет скана на новые уязвимости.
Отправляется репорт для последующего анализа/обработки, который включает уязвимые хосты/сервисы, уязвимости приоритезируются и категоризируются, можно почитать подробно о каждой найденной уязвимости (софтовой баги или даже неправильно настроенного сервиса или даже наличия бекдора в системе), иногда так же есть информация как можно избавится от нее/включается информация о том, есть ли возможность удаленного эксплойта найденной уязвимости и прочая важная информация для анализа.
Пример репорта из Nesus:
Тесты на проникновение (penetration testing)
Тесты на проникновение (penetration testing) – практика попытки взлома системы/сети для проверки корректности работы систем безопасности. Хакеры в белых шляпах. Использование эксплойтов и систем типо hacking linux (kali linux).
Осуществление регулярных pentest и формирование/разбор отчетов по ним не менее важный аспект в безопасности, чем регулярные vulnerability scanning. Позволяет проверить что системы обнаружения/блокирования/логгирования вторжений работают корректно. Сами тесты (как pentest, так и vulnerability scan) могут производится как внутренними сотрудниками ИБ (in-house), так и внешней аудит организацией (third-party testing). Рекомендуют использование одновременно обоих подходов.
Стандарты в области безопасности
PCI DSS (Payment Card Industry Data Security Standard) – пример всеобъемлющего стандарта безопасности, которому нужно следовать, в случае если компания обрабатывает платежи по кредитным картам.
У стандарта 6 основных задач:
Построение безопасной сети и систем – например, путем использования файрволов, запрета на использование паролей по умолчанию в системах. К примеру, вплоть до того, что должно быть под контролем на уровне файрвола – запрет на установку соединений из небезопасной сети в системы, которые хранят/обрабатывают данные cardholder (держателей карт).
Защита данных cardholder – защита сохраненных данных, шифрование (криптостойкое, с указанием примеров) данных по карточкам при передаче по открытым сетям (включая методы по реализации это передачи), политики по предельному времени хранения данных перед авто-удалением (data retention policies, к примеру, после авторизации платежа не сохранять данные, необходимые для аутентификации платежа, карты, а безопасно удалять их).
Поддерживать программу по управлению уязвимостями (vulnerability management program) – реализовывать и поддерживать безопасные системы и приложения. К примеру, защищать все системы от вредоносного ПО, регулярно проверять наличие антивирусного ПО на системах (patching), обновлять антивирусное ПО, обновлять ПО (особенно security patches, в пределах месяца после выпуска), иметь логи. Причем интересный факт – в общем случае, чем более важный сервер/сервис для компании, тем менее вероятнее что он будет пропатчен из-за того, что добавление патча зачастую сопровождается прерыванием сервиса и потенциальным влиянием на стабильность и надежность работы приложения.
Реализация мер по разграничению доступа (access control measures) – ограничение к данным cardholder политикой business need-to-know (проверяем что доступ к данным действительно нужен), аутентифицировать доступ к системам (пароли, 2FA/MFA), ограничить физический доступ к данным.
Регулярно мониторить и тестировать сети (regularly monitor and test networks) – отслеживать все попытки доступа к системам/сетевым ресурсам/cardholder data, регулярно тестировать системы безопасности и процессы. Тут помогут системы по логгированию (SIEMS), обнаружению вторжений (IDS/IPS), автоматические сканы посредством спец. утилит на уязвимости (vulnerability scanning utilities, например Nessus, OpenVAS, Qualys), сканы отработки защиты и систем аутентификации на атаки (penetration testing) – все это крайне важно в контексте безопасности.
Поддерживать политику по ИБ (maintain an information security policy) – поддерживать политику ИБ, которая относится ко всему персоналу/пользователям систем. Следовать ей должны все сотрудники, не только сотрудники ИБ. Политика должна быть продуманной (well-thought-out), но при этом простой для понимания (и нахождения). Должны быть созданы обучающие программы, которые в деталях описывают политику ИБ.
Privacy Policy
Privacy Policy (политики по работе с конфиденциальными данными) – подразумевают процедуры (кто, как, по каким причинам, где хранятся данные и где их нельзя хранить) и средства по обеспечению (шифрование; логгирование/аудит/информирование; ограничение доступа; доступ к данным, для тех, у кого есть доступ, только через запрос на доступ к данным; временной лимит на доступ) безопасного доступа к конфиденциальным данным.
Sensitive data exposure является третим в топ 10 OWASP для WEB applications – очень часто персональные данные хранят/обрабатывают не так, как нужно.
Облачная безопасность, как и традиционная, ставит вопросы защиты критичной информации от воровства, извлечения и удаления данных, приватность.
Большое количество вопросов при сохранении данных в публичных облаках к тому – что вы начинаете доверять облачному провайдеру, что он обеспечивает необходимую защиту ваших данных (shared responsibility client & cloud provider).
К примеру, при использовании облаков требуется обеспечение облачными сервисами физической безопасности носителей данных клиентов (СКУД, камеры, физические замки, юридическая ответственность и прочие вопросы). Кроме того, все чаще требуется соблюдение требований регуляторов, под которые подпадают данные клиентов (подобные законы существуют в Europe, USA, Russia, etc).
Примеры атак, которые справедливы для облачной среды:
Authentication and authorization attacks
API attacks – использование уязвимостей/небезопасных конфигураций в APU)
Session/traffic hijacking – перехвата трафика
DNS phishing attacks – подмена легитимного сайта через изменение DNS записи
XSS and many web application attacks (for example OWASP TOP 10)
SQL injection attacks
CSRF (session riding) attacks
DDoS attacks
MiTM attacks
Side-channel attacks – виртуалка атакующего находится на той же хост машине или максимально приближена к жертве, атакующий пытается использовать эту близость для взлома жертвы эксплуатируя баги изоляции между vm/containers
Примеры правильных вопросов облачному провайдеру до подписания с ним договора:
Используется ли шифрование при передаче и хранении моих данных? Если да, то какое и где хранятся ключи.
Как мои данные разграничены с данными других людей? На уровне виртуализации или физическом уровне?
Проводите ли вы тренинги сотрудников?
Разделяете ли вы данные по типу (data classification)?
Какой будет SLA и сколько будет стоить нужный уровень?
Что будет в случае появления уязвимости у провайдера, которая влияет на сервисы/данные клиента (кто будет ответственным, какие действия будут предприниматься и проч
Есть ли у cloud provider business continuity и disaster recovery (BCP/DR) планы. Какая реакция будет на подобные инциденты и какие гарантии (и стоимость) при их появлении в продолжении предоставления сервиса/защиты от потери данных.
Что будет с вашими данными после того, как контракт с cloud provider будет расторгнут (завершен)
Top secret — Cryptologic and communications intelligence Secret — Select military plans Confidential — Data indicating the strength of ground forces Sensitive unclassified — Data tagged “For Official Use Only” Unclassified — Data that may be publicly released with authorization
Insufficient due diligence is one of the biggest issues when moving to the cloud. Security professionals must verify that issues such as encryption, compliance, incident response, and so forth are all worked out before a contract is signed.
Пример продукта Cisco, который реализует облачную безопасность: Cisco Tetration. Функционал крайне широк.
Когда виртуальных машин или контейнеров становится несколько тысяч (например, в Cisco несколько тысяч виртуальных машин и контейнеров используются для обеспечения нашей внутренней работы), то задача статического определения, куда можно, а куда нельзя перемещаться контейнерам и виртуальным машинам, становится неподъемной. Ровно эту задачу – автоматизацию управления виртуальными машинами, контейнерами, приложениями внутри ЦОДа и внутри облака – и решает Cisco Tetration. С помощью специальных алгоритмов он описывает структуру сети, структуру ЦОДа и облака, позволяет прописать и динамически отслеживать правила взаимодействия виртуальных машин, приложений, контейнеров между собой, блокировать их перемещения в неразрешенные места, увязывает это все с политиками доступа внутри корпоративной сети, например, с теми же самыми Cisco ISE и Cisco Stealthwatch, с защитой периметра и дает возможность оценивать уязвимость приложений и виртуальных машин, которые используются в ЦОДе. И опять же динамически, опираясь на информацию об уязвимостях, усиливать или понижать уровень защиты тех или иных корпоративных ресурсов. То есть Tetration – это инструмент, который позволяет сегментировать приложения, виртуальные машины и контейнеры внутри ЦОДа и облаков и делать это динамически.
Общая концепция – IoT устройства не должны быть доступны напрямую через Интернет т.к. мы по умолчанию не можем эти устройства защитить средствами, которые в них встроены.
При прямом доступе устройства из внешней сети безопасность IoT устройства организовать сложнее, в сравнении с промежуточным контроллером/fog edge устройством (по сути тот же самый NAT).
Технологии IoT вроде INSTEON, Zigbee, Z-Wave, LoRaWAN и многие другие не разработаны с учетом безопасности, хотя и были улучшены в этом контексте в сравнении с изначальными реализациями. Например современный, Zigbee полагается на безопасность на основе сервисов безопасности стандарта IEEE 802.14.5 MAC layer, который поддерживает AES шифрование.
Большинство устройств сегмента IoT дешевые, крайне ограничены в количестве памяти/вычислительных ресурсах и не поддерживают развивающиеся технологии безопасности/шифрования, бекапы соединений и проч
При этом большинство таких устройств требуют безопасное удаленное управление при развертывании и во время эксплуатации
Большим вопросом является устойчивость шифрования с учетом, что многие IoT устройства разработаны на десятилетия работы (напр. умные счетчики)
Физическая безопасность устройств для IoT девайсов – вопрос который поднимается еще более серьезно в сравнении с “обычными” устройствами
Для IoT устройств справедливы большинство атак на “обычные” устройства и сервисы, но есть и особые, применимые только к IoT (мультиметры, осцилографы, UART дебагеры и даже паяльник)
многие IoT устройства часто используются сразу несколькими группами пользователей – к примеру, камеры или медицинское оборудование. В таком случае должна быть реализована авторизация, разграничены права между группами; с административной точки зрения – прописано кто отвечает за что
несанкционированный доступ к медицинскому оборудованию – одно из самых опасных в контексте IoT безопасности. Cisco видит решение в обеспечении безопасности еще “до” этих потенциально уязвимых устройств в случае стационарных усройств – через создание изолированного сегмента в котором эти устройства работают, в который нет доступа почти никогда и даже когда есть, строго определенным хостам и протоколам (как в органах власти и гос компаниях). Ограничение предполагается делать на базе Cisco Firepower/ISA 3000. В случае нестационарных, думаю, реализуемо аналогичное.
Безопасность отдается в угоду скорейшему выпуску продукта на рынок, поэтому многие интернет-вещи, в том числе медицинское оборудование, по умолчанию не защищены, и уже известны случаи атак на кардиостимуляторы, на дефибрилляторы, на инсулиновые помпы с подключением к Интернету, которые, к сожалению, никак не были защищены от внешних несанкционированных воздействий.
Cisco пропагандирует следующий подход: мы не всегда можем защитить саму интернет-вещь, но мы можем защитить подходы к ней. И если мы говорим о медицинских устройствах и организациях, которые используют, скажем, томографы или рентгенографическое оборудование, подключенные к Интернету, то в этом случае мы рекомендуем специальный дизайн, специальную архитектуру сети для такого рода применения. Это изолированный сегмент.Контролируемый доступ извне, разрешенное взаимодействие только с производителями медицинского оборудования в рамках так называемых технологических окон, в течение которых можно это оборудование обновлять. Контролируемый доступ изнутри, чтобы пациенты, например, лежащие в больнице, не могли подключиться к такого рода оборудованию.
Для защиты периметра сегментов, где установлены интернет-вещи, мы используем традиционные Cisco Firepower. Для агрессивных сред, в которых устанавливается промышленное или медицинское оборудование, используются наши специализированные промышленные файерволы или промышленные системы обнаружения атак под названием ISA 3000.
Пример политики безопасности для небольшой компании
Authentication system
Для аутентификации на компьютерах нам нужна централизованная система аутентификации на основе LDAP, например такая, как ActiveDirectory совместно с вводом кода из программного/аппаратного токена (2FA/MFA)
Для аутентификации на сетевых устройствах не обязательно разворачивать RADIUS сервер т.к. сетевых устройств в компании немного. Достаточно организовать доступ на оборудование по локальной учетной записи только для администраторов с помощью SSH/HTTPS на базе аутентификации паролю и/или приватному ключу.
Использовать дополнительную аутентификацию по учетной записи к базе SQL, в которой хранятся пользовательские данные.
External website security
Для шифрованного обмена данными между сайтом и клиентами для доменного имени сайта будет получен SSL сертификат (HTTPS)
Сервер с сайтом будет находиться в dmz зоне firewall за reverse proxy:
DMZ позволит разграничить внешний сайт от других внутренних ресурсов компании и при этом наложить ряд ограничений для взаимодействия извне с самим сайтом (анти-дос)
Reverse proxy позволит реализовать решение по отказоустойчивости и балансировке нагрузки для сервера с сайтом (прокси необходим т.к. ретейл – основной бизнес компании)
Internal website security
Для доменного имени внутреннего сайта будет сгенерирован собственный SSLсертификат
Внутренний сайт будет находиться внутри сети компании (за firewall)
Внешний доступ к внутреннему сайту будет ограничен использованием private адресации для внутреннего сайта
Remote access solution
Для remote-access клиентов нужно попасть во внутреннюю сеть (vpn решение на базе firewall или reverse-proxy за firewall) для взаимодействия с внутренним сайтом и другими внутренними ресурсами компании
Аутентификация в VPN/reverse proxy на основе логина+пароля/сертификата и программного/аппаратного токена (2FA/MFA)
Для доступа на ПК администраторов из под поднятого VPNможно поднять RDP
Firewall and basic rules recommendations
Использовать по умолчанию implicit deny
Использовать firewall в качестве remote-access VPN server
Включить stateful firewall для доверенной зоны
Ограничить доступ к сетевым устройствам, LDAP серверу и SQL серверу, хранящему данные пользователей, только подсетью администраторов
Создать VLAN и подсети в соответствии с группами пользователей
Laptop security configuration
FDE иintegrity check на базе TPM
На компьютеры должны распространяться корпоративные политики AD, касающиеся безопасности (подробнее ниже)
Application policy recommendations
Обновление приложений
Отключение и удаление ненужных приложений
Ограничение доступа к приложениям с помощью политик, например RBAC
Создавать backupвсех важных данных
Использование наилучших практик с точки зрения программирования (например. использование поддерживаемых версий языков/библиотек/модулей, изоляция переменных, проверка и чистка пользовательского ввода от спец. символов, уменьшение количества кода путем его переиспользования с помощью функций, так далее)
Security and privacy policy recommendations
Логгирование/разграничение доступа к данным клиентов
Отключить административные права для обычных пользователей
Политики по паролям (длина, спец символы, словарные слова, ротация)
Использовать корпоративный антивирус/binary whitelisting и host-based файрволл/ips
Регулярные тесты на уязвимости и проникновение
Регулярные обязательные обучения персонала по темам ИТ-безопасности
Intrusion detection or prevention for systems containing customer data
Внедрить системы NIDS/NIPS, HIDS/HIPS для анализа трафика сотрудников внутри сети компании. Настройка систем в случае обнаружения угроз (атаки, вирусная активность, неавторизованный скан сети) – уведомление администраторов, ограничение доступа, карантин определенных систем.
