Security

Взлом 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.

• Отсутствие 2FA для ssh (я после этой истории поставил 😉)

[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.

 

 

Большая часть взята из прекрасного базого курса Coursera по безопасности. 

• CIA (confidentiality, integrity, availability) – ключевые аспекты безопасности. Каждый из аспектов можно раскрыть подробнее, например целостность подразумевает защиту от порчи, подмены (имитозащиту) данных.

• CIA - triad of confidentiality, integrity, and availability is at the heart of information security. Confidentiality" signifies that data is only viewable by those authorized to view it; "Integrity" denotes that data won't be manipulated or corrupted; and "Availability" means that services remain reachable and available.

• Атаковать сложнее чем защищать – атакующему зачастую достаточно провести успешно только одну атаку из 100, чтобы взломать систему. При этом защищающийся может успешно отразить 99 атак и система все равно будет взломана.
• Risk – возможность понести потери в случае атаки на систему. Безопасность вся основывается на рисках – определение рисков, определение вероятности атак, разработка/проектирование систем для минимизации рисков этих атак (простейший пример из жизни – переход дороги). В контексте безопасности есть аксиома, что невозможно полностью исключить риск (полностью безопасная система – отключенная от сети, питания, к ней нет доступа ни у кого). Лучшее, что можно сделать, это идентифицировать риск, принять меры по уменьшению и мониторить.

Security is all about determining risks or exposure understanding the likelihood of attacks; and designing defenses around these risks to minimize the impact of an attack. 

• • Risk assessment (оценка рисков) – начинается с threat modeling (моделирования угроз). Подразумевается идентификация возможных источников угроз (векторов атак, таких, как уязвимости) для систем (критичных систем/критичных данных) с точки зрения потенциального атакующего, приоритизация этих угроз в зависимости от вероятности и серьезности (например, для уязвимости – можно ли использовать ее удаленно, вероятность ее использования, тип доступа, который получит атакующий в результате эксплойта). 

Threat modeling is the process of identifying likely threats to your systems or network, and assigning them priorities. This is the first step to assessing your security risks.

Things to consider when evaluating a vulnerability are how likely it is to be exploited, the type of access an attacker could get, and whether or not the vulnerability is exploitable remotely.

• Trade-off (компромис) – во многих темах безопасности встречаются темы компромиссов между безопасностью и удобством:
  • безопасный  пароль ! = пароль который легко запомнить,
  • максимальная длина ключа != максимальная скорость работы,
  • цена/безопасность аппаратной реализации != цена/безопасность программной
  • безопасность 3FA != удобству 1FA
  • и так далее

Из комментов:
Помню, как-то один прожектманагер, когда я заикнулся о том, как делать авторизацию, заявил: «Как говорил X X-ич X-ов, когда речь заходит о безопасности, работа останавливается.» Кто такой этот хрен, которого он цитировал, я так и не выяснил, да и имя сразу же забыл, но имею основания полагать, что такая точка зрения весьма распространена, и вертеть на х.ю вопросы безопасности как раз-таки входит в бестпрактисы дефективных манагеров. 

• Vulnerability (уязвимость) – недостаток в системе, который может быть использован для компроментации системы
• 0-day vulnerability – уязвимость нулевого дня – уязвимость, которая неизвестна производителю продукта, но известна хакеру. 0 дней подразумевает за сколько нужно ее починить (или сколько дней известно о уязвимости) 😀
• Exploit – софт, который использует уязвимость в системе безопасности
• Threat – угроза использования уязвимости (возможная атака)

– Attack vector (вектор атаки) – метод или механизм, которые атакующий может использовать для атаки сети/системы. Примеры векторов атак – вложения в почте, сетевые протоколы/сервисы.

An attack vector can be thought of as any route through which an attacker can interact with your systems and potentially attack them.

– Attack scope (совокупность векторов атаки) – совокупность векторов атак

The attack surface describes all possible ways that an attacker could interact and exploit potential vulnerabilities in the network and connected systems.

• Attack – непосредственно атака на систему
• Defense in depth (эшелонированная защита) – концепция наличия нескольких наложенных систем защиты. Может быть реализована даже в рамках одного продукта (например, Firewall). Нельзя полагаться на одну систему (SPOF). Отказоустойчивость в вопросе безопасности зачастую так же критична (а иногда и критичнее), чем работа непосредственно сервиса. Причем система может не упасть и ты не будешь знать что она не работает, а кто-то тем временем будет пользоваться уязвимостью в ней. К примеру,
  • best practice настраивать и sshd_config и iptables для защиты подключения по ssh на сервер
  • как бы плохи антивирусы не были, они хорошо защищают от популярных известных атак (модель blacklist). Конечно, с точки зрения безопасности лучше иметь binary whitelisting software (bit9) – который будет запрещать все, кроме того что явно не разрешено (концепция implicit deny ниже), но это очень неудобно, особенно если он не полагается на signing PKI (концепция trade-off выше ;)), но недостаток есть и у них – если доверять всему подписанному, не смотря внутрь, то, в тот момент, когда подделают подпись – тебе хана (примеры подобных атак были).
  • То же самое и про firewall – помимо классических сетевых устройств, должны быть и host-based firewall, у которых будут примерно такие же правила, как у классического устройства или даже больше (защита внутри сети от зараженных устройств внутри сети за файрволом) или защита mobile юзера.

Defense in depth involves multiple layers of overlapping security. So, deploying both host- and network-based firewalls is recommended.

Antivirus software operates off a blacklist, blocking known bad entities. This means that brand new, never-before-seen malware won't be blocked. Binary whitelisting software operates using a whitelist, blocking everything by default, unless it's on the whitelist.

A host-based firewall can provide protection to systems that are mobile and may operate in untrusted networks. It can also provide protection from compromised peers on the same network.

• Implicit deny/whitelisting – концепция о том, что нужно отключать ненужные сервисы (или ограничивать к ним доступ) или не давать лишние доступы (всем права админа – это не соответствует best practice концепции “least privilege”). Встречается везде и нужно использовать везде – даже на клиентских устройствах (host-based firewall). Отсюда например вытекает implicit deny в ACL (на роутерах Cisco или в iptables на INBOUNT) – концепция из сетевого мира, которая подразумевает, что все, что явно не разрешено, должно быть запрещено – это относится как к входящему трафику, так и к исходящему. Это намного более безопасная концепция, чем black listing, хотя и менее удобная. 

Implicit deny means that everything is blocked, unless it's explicitly allowed.
Every unnecessary component represents a potential attack vector. The attack surface is the sum of all attack vectors. So, disabling unnecessary components closes attack vectors, thereby reducing the attack surface.

• Internal Attack Team – есть во многих организациях, включая Google. Хакеры в белых шляпах.
• Survival Time системы без защиты, патчей (что не менее важно) и с неактуальной версией системы (Windows XP, god forbid), смотрящие “голо” в интернет – час. Потом ее хакнут. Поэтому безопасность – это важно.
• Security Education – обучение по безопасности, обязательно в крупных компаниях, которые заботятся о своей безопасности. Должно включать самые распространенные способы атаки (почтовые вложения, зеркала, пароли) и способы защиты от них. 

IT security training for employees should be designed to educate them on how to keep themselves and the organization secure, and to encourage a culture of security.

• Third party security – безопасность сторонней организации с которой взаимодействует твоя организация. Нужно проверять сторонние организации на соответствие политикам безопасности (внутренним внутри организации и зачастую даже твоим политикам) через VSAQ (Vendor security assessment questionnaries, быстрый и эффективный способ) или даже тестировать (audit, vulnerability test, pentest) их решения на безопасность. Пример VSAQ от Google.

You're trusting this third party to have reasonable security in place to protect the data or access you're entrusting them with.

A security assessment questionnaire allows you to quickly and efficiently get a broad understanding of what security measures a vendor company has in place. If available, any reports detailing penetration testing results or security assessments would also be valuable.

• Incident handling – управление инцидентами – подразумевает обнаружение проблемы, анализ/обнаружение влияния и последствий, сдерживание разрастания проблемы (containment strategy, напр. через ограничение сетевого доступа или даже отключения уязвимых хостов), устранение и восстановление последствий, изменение процедур/инфраструктуры для минимизации повторного возникновения (на основе postmortem). Все это применимо и к инцидентам, касающимся безопасности.

The first step is incident detection, because you need to be aware of an ongoing incident before you can react to it. Once you've detected the incident, you can begin containment to minimize the impact of the incident.

Ideally, you'd figure out what caused the incident in the first place, and make changes to avoid a similar incident from occurring in the future.

• Forensic analysis – криминалистический анализ логов/данных с зараженных хостов. Чаще всего делается на копии данных, во избежание изменения оригинальных данных (софт начал выпиливаться после того, как увидел, подозрительную для себя активность – напр. недоступность интернета). 
• Bastion host – хост, на входе в какую то (какие-то) IT системы. Позволяет получить доступ к каким то системам с себя/через себя, но на него наложены политики безопасности (аутентификации/авторизации, логгирования, мониторинга).

Bastion hosts are special-purpose machines that permit restricted access to more sensitive networks or systems. By having one specific purpose, these systems can have strict authentication enforced, more firewall rules locked down, and closer monitoring and logging.

• Advanced Persistent Threat (APT) – атака (не обязательно сложная) с внедрением в сеть и незаметным там нахождением существенное время. Advanced – потому что зачастую это таргетированная атака, при которой нет почти ограничения по времени/ресурсам. Чаще всего угроза постоянна – поэтому persistent. 

Виды атак

Malware (вредоносный софт)

virustotal.com – крутой сайт для проверки всем чем можно (в текущий момент 58 антивирей) файлов. 

Virus, Worm, Adware, Spyware (keylogger), Ransomeware, Trojan, Rootkit, Backdoor (софт/доступы – что может использоваться взломщиками, для возможности доступа на машину после успешного взлома), Rootkit, Botnet, Logic Bomb

Network attacks (сетевые атаки)

DHCP attacks (rogue DHCP => dhcp snooping), DNS cache poisoning (dns response flood after request => DNSSEC, версия DNS с аутентификацией и шифрованием), Data exfiltration (неавторизованная передача данных с хоста), Man-in-the-middle (session/cookie hijacking, arp spoofing, arp flood/scan, ip spoofing, rogue AP, evil twin => DAI, IPSG, 802.1x, network separation), DOS/DDOS (dns lookup, half-open attacks like syn flood; ddos = dos + botnet => flood guard)

Сетевая безопасность (наличие firewall, ids/ips, шифрование важных данных, мониторинг/алертинг, использование Wi-Fi, использование VPN, аутсорсинг управления сетью, какое оборудование используется, наличие бекапов конфигов, наличие политик по управлению инфраструктурой – обновление конфигов/софта/проч) крайне важна – сетевые устройства это первая линия обороны в IT инфраструктуре против внешних атакующих.

Your network is the foundation of your IT infrastructure and the first line of defense against external attackers.

Software Development (атаки на софт)

Баги софта (обновление языков программирования/библиотек/модулей/приложений, отключение ненужных приложений, ограничение доступа к нужным приложениям), Injection attack (изменение кода, good software principles like validating input & sanitizing data, изоляция переменных, переиспользование функций, etc): XSS (cross-site scripting – добавление зловредного кода на сайт например для session/cookie hijacking пользователей этого сайта), SQL injection (слив/изменение базы), 

Password attacks (атаки на пароли)

Password attacks (brute force, dictionary; strong passwords, 2FA, captcha, IPS)

Strong password не должен полагаться только на замену букв на созвучные буквы/цифры (типо f1rst), это учтенные вещи во многих password cracking tools. Обычно политики создания/обновления паролей задаются централизованно через AD, IPA (Identity Policy Audit) и уже AD/IPA проверяют пароли на политики – длина, наличие спец. символов, повторяемость, отсутствие словарных слов и прочее. И безусловно нельзя – передавать пароль, записывать на бумажке, использовать один пароль в нескольких системах.

A good balance of a strong but useable password is at least 8 characters, includes a mixture of punctuation characters, and rotates periodically, but not too frequently.

Social engineering (социальная инженерия)

Phishing (fake email, spear phishing, email spoofing), Baiting (usb-drive), Tailgating (access to restricted area) – чаще всего решаются через обучение персонала

Encouraging people to lock their screens when they walk away from their computer is a very important behavior to reinforce. The same goes for checking the address of the website they're authenticating to, to make sure it's not a fake phishing site. It's also important that people are comfortable asking security questions when they're unsure.

Encryption attacks (атаки на шифрование)

Brute force attack

Brute force подробнее

В brute-force мы пытаемся угадать ключ/пароль к зашифрованным или захешированным данным, защита через длину ключа/выбора хеш функции, но технически говоря, 100% защиты от brute force не существует – все упирается во времени и ресурсах, если они безграничны – любая система в теории может быть взломана. Какие рекомендации – использовать сложный пароль, использовать salt, прогонять пароль и соль через hashing алгоритм много раз (до сотен) раз. 

A brute-force password attack involves guessing the password. So, having complex and long passwords will make this task much harder and will require more time and resources for the attacker to succeed. Incorporating salts into password hashes will protect against rainbow table attacks, and running passwords through the hashing algorithm lots of times also raises the bar for an attacker, requiring more resources for each password guess.

Cryptology (криптография)

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

Steganography involves hiding messages from discovery instead of encoding them.

• Cryptology/cryptography (криптография). Шифруем что-то, чтобы не увидели другие. Реализация принципов CIA: конфеденциальность, целостность, аутентификация. Теме тысячи лет, но особенно она развивается сейчас. 
• Cryptosystem – взаимосвязь алгоритмов генерации ключа шифрования, шифрования и дешифрования данных.

• A cryptosystem is a collection of algorithms for key generation, encryption/decryption

• Cryptanalysis – криптоанализ. Попытка расшифровать данные, даже если неизвестны какие-то необходимые элементы для этого (ключи/алгоритмы).
  • Лингвистический анализ – подход для старых алгоритмов
    • Frequency analysis – практика изучения частоты появления букв в зашифрованном тексте. Frequency analysis основан на том, что в письменном языке: 1) определенные буквы встречаются чаще, чем другие (English: e, t, a, o) 2) определенные буквы чаще группируются вместе с другими (English: er, th, an, on).  Frequency analysis может быть использован для таких методов шифрования как Letter transposition/substitution т.к. они сохраняют частоту букв в шифре.
  • Математический анализ + автоматизация – подход для новых алгоритмов. Подразумевает, как вычисления на базе обычных CPU, так и на основе видеокарт или даже квантовых компьютеров. Несмотря на то, что современные криптосистемы считаются очень стойкими, риски взлома с использованием современных же методов и разработок вполне реальны (напр. квантовые вычисления и простота операции факторизации числа (разложение на множители) для них, при этом аксиома сложности этой операции для больших числе заложена например в RSA) .

It’s been said that the advent of modern computing has spelled the death of the field of cryptanalysis; but the practice is still alive and well -- it’s the methodology that’s changed as technology has transformed the landscape. As quantum computing continues to develop, there’re concerns that modern encryption could be at risk of being broken. This is because most modern encryption algorithms are based on large prime number factorization being computationally difficult, something that can be significantly sped up by quantum computing. Because of this, quantum computing would allow for significantly faster factorization and brute-force attacks on encryption keys, making the future of modern cryptography questionable in the looming quantum computing era.

• 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 символов для декодирования = начальный символ) – можно использовать тот же ключ для дешифрования, что и для шифрования. 
  • Kerckhoffs’s principle (Shannon‘s maxim, “the enemy knows the system”) – хороший шифр состоит из двух компонентов – encryption algorithm + key. Такой encryption algorithm как RSA не разберешь без PhD в математике. Ключ добавляет что-то уникальное в шифр, что с одной стороны, имея ключ, позволяет расшифровать исходные данные, с другой – не позволяет расшифровать шифр, зная даже используемый алгоритм, а во многих случаях и публичный ключ.

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

• Encryption – шифрование. Применение к исходным данным (plaindata, plaintext) какого то encryption algorithm (DES/RSA/AES) с ключем, чтобы при передаче данные были зашифрованы (cipherdata, ciphertext).

An encryption algorithm is the specific function or steps taken to convert plaintext into encrypted 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. 
    • key generation (генерация ключа) – может являться комбинацией нескольких ключей (ключ алгоритма + ключ IV). Тут появляется вопрос псевдо-рандом (см. DSA и Sony) или рандом. Генерация может основываться на базе
      • факторизации числа (number factorization)
      • эллиптических кривых (elliptic curves)
    • key exchange (распространение ключей) – для безопасного распространения симметричного ключа может использоваться ассиметричное шифрование или Diffie Hellman алгоритм (подробнее ниже)
    • повторное использование (защита с использованием initialization vector, IV)
• Random generator – Random является крайне важной темой в безопасности, т.к. многие системы безопасности полагаются на отсутствие логики в нем. 
  • Random number generator (NG) – генератор (не псевдо) случайных чисел. Обычно аппаратный, например TPM (Trusted Platform Module).
  • Pseudo-random number generator (PNG, Генератор псевдослучайных чисел) – алгоритм, порождающий последовательность чисел, элементы которой почти независимы друг от друга и подчиняются заданному распределению (обычно равномерному). В операционных системах для генерации рандома используется entropy pool – источник рандомных данных (время, состояние диска, фаза луны..), которые используют генераторы рандома. 
• Initialization vector (IV, вектор инициализации), представляет собой произвольное число, которое может быть использовано вместе с секретным ключом для шифрования данных. В результате получается схема: shared master key + one-time encryption IV key (передается открыто). Пример использования – 802.11 WEP шифрование, AES. Использование IV предотвращает повторение шифрования данных, что делает процесс взлома более трудным для хакера с помощью атаки по словарю, в попытках найти шаблоны и сломать шифр.
• Nonce – рандомная последовательность, которая может быть использована только один раз при взаимодействии (once). Часто используется в Initialization Vector (IV).

In cryptography, a nonce is an arbitrary number that can be used just once in a cryptographic communication.

Symmetric encryption (симметричное шифрование)

• Ключ для дешифрования = Ключ для шифрования (подробнее в общем разделе Криптография, шифр ROT13). Этот ключ должен держаться в секрете.

Symmetric just means that the same key is used to encrypt/decrypt. Assymetric means that one key encrypts and a different key decrypts (and that the reverse is also true).

• В сравнении с ассиметричным шифрованием легче для реализации, проще использовать, быстрее для шифрования большого количества данных. Но симметричность может быть неудобна и даже не безопасна – например
  • Ассиметричное шифрование позволяет безопасно обмениваться данными по незащищенному каналу без предварительной передачи общего ключа шифрования, как в симметричном шифровании
  • если пароль Wi-Fi украден, нужно менять пароль на всех устройствах
  • если нужно дать какой-то большой группе людей временный доступ, ты же не будешь им давать постоянный пароль, тебе нужен временный, но Virtual SSID не все роутеры поддерживают
• Многие протоколы/схемы используют как симметричное шифрование, так и ассиметричное, на основе лучших качеств обоих:
  • для обмена симметричными ключами (symmetric encryption key/shared secret) используется ассимметричное шифрование (secure key exchange is a common application for assymetric algorithms)
  • для последующего обмена (шифрования/дешифрования) данными используется симметричное шифрование на основе полученных ключей
• Симметричное шифрование бывает
  • поточным (stream ciphers) – один символ шифруется в один символ (1к1). Работают быстрее и проще для реализации, но обычно менее безопасны. 
  • блочным (block ciphers) – несколько символов (статичное количество, притом, что если данных недостаточно – добавляются) шифруется в один. Обратное от поточных. 

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, RC4, and AES are all symmetric encryption algorithms.

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, хранимым в архиве – дешифруют данные на основе этого ключа.

WinRAR has changed its encryption standard from AES 128 to AES 256 with its „RAR 5.0“ format. Thus we highly recommend using the RAR 5.0 format in order to use the stronger AES Encryption.

However, the AES – 128 Bit is strong as well and it is used by governments and military installations alike to encrypt secret classified information.
The password based key derivation function is now based on (PBKDF2) using HMAC-SHA256, the core of the WinRAR security mechanism.

WinRAR does not check a password at all. It passes a password through the hash function to set a 128/256 Bit AES encryption key and then uses this key to encrypt the file data valid until RAR 4.x format. The new RAR 5.x format detects wrong passwords even before starting extraction and does not extract garbage. RAR 5.x stores a special password hash generated by one way hash function. Consequently the knowledge of this hash does not allow to know a password of the encryption key. When password is entered RAR compares its hash to stored hash in case of no match it rejects the wrong password early. This one way hash function is intentionally slow and based on PBKDF2, therefore it does not allow to increase the brute force attack performance noticeably.

В контексте шифрования RAR стоит отметить что – всегда лучше использовать шифрования и содержимого и методанных “encrypt file names” – это вытекает из реальных взломов старых версий и того, что там используются “спец” алгоритм by Winrar (даже в новой версии).

If archive headers are not encrypted (“encrypt file names” option is disabled), file checksums for encrypted RAR 5.0 files are modified using a special password dependent algorithm to prevent third parties from guessing file contents based on checksums.

Assymetric encryption, public key cryptography (ассиметричное шифрование, Криптографическая система с открытым ключом)

• Ключ для дешфирования != Ключ для шифрования

Symmetric just means that the same key is used to encrypt/decrypt. Assymetric means that one key encrypts and a different key decrypts (and that the reverse is also true).

• Основное преимущество ассиметричного шифрования – оно позволяет организовать защищенную связь по незащищенному каналу

By exchanging public keys for encrypting data, asymmetric encryption securely exchanges information over untrusted channels.

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

Confidentiality is provided by the encryption and decryption functionality, while authenticity and non-repudiation are ensured by the signing and verification processes.

• Ассиметричное шифрование позволяет безопасно обмениваться данными по незащищенному каналу без предварительной передачи общего ключа шифрования, как в симметричном шифровании
• Многие протоколы/схемы используют как симметричное шифрование, так и ассиметричное, на основе лучших качеств обоих:
  • для обмена симметричными ключами (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).

The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions.
In such a system, any person can encrypt a message using the receiver's public key, but that encrypted message can only be decrypted with the receiver's private 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) – критичная часть в безопасности соединений в интернете сегодня. 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 клиента.

In order to issue client certificates, an organization must setup and maintain CA infrastracture to issue and sign certificates.

• Code signing certificate – используются для подписи исполняемых программ, позволяет пользователям программ проверять подпись и убедиться, что программа не изменена/создана производителем (см. MD-5 и Flame Malware Microsoft case). 

Сертификат состоит из открытого ключа отправителя, методанных (информация о владельце, времени действия, области применения ) и самое главное – электронной подписи от Certification Authority (CA), который сначала сам, используя Registration Authority (RA) (обычно CA и RA один сервер), проверяет принадлежность ключа владельцу (например, то что домен weril.me находится на том же веб-сервере, с которого идет запрос на сертификат), а потом, проверив, подтверждает принадлежность публичного ключа для других с помощью своей электронной подписи в сертификате. По сути сертификат устанавливает соответствие публичного ключа и владельца. 

Сертификат открытого ключа (сертификат ЭП, сертификат ключа подписи, сертификат ключа проверки электронной подписи - электронный или бумажный документ, содержащий открытый ключ, информацию о владельце ключа, области применения ключа, подписанный выдавшим его Удостоверяющим центром и подтверждающий принадлежность открытого ключа владельцу.

The certificate authority is the entity that signs, issues, and stores certificates.
A digital certificate contains the public key information, along with a digital signature from a CA. It also includes information about the certificate, like the entity that the certificate was issued to.

Сертификаты хранятся в central repository – это позволяет certificate management system (системе управления сертификатами) безопасно хранить и индексировать ключи, управлять ими (отзывать, выдавать). 

Стандарт X.509 описывает формат цифровых сертификатов, первично появился в 1988. Текущая версия номер 3 (RFC 2459 от 1999). Так же определяет certification revocation list (CRL)  – способ распределения списка сертификатов, которые больше не валидны. CRL представляет собой список отозванных сертификатов, который распространяется CA.

To verify a certificate, the period of validity must be checked, along with the signature of the signing certificate authority, to ensure that it's a trusted one.

CRL stands for "Certificate Revocation List." It's a list published by a CA, which contains certificates issued by the CA that are explicitly revoked, or made invalid.

Пример сертификата, на основе моего сайта.

• 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 – E8 43 – должно включать тоже самое, что и в public key (какой ключ подписан CA)
• Certificate Signature Value – подпись CA
• Certificate Fingerprint – не включается в сертификат, это значения, рассчитанные на клиенте при проверке сертификата (hash от сертификата)

 

Сертификатом может быть подписан софт – для проверки что софт является безопасным. Производитель софта подписывает софт подписывает своим приватным ключем,  подпись проверяется на хосте, который запускает приложение путем дешифрования через public key. Так же проверяется trust chain public ключа в сертификате.

 

CERTIFICATION AUTHORITY (ЦЕНТР СЕРТИФИКАЦИИ)

Электронная подпись открытого ключа делается Certification Authority. Certification Authority (Центр Сертификации, Удостоверяющий Центр) – заведомо доверенная организация. Мы, доверяя центру сертификации, устанавливаем сертификат открытого ключа получателя и начинаем с ним обмен. Валидация центра сертификации происходит по электронной подписи CA в сертификате открытого ключа. Аутентичность подписи сертификата проверяется с помощью открытого ключа CA, которой заранее (до обмена, чаще всего идет с дистрибутивом OS, причем они могут обновляться, а браузеры чаще всего используют сертификаты системы) есть в системе всех участников. Подробнее о калькуляции и работе с цифровой подписью ниже. Примером CA в мире WEB является просто крутейший Let’s Encrypt, который позволяет автоматизировать процесс получения сертификата SSL для сайта (здоровья тебе, let’s encrypt).

Для решения этой проблемы открытый ключ Алисы вместе с сопроводительной информацией (именем, сроком действия и прочим) подписывается центром сертификации. Конечно же, предполагается, что центр сертификации честный и не подпишет ключ злоумышленника. И второе требование: открытый ключ центра сертификации распространяется настолько широко, что ещё до установления связи Алиса и Боб будут иметь этот ключ, и злоумышленник ничего не сможет с этим поделать.

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

Весь PKI основан на доверии между участниками – создается chain of trust (цепочка доверия) начинающийся с Root Certificate Authority (корневого CA, который self-signed).

Корневой CA может (и делает, в случае WEB) делегировать полномочия по подписи нижестоящим CA (устанавливает в сертификате поле CA=true, что делает выданный сертификат intermediary/subordinate CA их может быть несколько по дереву) – он подписывает своим private ключем публичный ключ нижестоящему CA в виде сертификата, а тот может подписать своим клиентам (intermediary CA или end-entity/leaf certificate – сертификат без права CA, права выдачи сертификатов). При этом широкоизвестный ключ нужно иметь только корневому CA, но честными должны быть все члены цепочки. Корневые сертификаты являются self-signed (самоподписанными), такой сертификат можно сделать и самому – например, сайт без доступа в интернет даже для возможности получения сертификата (по сути это подписание своего public ключа с помощью private ключа). Такой сертификат не будет считаться валидным до тех пор, пока ты не согласишься доверять этому сертификату (в случае корневых CA – по умолчанию). 

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

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

Наконец, секретные ключи абонентов время от времени раскрываются. Поэтому, если есть возможность связаться напрямую с центром сертификации, последний должен иметь возможность отзывать сертификаты своих «подчинённых».

DIGITAL SIGNATURE (ЦИФРОВАЯ ПОДПИСЬ) или как работает Public Key Signature

CA, при выдаче сертификата, применяет hash функцию со своим private ключем к данными сертификата (публичный ключ + методанные), который он выдает. Результатом является цифровая/электронная подпись в виде hash. По сути, тут обратный процесс от описанного Базового алгоритма работы ассиметричного шифрования:

The private key is used to sign data. This allows a third party to verify the signature using the public key, ensuring that the signature came from someone in possession of the private key.

1. формируется цифровая подпись сертификата у CA: данные, в нашем случае все данные (публичный ключ отправителя + методанные), шифруются private ключем на стороне CA, с применением HASH функции (SHA1, MD5) + алгоритма шифрования (если говорить последовательно – сначала берется hash, потом он шифруется)
2. отправитель отправляет сертификат (публичный ключ + методанные + цифровая подпись CA)
3. получатель, используя public ключ CA, расшифровывает цифровую подпись и получает результат HASH функции для данных в сертификате, который рассчитан CA
4. расшифровав подпись, мы рассчитываем hash от данных (публичный ключ отправителя + методанные) в сертификате, применяя туже hash функцию, что CA
5. сравниваем значение hash из цифровой подписи, с результатом hash функции от данных в сертификате
6. если совпадает – все ок, если нет – подделка сертификата или данных

Все это прекрасно расписано в wiki (тут есть и вполне понятное формальное описание) и stackoverflow.

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

With a digital signature, you are trying to prove that the document signed by you came from you. To do that, you need to use something that only YOU have: your private key.

A digital signature in its simplest description is a hash (SHA1, MD5, etc.) of the data (file, message, etc.) that is subsequently encrypted with the signer's private key. Since that is something only the signer has (or should have) that is where the trust comes from. EVERYONE has (or should have) access to the signer's public key.

So, to validate a digital signature, the recipient

1) Calculates a hash of the same data (file, message, etc.),
2) Decrypts the digital signature using the sender's PUBLIC key, and
3) Compares the 2 hash values.
If they match, the signature is considered valid. If they don't match, it either means that a different key was used to sign it, or that the data has been altered (either intentionally or unintentionally).

У внимательного человека появляется вопрос, почему то, что зашифровано private key, расшифруется public key. Ведь по идее то что зашифровано публичным ключем расшифруется приватным (как в базовом алгоритме работы). 

My understanding was that the keys were not symmetric... that is, objects encrypted with a public key are able to be decrypted by the private key, but that this relationship did not work inversely... more specifically, I did not think objects encrypted with the private key could be decrypted by the public key. If that is indeed the case, than this definitely answers my question. 

Но ответ простой – это не ошибка и не симметричное шифрование. Так оно работает – то, что зашифровано публичным ключем, может быть расшифрованное приватным И НАОБОРОТ – то, что зашифровано приватным, может быть расшифровано публичным.

The keys work inversely to each other. Encrypted something with your public key? Decrypt it with your private key. Conversely, if you encrypted something with your private key, you decrypt it with your public. Such is the nature of asymmetric cryptography. 

Symmetric just means that the same key is used to encrypt/decrypt. Assymetric means that one key encrypts and a different key decrypts (and that the reverse is also true). 

 

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. Информация, которая позволяет аутентифицировать отправителя сообщения (authenticity) и проверить отсутствие модификации сообщения (data integrity). По сути это функциональный аналог public key signature. MAC отправляется вместе с сообщением.

A MIC can be thought of as just a checksum or hash digest of a message, while a MAC uses a shared secret to generate the checksum. This also makes it authenticated, since the other party must also have the same shared secret, preventing a third party from forging the checksum data.

В 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 (По описанию похож на симметричное шифрование):

1. Стороны обмены согласуют стартовое число (shared number). Оно должно быть рандомное, очень большое и отличаться для каждой сессии. Подразумевается небезопасным (т.е. от безопасности этого элемента не зависит система).
2. Каждая сторона выбирает еще одно крупное рандомное число, но это число уже хранится в тайне (secret number). 
3. Каждая сторона складывает shared number со своим secret number, в результате получая общее число (combined number)
4. Стороны обмениваются результатом сложения между собой. 
5. Далее стороны складывают полученные данные (combined number соседа) со своим secret number.
6. Результатом является shared number + secret numbet соседа + secret number свой. И это значение одинаково на обеих сторонах. При этом secret number обеих сторон остаются неизвестными (ну относительно неизвестными, т.к. операция вычитания из combined number потенциально украденного shared number приведет к получению secret number одной из сторон). 

ELLIPTIC CURVE CRYPTOGRAPHY (Эллиптическая криптография)

ECDH, ECDSA– вариации Diffie-Hellmen (DH) и Digital Signature Algorithm (DSA), которые работают с элиптическими кривыми

Elliptic curve cryptography (ECC, элиптическая криптография) – криптографическая система с открытым ключем, которая использует алгебраическую структуру эллиптических кривых над конечными полями для генерации безопасных ключей.

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

В отличии от традиционных систем с открытым ключем, которые используют факторизацию (разложение на множители) больших целых чисел, как сложность для инверсии public-private key системы на базе эллиптической криптографии используют дискретное логарифмирование.

Эллиптическая кривая состоит из набора координат, которые входят в алгебраическое уравнение. Такая кривая имеет несколько интересных и уникальных свойств:

• Горизонтальная симметрия (кривая вверх от х равна отраженной  кривой вниз от х)
• Любая не-вертикальная линия пересечет кривую максимум в трех местах – именно это свойство используется в шифровании

Польза эллиптических кривых состоит в том, что при они способны достигать такого же уровня безопасности, как традиционные системы с открытым ключем, при этом используя меньший размером ключ. Например, 256 битный elliptic curve key сопоставим с 3,072 битным RSA ключем. Это позволяет сильно сэкономить количество данных, которое нужно для хранения и передачи, при работе с ключами. Элиптические кривые с ключем 384 bit EC можно использовать для шифрования top secret данных в USA. Но так же в USA озабочены потенциальной уязвимостью EC к атакам на базе квантовых вычислений (однако тоже самое выше и про факторизацию числа, см поиском factorization). 

 

Hashing

Hashing или hash function – тип функции, которая принимает набор данных произвольной длины на входе и выводит фиксированный набор данных (hash/digest) на выходе. Это константа. Криптографические hash функции похожи на симметричные блочные шифры т.к. работают с блоками данных (и даже больше – многие hash функции основаны на модифицированных блочных шифрах).

Идеальная hash функция

• на разный набор входных данных производит всегда разный результат, т.е. hash от входящих данных уникален => нет вероятности коллизии, когда от разных данных будет один hash (привет, DES-3028 и Broadcom)

If two different files result in the same hash, this is referred to as a hash collision. Hash collisions aren't awesome, as this would allow an attacker to create a fake file that would pass hash verification.

• криптографическое хеширование и hash’и похожи тем, что из понятного текста появляется какая-то хрень, но hash сильно отличается от шифрования тем, что hash функция должна быть однонаправленной – не должно быть возможно из результата hash получить исходный текст.

Hash functions, by definition, are one-way, meaning that it's not possible to take a hash and recover the input that generated the hash. Encryption, on the other hand, is two-directional, since data can be both encrypted and decrypted.

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

$ echo "Hello world" | md5sum # в MacOS просто md5
f0ef7081e1539ac00ef5b761b4fb01b3
$ echo "hello world" | md5sum
6f5902ac237024bdd0c176cb93063dc4

• функция должна быть быстрой

Hash используются во многих местах, например:

• в криптографии для
  • уникальной идентификации данных. К примеру, сохранение паролей пользователей в виде hash в базе/файле like .htdigusers. Причем пароль может прогоняться через hash функцию несколько раз, в некоторых случаях с тысячами итераций. 
  • проверки целостности
  • цифровых сертификатах
• Hash таблицы используются для ускорения lookup в таблице
• для идентификации (для удаления, просто обнаружения, etc) дублирующихся данных
• в оборудовании (например, сетевом), для экономии памяти

Так как применение абсолютно разное, существует огромное количество разных hash функций, в том числе “самописных” (привет еще раз DES-3028 и Broadcom).

rainbow tables (радужные таблицы) – используются хакерами для ускорения процесса восстановления паролей из украденных hash. Такая таблица представляет собой просто предрасчитанную таблицу из password – hash. С ней достаточно сделать lookup в таблице по hash, чтобы найти пароль, не рассчитывая пароль самому, как в случае с brute force. Такие таблицы есть в интернете для популярных паролей и хеш-функций. Например, популярный в свое время http://gpuhash.me, который активно использовался для взлома Wi-Fi и предлагал даже бесплатные проверки по своим скалькулированным заранее радужным таблицам. Защитой от таких таблиц является соль (salt) – дополнительные рандомные данные, которые добавляются к паролю перед применением к нему hash функции. В результате, в таблице, на основе которой происходит аутентификация, сохраняется и hash и salt. Поэтому общие таблицы из интернета тут не подойдут и нужно расчитывать пароль на основе hash самому, что сложно, особенно если соль большая по длине. Ранние UNIX системы использовали под разрядности соли 12 бит, что составляет 4096 возможных комбинаций соли. Получается для каждого пароля и соли в базе нужно генерировать hash для всех 4096 возможных salt. В новых системах типо Linux/BSD используется 128 бит под соль. Это бесконечность вариантов (340 + 36 нулей) и rainbow таблицы бесполезны тут. 

Instead of computing every hash, a rainbow table is a precomputed table of hashes and text. Using a rainbow table to lookup a hash requires a lot less computing power, but a lot more storage space.

 

Примеры 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. 

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. 

$ sha1sum shattered*
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf

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 меняется кардинально, даже из-за изменения/добавления одного символа.

# PART 1
$ echo 'This is some text in a file, just so we have some data' > file.txt

$ md5sum file.txt > file.txt.md5 # generate the MD5 sum for the file and store it

$ cat file.txt.md5

$ md5sum -c file.txt.md5 # you can also verify that the hash is correct, and that the original file hasn't been tampered with since the sum was made.


# PART 2
$ cp file.txt badfile.txt # create new file
md5sum badfile.txt > badfile.txt.md5 # generate a new md5sum for the new file

$ cat badfile.txt.md5 file.txt.md5 # Note that the resulting hash is identical to the hash for our original file.txt despite the filenames being different. This is because hashing only looks at the data, not the metadata of the file.

$ echo " " >> badfile.txt # add a space to the end of the file
md5sum -c badfile.txt.md5 # Now that you've made a very minor change to the file, try verifying the hash again. It should fail verification this time, showing that any change at all will result in a different hash.

$ md5sum badfile.txt > new.badfile.txt.md5 # To see how different the hash of the edited file is, generate a new hash and inspect it
cat new.badfile.txt.md5 file.txt.md5

Все тоже самое справдливо для SHA. По умолчанию генерируется SHA-1 hash, поведение можно изменить задава алгоритм через опцию -a (-a 256 для SHA-256).

shasum file.txt > file.txt.sha1
cat file.txt.sha1
shasum -c file.txt.sha1
shasum -a 256 file.txt > file.txt.sha256
cat file.txt.sha256
shasum -c file.txt.sha256

 

MIC (Message Integrity Check) – hash/digest от сообщения. По сути checksum для сообщения, который обеспечивает только целостность данных (аналог CRC) и при этом не предоставляет никакой защиты. Не путать с MAC (как с MAC address, так и с Message Authentication Check). В отличии от MAC, MIC не использует секретные ключи (т.е. не требует аутентификации) -> MIC не может никак защитить от того, атакующий изменит сообщение, пересчитает checksum и модифицирует MIC для сообщения. 

A MIC can be thought of as just a checksum or hash digest of a message, while a MAC uses a shared secret to generate the checksum. This also makes it authenticated, since the other party must also have the same shared secret, preventing a third party from forging the checksum data.

 

 

 

Applications

HTTPS – HTTP over SSL (old, 3.0 deprecated from 2015)/TLS (secure from 1.2). TLS энкапсулирует данные HTTP для их защиты, аутентификации (обычно только сервера) и проверки целостности.

TLS – Transport Layer Security. Используется не только для защиты/аутентификации в HTTP, но и во многих других местах – VoIP звонки, такие как Skype или Google Hangouts, email, instant messaging, Wi-Fi network security. Использует как asymmetric encryption (симметричный ключ), так и symmetric (данные).

SSL/TLS use asymmetric algorithms to securely exchange information used to derive a symmetric encryption key.

TLS предоставляет три вещи:

• Безопасный канал связи – передаваемые по каналу данные защищены от подслушивания
• Аутентификация – возможность аутентификации обеих сторон во взаимодействии, хотя обычно только сервер аутентифицируется клиентом
• Целостность сообщений – есть проверка на то, что данные не потерялись и не изменены при передаче

Для организации безопасного канала связи используется TLS handshake – (пример однонаправленной проверки, только сервера):

• клиент устанавливает соединение по TCP,
• отсылает TLS Client Hello (client info: максимальная поддерживаемая версия TLS, список поддерживаемых шифров, опции),
• а далее происходит отправка сервером сертификата+шифров+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 сообщениями) за пределами отведенного буфера – включая закрытые ключи/куки/данные других соединений и проч

Уязвимые версии OpenSSL читали память за пределами отведённого буфера (RFC предписывает не отвечать на такие пакеты). За пределами буфера могут встретиться любые данные, в том числе (очень редко) закрытые ключи шифрования сервера, данные других соединений, содержащие идентификационные cookie и многое другое.
Heartbleed осуществляется отправкой некорректно сформированного Heartbeat-запроса, в котором реальный размер строки очень мал, а число, символизирующее длину передаваемой строки, очень велико. Так можно получить в ответ от сервера больше всего скрытой информации. Таким образом, у жертвы возможно за один запрос узнать до 64 килобайт памяти, которая была ранее использована OpenSSL.
Heartbeat-запрос выглядит так: «Верни мне слово тест, которое состоит из 4 букв», и получает ответ «тест». Heartbleed-запрос выглядит иначе: «Верни мне слово „тест“, которое состоит из 500 букв», и получает ответ, состоящий из слова «тест» и еще 496 символов, лежащих у жертвы в активной памяти.
Несмотря на то, что злоумышленник имеет некоторый контроль над размером блока памяти, он никак не может управлять положением этого блока, и поэтому единственным способом увеличить вероятность получения ценных данных — многократный повтор эксплуатации ошибки.

 

SSH

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 ключ пользователя (который находится только у пользователя) по его открытому ключу (который хранится на сервере).

 

PGP

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. 

IPsec (Internet Protocol Security) – VPN протокол, который придуман для работы с IPv6. В оригинале IPv6 требовал обязательной поддержки IPsec для полного соответствия требованиям IPv6 (поэтому многие CPE роутеры были только IPv6 ready), в последующем это требование убрали из обязательных.

IPsec работает путем шифрования и энкапсуляции оригинального IP пакета в пакет IPsec. 

Два режима работы IPsec:

• Туннельный – шифруется и payload и IP header, IP packet весь энкпсулируется в новый IP пакет.
• Транспортный (используется, например, в Windows) – шифруется только payload оригинального пакета, IP header сохраняется оригинальный, но используется authentication header, который включает hash от данных IP пакета (включая header IP, transport, application data). Это защищает от подмены данных (включая NAT/PAT), включая данных не зашифрованного IP header. 

Фазы и работа IPsec.

L2TP (Layer 2 Tunneling Protocol) – по сути не VPN решение и не обеспечивает шифрование, но позволяет передать модифицированные пакеты из одной сети в другую энкапсулируя эти пакеты. Чаще всего реализовывается в связке L2TP over IPsec (RFC 3193). Так же может использоваться без VPN – например ISP могут предоставлять доступ в сеть на основе L2TP ;).

The tunnel is provided by L2TP which permits the passing of unmodified packets from one network to another.
The secure channel, on other hand, is provided by IPsec, which provides confidentiality, integrity, and authentication of data being passed.

Работа L2TP over IPsec:

• сначала согласовывается IPsec security association (согласование деталей безопасного подключения) – обмен ключами, публичные ключи, разделяемые секреты
• устанавливается безопасное соединение, используя Encapsulating Security Payload (ESP) – протокол из стека IPsec, который энкапсулирует IP пакет, обеспечивая конфиденциальность, целостность и аутентификацию
• устанавливается 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), АПМДЗ (Аппаратно-программный модуль доверенной загрузки) – аппаратное устройство, обычно интегрированное аппаратно в компьютер(ную систему). Есть стандарт, описывающий TPM. TPM по сути выступает как выделенный крипто-процессор для системы. TPM имеет свой RSA (или другой) ключ, который зашит в hardware во время производства (это основной недостаток TPM, производитель может знать ключ и прошить его на другое устройство). TPM бывают различных версий, Microsoft со своим решением BitLocker для FDE рекомендует использовать TPM 1.2 и выше для шифрования диска. 

Может быть реализован:

• как отдельный чип – классическим TPM, наиболее безопасная реализация т.к. в таком случае есть защита от физического взлома в виде tamper protection

хотя с использованием электронного микроскопа и оборудования с точностью микрон исследователь смог получить доступ ко всему содержимому TPM через манипуляцию с микросхемой TPM (подключился к незашифрованной data bus внутри TPM и послушал незашифрованные данные) - но это крайне сложно и требует много времени

• интегрирован в другой чип – на мобильных устройствах чаще всего сделано так, встроен в процессор или материнскую плату, несет название secure element
• виртуализирован на гипервизоре
• реализован в качестве прошики/софта

TPM предоставляют:

A TPM can be used for remote attestation, ensuring that a host is a known good state and hasn't been modified or tampered (from a hardware and a software perspective). TPMs can also seal and bind data to them, encrypting data against the TPM. This also allows it to be decrypted by the TPM, only if the machine is in a good and trusted state.

• 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”, всегда шифруются/дешифруется ключами (при пароле – получение доступа к ключу). Чаще всего операция делается незаметно для пользователя – пароль для дешифрования (для ключа дешифрования) = пароль входа в систему.

With the contents of the disk encrypted, an attacker wouldn't be able to recover data from the drive in the event of physical theft. An attacker also wouldn't be able to tamper with or replace system files with malicious ones.

FDE повсеместно используется во многих мобильных устройствах – ноутбуки, телефоны, планшетники. Но рекомендуется и для декстопов/серверов. 

Возможные реализации FDE:

• TPM – причем TPM может запрещать unlock диска если system configuration изменился (см. TPM platform integrity)
• PGP
• Bitlocker от Microsoft (Windows 10), интегрируется с TPM/USB drive или просто по паролю пользователя в систему
• 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).

Key escrow allows the disk to be unlocked if the primary passphrase is forgotten or unavailable for whatever reason.

 

 

Использование OpenSSL

OpenSSL библиотеку использовали в lab’е ниже для

1. генерации private key на базе RSA и создания public key на основе private key (key pair)
2. шифрования/деширования данных
3. генерации 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.

$ openssl genrsa -out private_key.pem 2048
Generating RSA private key, 2048 bit long modulus
................................................................................................+++
.......................................................................................................+++
e is 65537 (0x10001)

$ cat private_key.pem 
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA2CGpoeY8FZ+AiWnvo837bbahhU86991GkrbXfb4sgtGCFTMS
yjvXtlbuDr/WO6F3ANwf/H8pU+CWYAsstyqbJ96UpKGBPTKXzE0SstTTtDHNPixw

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.

$ openssl rsa -in private_key.pem -outform PEM -pubout -out public_key.pem
writing RSA key

$ cat public_key.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2CGpoeY8FZ+AiWnvo837

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:

$ openssl rsautl -encrypt -pubin -inkey public_key.pem -in secret.txt -out secret.enc

$ cat secret.enc
i!:_p3
AVh~
Y9yą35!`'Fե

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:

$ openssl rsautl -decrypt -inkey private_key.pem -in secret.enc
This is a secret message, for authorized parties only

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:

$ openssl dgst -sha256 -sign private_key.pem -out secret.txt.sha256 secret.txt

$ cat secret.txt.sha256
dv}ëi}Ь

GW"\+-IEA
QY+eOFd+i+_-@_abbi+ ~]

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:

$ openssl dgst -sha256 -verify public_key.pem -signature secret.txt.sha256 secret.txt
Verified OK

 

 

AAA

AAA (Authentication Authorization Accounting)

Authentication is proving that an entity is who they claim to be, while authorization is determining whether or not that entity is permitted to access resources.

Authentication (authn) – идентификация и проверка личности. Идентификация включена в процесс аутентификации, она позволяет описать объект уникально (например, адрес почты уникально идентифицирует объект).

Примеры систем, которые аутентифицируют клиента (и не только – чаще всего используются для полного перечня AAA): LDAP (подробнее в Directory Services), Radius (Remote Authentication Dial-In User Service), Tacacs+ (Terminal Access Controller Access-Control System Plus, Cisco protocol release as open standard 1993), Kerberos (подробнее в Directory Services). Могут контролировать доступ к любым ресурсам – сети (802.1x, VPN, Wi-Fi), серверам, ресурсам. Многие из них используют EAP (Extensible Authentication Protocol), для согласования наиболее безопасных протоколов аутентификации для работы между клиентом и сервером. Данные пользователей зачастую хранятся в базе (иногда база и RADIUS – отдельные сущности), но некоторые системы могут работать и с обычными файлами (.htdigusers). RADIUS и TACACS, помимо задач аутентификации (пользователь тот, за кого себя выдает), решают и задачи авторизации (дать доступ туда/к тем командам, но не дать туда/к этим командам).

• TACACS+ чаще используется для авторизации на самих сетевых устройствах. 
• RADIUS чаще используется для AAA процесса сетевого доступа клиентов к сетевым сервисам 🙂 Взаимодействие между клиентом и сервером обычно происходит не напрямую, а через промежуточный (relay) элемент (Wi-Fi controller, ASA, BRAS, server radius application). 

Clients don't actually interact directly with the RADIUS server; the authentication is relayed via the Network Access Server.

Примеры данных, на основе которых проводят аутентификацию – по username/password, PIN, карта, по ключу, по смс, по токену (physical/software), face ID/IRIS scan/fingerprint, связка методов (2FA). При том, что когда говорят про 2FA, обычно подразумевают два несвязанных способа аутентификации:

• по тому, что ты знаешь (пароль),
• по тому, что ты имеешь (токен, телефон, ключ),
• по тому, чем ты являешься (biometric ID – face ID/IRIS scan/fingerprint; отпечатки пальцев легко подделать с помощью клея).

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.

Пароли в правильных реализациях хранятся не в виде 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.

Токены обычно ротируют коды (пароли) каждые n секунд (60 секунд для RSA SecureID), коды являются одноразовыми (OTP – One Time Password). СМС считаются менее надежными в сравнении с токенами – они не шифруются по умолчанию, их зачастую можно перехватить при хорошей тех. подготовке (или даже просто звонке оператору), сильная зависимость от организации безопасности у оператора связи.

Токены:

• TOTP (RSA, time-based token) – в токен и на сервер включается одинаковое seed value (рандомно изначально сгенерированное значение ключа, которое хранится на сервере и на токене), далее на основе времени (которое 1) всем известно 2) должно быть относительно синхронизировано) происходит ротация ключа, причем сервер может учитывать смещение во времени у токена в рамках нескольких минут. 
• COTP (counter-based 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). Очень удобно – позволяет не хранить кучу разных паролей, не терять время пользоватля на постоянные переавторизации и обслуживание систем с паролями. Недостаток в безопасности – один взлом (напр. традиционный или новый – воровство session cookie/token/ticket) дает доступ ко всему . Поэтому SSO обычно используется только в схеме 2FA. SSO реализуется путем аутентификации на центральном сервере аутентификации (напр. LDAP, Kerberos), далее LDAP/Kerberos предоставляет cookie/token/ticket, который может использоваться чтобы получить доступ к приложениям, которые сконфигурированы с возможностью использования SSO. 

SSO - an authentication concept that allows users to authenticate once to be granted access to a lot of different services and applications. 

SSO allows one set of credentials to be used to access various services across sites. This reduces the total number of credentials that might be otherwise needed. SSO authentication also issues an authentication token after a user authenticates using username and password. This token then automatically authenticates the user until the token expires. So, users don't need to reauthenticate multiple times throughout a work day.

OpenID – open decentralized authentication system. Используется обычно в связке с OAuth. Открытый стандарт, который позволяет участвующим сайтам, известным как Relying Parties, аутентифицировать пользователей используя третью сторону (какой-то сервер аутентификации, identity provider). Похожая на SSO вещь, но аутентификация зачастую не сквозная. В результате сайты аутентифицирует пользователей, не требуя от пользователя данных и не требуя реализации аутентифиции на самом сайте. Так же пользователи могут посещать сайт, не создавая аккаунт. Хотя это зачастую и сложно реализовать/поддерживать, это очень удобно для клиента, который не хочет плодить сущности без нужды. Для работы сайту нужно создать shared secret с провайдером и все (используется для обмена сообщениями). После редиректа клиента, в результате успешной авторизации у третьего лица и подтверждения что клиента хочет авторизоваться на сайте, сайт получает факт успешной аутентификации и какие-то данные (email/phone) + токен (не пароль).

OpenID allows authentication to be delegated to a third-party authentication service.

Authorization (authz) – выдача полномочий на основе аутентификации (куда имеет доступ аутентифицированный entity). 

OAuth – популярный сервис, похожий на OpenID. Схема работы очень похожа на OpenID, только вместо аутентификации, сайт получает какой-либо доступ от имени пользователя (например, отправлять сообщения/почту). Обычно OpenID используется совместно с OAuth – OpenID Connect это уровень аутентификации, встроенный в OAuth 2.0. По сути как RADIUS и TACACS, объединение задач аутентификации и авторизации.

OAuth is an open authorization protocol that allows account access to be delegated to third parties, without disclosing account credentials directly.

В отличии от чистого OpenID провайдер OAuth авторизации знает все о том, кто решил проверить клиента, так же OAuth привязан к конкретному провайдеру, в отличии от OpenID. И это огромный плюс для таких крупных игроков как google/facebook/vk. Полезно для небольших сайтов, например блогов – можно только таким пользователям давать возможность комментирования.

Пример совместной работы OpenID и OAuth.

 

ACL (Access Control Lists) – бывают не только на сетевом оборудовании, но например в файловой системе (разграничение по правам в Windows тоже делаются через Access Control Lists). Папка или отдельный файл может иметь список лиц/групп-лиц, которые могут иметь те или иные (R/W/E) права к папке/файлу. Индивидуальные разрешения для объекта называются Access Control Entries, они составляют ACL. 

 

Accounting – сохранение данных о том, куда ходил/что делал пользователь в системе. Критичным компонентом accounting является Аудит, потому что сам запись в accounting не означает, что кто-то его смотрит (как с мониторингом). TACACS используется как syslog – по сути кто что ввел. RADIUS accounting часто используется для биллинга ISP – он записывает длину сессии, местоположение клиента, bandwith (или другие выделенные сетевые ресурсы), количество переданных данных (в обе стороны), эти данные могут использоваться для анализа достижения квоты (ограничить доступ в это время, ограничить полосу когда выкачал столько то).

Accounting involves recording resource and network access and usage. Auditing is reviewing these usage records by looking for any anomalies.

 

 

Network security

Network hardening – процесс улучшения безопасности сети путем уменьшения потенциальных рисков через конфигурационные изменения и соблюдение политик. Implicit deny, monitoring & analyzing traffic. 

Мониторинг трафика (в том числе возможно и с клиентских устройств и приложений, не только логов с файрвола и аутентификаций; полезно и при разборе уже состоявшихся взломов в рамках post-fail analysis/post-mortem, чтобы предотвратить повтор/понять масштаб взлома) и анализ логов (причем чаще всего автоматический анализ, не ручной) крайне важен т.к. сначала нужно понять корректные паттерны поведения пользователей в сети, чтобы потом понять нетипичные, которые возможно говорят о взломе/заражении.

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

Centralized logging is really beneficial, since you can harden the log server to resist attempts from attackers trying to delete logs to cover their tracks. Keeping logs in place also makes analysis on aggregated logs easier by providing one place to search, instead of separate disparate log systems.

В контексте того, что нужно логгировать и сколько хранить, нужно найти середину:

• слишком много данных очень часто плохо – во первых дорого для хранения, во вторых избыточные “мусорные” данные зачастую не позволяют найти важное
• слишком мало – тоже плохо, можно не слоггировать то, что нужно было логгировать

SIEMS – Security Information and Event Management System – по сути централизованный сервер логов для СБ, с возможностью анализа логов. Примеры: rsyslog, Splunk Enterprise Security, IBM Security Qradar, RSA Security analytics.

Технология SIEM обеспечивает анализ в реальном времени событий (тревог) безопасности, исходящих от сетевых устройств и приложений, и позволяет реагировать на них до наступления существенного ущерба

Системы по автоматическому анализу логов (logs analysis system, например Splunk):

• часто лог системы позволяют нормализировать данные из разных источников (например на входе поменять YYYY-MM-DD на DD.MM.YYYY), зачастую позволяя реализовать correlation analysis (анализ взаимосвязей событий) между разными системами

Logs from various systems may be formatted differently. Normalizing logs is the practice of reformatting the logs into a common format, allowing for easier storage and lookups in a centralized logging system.

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

 

 

802.1x – IEEE стандарт использующий EAP (Extensible Authentication Protocol). Поэтому часто называется EAP over LAN (EAPOL). Не защищает от подслушивания, для этого надо использовать MACsec (802.11ae). Изначально придуман для Ethernet, но поддерживает и другие типы среды (Wi-Fi, fiber). EAP по своей природе поддерживает огромное количество разных методов аутентификации, один из самых часто используемых в 802.1x является EAP-TLS. EAP-TLS предоставляет mutual authentication (cleint & server). Часто используется в enterprise WLAN.

The client and server both present digital certificates, which allows both sides to authenticate the other, providing mutual authentication.

Схема работы 802.1x похожа на схему работы обычного RADIUS – клиент (EAP supplicant) взаимодействует с сервером через relay (switch/AP). Relay на основе ответа сервера предоставляет доступ. При этом relay взаимодействует с клиентом по 802.1x (и для клиента является по сути сервером), а с сервером аутентификации по RADIUS. При аутентификации может использоваться сертификаты (софтовый или даже ключи в TPM), пароль (ISP), сертификат + пароль, токен и все что угодно. 

Flood guards – обеспечение защиты от DoS/DDoS. Обычно реализуется на Firewall/Enterprise Router/IPS/IDS, но есть и open source продукты для небольших организаций, например failed2ban (подробнее в статье iptables). Он обнаруживает атаки по общему паттерну (SYN flood/UDP flood), при достижении порога генерируется alert или даже предпринимаются автоматические меры (activation threshold) – напр. блокируется трафик на определенное время.

A flood guard protects against attacks that overwhelm networking resources, like DoS attacks and SYN floods.

 

Network separation – разделение сети на разные элементы, полезно в сетевой безопасности (разные vlan, подсети, vrf, контексты) – можно изолировать проблемы, проще мониторить трафик между элементами и проч.

 

Firewall – критичный элемент для защиты сети. Могут быть как отдельные устройства standalone firewall, функционал встроенный в устройства integrated router, так и софт на каждом хосте host-based firewall (обычно оба решения, hbf встроен во все OS сегодня).

Using both network- and host-based firewalls provides protection from external and internal threats. This also protects hosts that move between trusted and untrusted networks, like mobile devices and laptops.

Вендоры:

• Cisco FirePower (FP, FTD – Firepower Threat Defence, FTC – Firepower Management Center) – ngFirewall на базе ASA + snort. Первоначально девайсы склеивались как разные сущности – управление/прошивки/ключи были разные разные (по примеру интеграции catalyst, aironet, meraki). Сейчас уже интеграция едино и через веб NMS – без CLI и локальной веб на базе java. Весь основной функционал ASA уже перенесен в веб. Из консоли конфига нет, только show и debug. В целом по практике FirePower не особо хвалят. Особенно в контексте организации high availability (резервирования) железок – хардварные сложно/глючно (splitbrain от фазы луны, причем легко не починишь – не как в доке “нажмите кнопку resolve split-brain и активный станет активным/секнодари сотрет лишнее”), виртуальные вообще невозможно объединить.

какое же г-но Cisco сделала из своего жалкого подобия попытки догнать Palo Alto. Поставил в лабе кластер из двух виртуальных FTD и одного FMC, проработало пару дней, активная нода упала и не поднимается, перезагрузил - теперь висит в состоянии unknown - вторая нода слава Богу продолжает работать. Когда пушишь конфиг, можно идти чаек попить. При том что конфиг-то практически пустой, так несколько строчек лабовских тестов. Народ в циско-группах пишет что у некоторых обновления конфига занимает по 20 минут, при этом что самое смешное - снорт перегружается и обрывает все активные сессии. Браво, я такого от корпоративного фаерволла не видел со времен 2002-го года и красных WatchGuard-ов.
В общем, продолжаю наблюдать и понимаю, почему циска вылетела из квадранта лидеров, где прочно засели Palo Alto Networks

• PaloAlto – очень хороши.
• Cisco ASA – классика жанра. Есть vASA (как просто L4 firwall неплох). pbr появились на asa в урезанном виде, но gre так и нет. ASR лучше ASA по производительности NAT.
• CheckPoint – многие банки используют. В целом ок.
• Fortigate – тоже многие используют, хвалят железку.
• WatchGuard

 

ngFirewall обычно поддерживает огромное количество функционала.

• Fw
• Ids/ips
• App filter
• App trust (рейтинг доверия к app)
• App content (skype file transfer)
• Antivir integration
• Ad integration – Active Directory, OpenLDAP (ограничение доступа по учетным записям в LDAP; доступ на основе учетных записей через captive portal, clientless VPN, VPN, etc)
• URL filtering
• Ssl inspect часто уже аппаратно, нужно чтоб серт был установлен на хосты, есть баги с какими то аппами (dropbox например, используя ssl pinning, проверяет что серт ее компании дается, а не какой-то промежуточный файра/антивира)
• Antibotnet/ddos

 

IDS/IPS – устройства, которые мониторят (и не только – IPS) безопасность сети, полагаются на packet capture/analysis. Срабатывают на подозрительные паттерны (signature based detection, техника похожая на антивирус) трафика, подозрительное поведение пользователей (начал выкачивать всю базу после удаленного подключения), подозрительное поведение систем (с сервера http открылся неизвестный коннект во внешнюю сеть не по http протоколу). Под паттернами подразумеваются уникальные характеристики известного опасного трафика (особая последовательность пакетов, пакеты с определенными значениями в header – запросы к определенным IP/port/app, анализ клиентского поведения – доступ с внешней системы, потом доступ к базе и интенсивный сетевой обмен). Недостаток таких систем такой же как у антивирусов – blacklisting модель, которая подразумевает, что если атака неизвестна для производителя IDS/IPS (нет сигнатуры), значит с большой вероятностью она не будет заблокирована. Кроме того, возможны false-positive срабатывания (срабатывание защиты на легитимные действия/трафик). 

An IDS only detects intrusions or attacks, while an IPS can make changes to firewall rules to actively drop or block detected attack traffic.

Через IPS обязан проходить трафик, в теории он может работать в связке с Firewall (когда происходит событие создавать правила на Firewall), но это не позволит заблокировать первичные пакеты, которые посчитались опасными. Так же как Firewall (а иногда функционал включен в Firewall), IDS/IPS системы могут быть как network based (NIDS/NIPS), так и host based (HIDS/HIPS). Не защищают от всего (как и антивирусы), т.к. всегда есть атаки нулевого дня. Можно задавать свои правила. Система может работать в режиме обучения первое время, распознав корректное поведение и последующая анализируя на основе него. При использовании IDS/IPS всегда надо учитывать полосу и хранение. В случае IPS под вопросом так же скорость обработки/отказоустойчивость.

It's important to understand the amount of traffic the IDS would be analyzing. This ensures that the IDS system is capable of keeping up with the volume of traffic. Storage capacity is important to consider for logs and packet capture retention reasons.

При срабатывании обычно происходит аларм, данные о пакетах, на которые произошло срабатывание, сохраняются. 

У IDS/IPS есть архитектурное отличие от firewall, состоящее в том, что считается, что firewall защищает от атак извне и мониторит трафик из untrusted зон, а IDS/IPS – мониторит трафик внутри сети, мониторит весь трафик и обнаруживает проблемы уже внутри т.е. архитектурно это разные задачи. Легко обнаруживает/блокирует такие атаки как brute-force.

Обычно IDS/IPS ставится в ядре сети (точно за Firewall), через который проходит весь трафик и подключается к порту, на который настроен mirror с разных портов (хоть со всех, главное чтобы влезло и железка давала). Обычно имеет как минимум два порта – один для съема трафика, второй для management.

Популярные IDS/IPS – Snort (Cisco), Suricata, Bro NIDS. 

 

Proxy и Reverse Proxy – подробнее в статье про proxy. 

 

 

Wi-Fi Security

Сюда все из IT раздела.

WEP (Wired Equivalent Privacy) – уже через после нескольких лет использования перевод звучит как стеб. Разбирать как он работает нет смысла – его нельзя использовать (если только в качестве honey pot)

Причины: в основном из-за некорректного использования RC4 (должна быть сменяемость ключа постоянная, а не статичный shared ключ, как в WEP), слабости самого RC4, IV используемого в нем - передаваемого plain/text и небольшого по размеру.

The RC4 stream cipher had a number of design flaws and weaknesses. WEP also used a small IV value, causing frequent IV reuse. Lastly, the way that the encryption keys were generated was insecure.

WPA (Wi-Fi Protected Access) – изначально придумывался как временное решение, которое позволит заменить WEP на том же оборудовании, на котором работает WEP, через простую перепрошивку. Тут появился TKIP – temporary key integrity protocol, в нем реализованы новые (по сравнению с WEP) фичи:

• Более безопасный способ генерации ключа (используется и в 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 раз

Сам ключ может быть задан напрямую 64-значный 16-и ричный ключ или используя password ASCII 8-63 символа, который прогоняется через PBKDF2. 

• Добавлен 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 Enterprise would offer the highest level of security for a WiFi network. It offers the best encryption options for protecting data from eavesdropping third parties, and does not suffer from the manageability or authentication issues that WPA2 Personal has with a shared key mechanism. WPA2 Enterprise used with TLS certificates for authentication is one of the best solutions available.

 

 

WPA2 – добавил еще безопасности, во первых он отказался от RC4 в пользу AES (TKIP WPA2 – неполноценный WPA, по сути). CCMP (AES GCM – Counter Mode CBC-MAC Protocol) – он позволил реализовать аутентифицированное шифрование (данные конфиденциальны и аутентифицированы), через механизм authenticate & encrypt.

WPA2 uses CCMP. This utilizes AES in counter mode, which turns a block cipher into a stream cipher.

Довольно безопасный стандарт, но все таки его можно взломать в версии 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 есть таблицы.

Because the SSID is used as a salt, it should be something unique to protect against rainbow table attacks. A long, complex password will protect against brute-force attacks.

Сначала рассчитывается CBC-MAC digest, затем результирующий authentication code шифруется вместе с сообщением, используя блочный шифр (напр. AES в режиме counter, что превращает его в stream cipher, используется seed value с инкрементирующимся counter для создания key stream, который шифруются данные).

Как клиент проходит аутентификацию (four-way handshake).

1. AP отправляет nonce клиенту
2. клиент отправляет nonce AP
3. AP отправляет GTK
4. клиент отправляет 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.

You should disable WPS entirely if you can. If you need to use it, then you should use a lockout period to block connection attempts after a number of incorrect ones.

WPS бывает не только по кнопке:

• PIN entry authentication
  • клиент генерирует PIN и вводит его на AP
  • PIN зашит в прошивку AP
• NFC/USB
• push-button

Зашитый PIN в прошивку чаще всего ругают в контексте ругани WPS – его легко ломают brute force, причем метод вообще говно т.к. двумя частями отправляется pin (сначала первая часть и если она ок!!!!!!, то вторая). В результате за 11к попыток можно перебрать все варианты (без rate limit можно было взломать меньше чем за 4 часа, пока в спецификации не сделали тресхолд 3 неправильные попытки в минуту, но даже это воркэраунд = 3 дня).

The WiFi Protected Setup (WPS) PIN is susceptible to a brute force attack. A design flaw that exists in the WPS specification for the PIN authentication significantly reduces the time required to brute force the entire PIN because it allows an attacker to know when the first half of the 8 digit PIN is correct. The lack of a proper lock out policy after a certain number of failed attempts to guess the PIN on many wireless routers makes this brute force attack that much more feasible.

 

 

Packet sniffing (tcpdump, wireshark, aircrack-ng, kismet)

Port mirroring, RSPAN

Отдельные статьи:

• wireshark
• tcpdump

Обычно это происходит автоматически при запуске инструментов для снифинга, но перехват трафика требует помещение интерфейса в promiscuous (неразборчивый) режим, чтобы сетевая карта не дропала пакеты, которые не предназначены ей. В Wi-Fi карточку так же можно переместить в Monitor mode – она будет слушать даже пакеты в других (не только в подключенном) SSID и на других частотах.

 

 

Обновление ПО/системы/драйверов устройств

В контексте атак типо OpenSSL heartbleed и множества других подобных проблем с безопасностью софта (например баги с Java, Adobe Flash Player, ОС или даже драйверами устройств) крайне важны инструменты, которые будут уведомлять о новых патчах/новых версиях софта. Зачастую это встроено в антивирусы, но есть и специализируемые инструменты типо Microsoft SCCM, Puppet Labs, которые позволяют изучить какой софт глобально установлен на всех ПК и обновить его при необходимости.

As vulnerabilities are discovered and fixed by the software vendor, applying these updates is super important to protect yourself against attackers.
Software updates or patches can fix recently discovered vulnerabilities or close ones that you weren't aware of.

Общая практика – поддерживать работу только последней версии софта и запрещать явно ненужное/разрешать явно нужное. Разрешенное унифицировано обновлять (унифицировано – чтобы иметь единообразный софт везде, упростив эксплуатацию и уменьшив 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.

By having the hard drive encrypted both with the cryptographic device and with the user's password, Chrome OS ensures that the user's data can't be accessed by an attacker.

• По умолчанию все настройки выставлены “безопасными” и не нужно ничего делать – например, апдейты автоматически скачиваются и устанавливаются.

By implementing automatic updates, Chrome OS ensures that security updates are applied on time, keeping the system secure.

• Так же Chrome OS состоит из нескольких уровней безопасности, реализуя модель defence in depth (если один уровень не отрабатывает – есть другие).

Defense in Depth is the concept of having multiple, overlapping systems of defense to protect IT systems. This is exactly what Chrome OS offers.

• Каждый процесс и вкладка Chrome является уникальным процессом, изолированы на уровне ОС от остальных (sandboxing). Исключением является только данные на HDD под эти вкладки/процессы (cookie, cache, bookmarks), причем к данным одной вкладки безусловно не может обратится процесс другой вкладки.

Sandboxing refers to the fact that each tab in a Chrome browser - as well as each of the system services - runs in a separate process, completely independent of the others.

OS Recovery Mode – У Chrome OS простой процесс восстановления, в случае повреждения/изменения системных файлов система входит в режим восстановления и помогает пользователю восстановить ее.

Powerwash – позволяет легко сбросить ОС к заводским настройкам (как телефон), персональные данные восстанавливаются из облака. Причем powerwash стирает ключи пользователей отчищаемой системы из памяти, делая невозможным восстановление данных с ЖД (т.к. они шифруются данными пароля пользователя + ключами с TPM – см. ниже). 

Verified Boot

Verified Boot – проверяет целостность системы при загрузке. Если в с систему были внесены изменения – она не загрузится, вместо этого запустится процесс восстановления. Так же Verified Boot не даст загрузить систему, версия которой помечена как уязвимая.

Verified Boot is a process that verifies the integrity of the operating system being used, from start to finish. So that the user can trust that the contents of the OS come from a reliable source.

Состоит из четырех компонентов:

read-only firmware – прошивка с которой поставляется Chrome OS устройство. Изменить прошивку без физических изменений машины невозможно – прошивка защищена от удаленных атак. В прошивку включаются криптографические ключи, которые проверяет что последующий компонент (read-write fw) при загрузке из доверенного источника и что в последующем компоненте нет лишнего кода. Если проверка завершена успешна – исполняется код из read-write fw, если не успешна – read-only fw попытается восстановить систему из последнего backup read-write fw (предварительно проверив, что он валиден). Если и в backup какая то дрянь – система будет загружена в режиме восстановления (recovery mode).

If the read-only firmware can't validate either of the two versions of the read-write firmware, it will automatically start the Recovery Mode

 

read-write firmware – прошивка, которая может автоматически обновляться по необходимости. Проверяет непосредственно ОС (ядро ОС из доверенного источника) примерно таким же алгоритмом, что и read-only fw (алгоритм точно такой же – если найдено несоответствие – загружаем другой OS kernel или уходим в восстановление ОС).

If the read-write firmware can't validate either of the two kernels and their root partitions, it will automatically start the Recovery Mode

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.

A vulnerability scanner will scan and evaluate hosts on your network. It does this by looking for misconfigurations or vulnerabilities, then compiling a report with what it found.


FROM NESSUS
Today, Nessus is trusted by more than 27,000 organizations worldwide as one of the most widely deployed security technologies on the planet - and the gold standard for vulnerability assessment.

Our research team works closely with the security community to discover new vulnerabilities and provide insights into published vulnerabilities to help organizations quickly detect them in their environment.
More than 100 zero-day vulnerabilities discovered over the past 3 years. New plugins released within 24 hours of vulnerability disclosure (on average)

Nessus has the industry's lowest false positive rate with six-sigma accuracy (*.32 defects per 1 million scans).
Nessus has the deepest and broadest vulnerability coverage in the industry.
Nessus is trusted by more than 27,000 organizations, with 2 million downloads worldwide.

Примерный алгоритм работы:

1. Сканят сеть на хосты с помощью разных способов – ping sweep, port scanning
2. Детальный скан запускается на каждый обнаруженный хост
3. Делается попытка определения сервисов за портами
4. Делается попытка взлома сервисов на основе баз известных уязвимостей  и мисконфигураций (напр. неоптимальные ciphers, пароли по умолчанию. Nessus проверяет как понимаю не реальными атаками, а их моделированием на основе Nessus attack scripting language. Базу с уязвимостями нужно регулярно обновлять (ничего нового), иначе не будет скана на новые уязвимости. 
5. Отправляется репорт для последующего анализа/обработки, который включает уязвимые хосты/сервисы, уязвимости приоритезируются и категоризируются, можно почитать подробно о каждой найденной уязвимости (софтовой баги или даже неправильно настроенного сервиса или даже наличия бекдора в системе), иногда так же есть информация как можно избавится от нее/включается информация о том, есть ли возможность удаленного эксплойта найденной уязвимости и прочая важная информация для анализа.

Пример репорта из Nesus:

 

Тесты на проникновение (penetration testing)

Тесты на проникновение (penetration testing) – практика попытки взлома системы/сети для проверки корректности работы систем безопасности. Хакеры в белых шляпах. Использование эксплойтов и систем типо hacking linux (kali linux). 

Penetration Testing is the practice of attempting to break into a system or network to verify the systems in place.

Осуществление регулярных 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) – реализовывать и поддерживать безопасные системы и приложения. К примеру, защищать все системы от вредоносного ПО, регулярно проверять наличие антивирусного ПО на системах, обновлять антивирусное ПО, обновлять ПО (особенно security patches, в пределах месяца после выпуска), иметь логи.
• Реализация мер по разграничению доступа (access control measures) – ограничение к данным cardholder политикой business need-to-know (проверяем что доступ к данным действительно нужен), аутентифицировать доступ к системам (пароли, 2FA), ограничить физический доступ к данным.
• Регулярно мониторить и тестировать сети (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 (политики по работе с конфиденциальными данными) – подразумевают процедуры (кто, как, по каким причинам, где хранятся данные и где их нельзя хранить) и средства по обеспечению (шифрование; логгирование/аудит/информирование; ограничение доступа; доступ к данным, для тех, у кого есть доступ, только через запрос на доступ к данным; временной лимит на доступ) безопасного доступа к конфиденциальным данным. 

Privacy policies are meant to govern the access and use of sensitive data for authorized parties. Sensitive data should be treated with care so that an unauthorized third-party doesn't gain access. Ensuring this data is encrypted is an effective way to safeguard against unauthorized access.

 

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

Authentication system

• Для аутентификации на компьютерах нам нужна централизованная система аутентификации на основе LDAP, например такая, как ActiveDirectory совместно с вводом кода из программного/аппаратного токена (2FA)
• Для аутентификации на сетевых устройствах не обязательно разворачивать 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)
• Для доступа на ПК администраторов из под поднятого VPNможно поднять RDP

 

Firewall and basic rules recommendations

• Использовать по умолчанию implicit deny
• Использовать firewall в качестве remote-access VPN server
• Включить stateful firewall для доверенной зоны
• Ограничить доступ к сетевым устройствам, LDAP серверу и SQL серверу, хранящему данные пользователей, только подсетью администраторов

 

Wireless security

РеализоватьWPA2 enterprise (AES GCM encryption + 802.1x RADIUS authentication)

 

VLAN configuration recommendations

Создать 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 для анализа трафика сотрудников внутри сети компании. Настройка систем в случае обнаружения угроз (атаки, вирусная активность, неавторизованный скан сети) – уведомление администраторов, ограничение доступа, карантин определенных систем.