По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Статьи по тематике устранение неисправностей связаны с определенным набором решений проблем. В случае с Linux и Unix полезно иметь некое руководство по доступным инструментам, облегчающим работу по поиску и устранению проблем. Это такой документ, который содержит основные важные команды, позволяющие облегчить жизнь администраторам Linux/Unix при возникновении проблем.
Команда "list open files" или команда lsof выглядит достаточно просто, но ее использование в качестве инструмента для устранения неполадок не так очевиден, как кажется на первый взгляд. Например, если у неизвестного процесса открыто несколько файлов, знание того, какие они есть, может помочь определить, является ли процесс легитимным.
В первой статье рассмотрим множество вариантов использования команды lsof.
Во второй статье рассмотрены рекомендации о том, как исправлять проблемы этим множеством вариаций данной команды.
Контрольные вопросы, которые следует задать себе при диагностике проблем, является предметом нашей третьей статьи. Это поможет навести порядок в хаосе, который создают некоторые проблемы.
Работа с базами данных Oracle - обычная задача администратора, и немного узнать о них и о том, как тестировать соединения с ними, - ценный инструмент, описанный в четвертой статье. Если проблема связана с подключением, отпадает потребность в вызове администратора баз данных.
В завершении нашего руководства приведена статья с инструкциями по командам, необходимым для управления дисками и разбиения их на разделы.
Команда lsof
Команда lsof - это нечто большее, чем вы можете себе представить. Узнайте обо всех возможностях ее применения для поиска и устранения неполадок.
lsof - команда Unix/Linux, которая отображает все открытые файлы или идентифицирует процессы, открытые конкретными файлами. Удобная для оценки безопасности ИС, а также для устранения проблем lsof предлагает широкий спектр параметров, позволяющие использовать её различными способами - иногда даже превосходя команду ps для просмотра процессов и команду netstat для исследования сетевых интерфейсов.
Что такое открытые файлы?
Для начала давайте рассмотрим, что такое открытые файлы и почему они вам могут быть интересны. Открытые файлы - это файлы, которые использует какой-либо процесс. Этот процесс может быть командой, которую вы выполняете, или приложением, запущенным на сервере, которым вы управляете. Открытые файлы могут включать файлы данных и библиотеки, которые предоставляют общие процедуры. Многие файлы открываются каждый раз, когда вы входите в систему. Вы можете быть удивлены их количеством. Если вам интересно, сколько файлов у вас открыто прямо сейчас, попробуйте эту команду:
$ lsof -u admin | wc -l
1715
И если вы когда-нибудь слышали, что для Unix все является файлом, вы, возможно, не слишком удивитесь, узнав, что lsof работает с такими вещами, как сетевые интерфейсы, которые большинство из нас обычно не считают файлами.
Почему нам это важно?
Иногда появляется необходимость узнать об открытых файлах, потому что вы пытаетесь удалить файл и обнаруживаете, что он уже используется. Может быть, он заполняет ваше дисковое пространство. Вам необходимо узнать, каким файлом какой процесс открыт, чтобы можно было остановить его и очистить файл. В других случаях вам понадобится узнать, что делает неизвестный подозрительный процесс, и только изучение файлов, которые открыл подозрительный процесс, может предоставить ценную информацию.
Принцип работы lsof?
При применении команды lsof без параметров в терминале выводятся все файлы, которые открыты (используются) в вашей системе. Если вы запустите lsof от своего имени, вы получите длинный список файлов, но выходные данные будут включать в себя множество сообщений об отказе в разрешении - многие из них представляют открытые файлы в файловой системе /proc, которые вам не разрешено видеть. Запустите команду от имени root, и вы увидите больше выходных данных.
Что еще интересного?
Беглый взгляд на довольно большой справочник lsof отобразит вам, что мы увидели только меньшую ее часть возможностей. lsof имеет обширный список опций.
В этой статье мы разберем наиболее полезные.
Чтобы начать работу со всеми этими параметрами, вам необходимо о том знать о возможности использования более одной опции. Для этого используйте слово OR. Таким образом, вы получаете список, объединяющий результаты указанных вами параметров. Помимо этого вы можете выбрать вариант, со служебным словом AND. В этом случае ваши опции будут применяться вместе. Другими словами, вы увидите те файлы, процессы и т. д., которые соответствуют всем указанным вами параметрам. Для применения объединения AND, добавьте в свою команду параметр -a.
Полезные параметры lsof
Примеры использования lsof с параметрами, отображены на скриншотах ниже. Они демонстрируют наиболее полезные вещи, которые вы можете применить с данной командой.
На скриншоте ниже lsof, перечисляет все процессы, у которых открыт конкретный файл:
На этом скриншоте выводится список всех процессов, у которых есть открытые файлы в определенном каталоге:
На этом скриншоте показаны файлы, открытые bash:
На этом скриншоте, но с использованием подстроки вместо полного имени процесса:
На этом скриншоте перечислены открытые файлы для определенного идентификатора процесса:
lsof помогает изучить сетевые подключения:
На скриншоте показан пример просмотра портов и/или установленных соединений.
Также можно сетевые подключения для одного конкретного источника.
Просмотр файлов пользователем
На этом скриншоте lsof просматриваем открытые файлы для конкретного пользователя:
Для просмотра открытых файлов всех пользователей, кроме определенного (здесь это root), используйте знак ^:
Перечислить идентификаторы процессов для процессов, запускаемых конкретным пользователем:
$ sudo lsof -t -u froggy
15352
15353
Завершить все процессы, принадлежащие конкретному пользователю:
$ sudo kill lsof -t -u froggy
Используйте параметр -a для использования оператора AND для объединения ваших опций вместе, помня, что это ограничивает вывод только тем, что соответствует всем указанным условиям:
Public Key Infrastructure (PKI) - это набор различных технологий, которые используются для обеспечения аутентификации источника, целостности данных и конфиденциальности для пользователя в сети. PKI использует преимущества асимметричного шифрования и использует пары открытого и закрытого ключей для шифрования данных.
В PKI открытый ключ обычно связан с цифровой подписью, чтобы добавить доверие и проверить сведения о владельце сертификата. Ниже приведен ключевой жизненный цикл в PKI:
Генерация ключа: Этот процесс определяет шифр и размер ключа.
Генерация сертификата: Этот процесс создает цифровой сертификат и назначает его человеку или устройству.
Распространение: Процесс распространения отвечает за безопасное распространение ключа пользователю или устройству.
Хранение: Этот процесс отвечает за безопасное хранение ключа, чтобы предотвратить любой несанкционированный доступ к нему.
Отзыв: Сертификат или ключ могут быть отозваны, если они скомпрометированы субъектом угрозы.
Срок действия: Каждый сертификат имеет срок службы.
Каждый день мы посещаем различные веб-сайты, такие как социальные сети, стрим, новости, спорт, блоги и другие платформы. Однако задумывались ли вы когда-нибудь о проверке подлинности веб-сайтов, которые вы посещаете? Вы, наверное, думаете, что всему, что находится в Интернете, нельзя доверять. Хотя это отчасти правда, мы можем доверять только ограниченному числу веб-сайтов, например, доверять веб-сайту вашего банка. Главный вопрос заключается в том, как мы можем проверить подлинность веб-сайтов, которые мы посещаем? Именно здесь как PKI, так и цифровые сертификаты помогают установить доверие между хостом в Интернете и нашим компьютером.
Центр сертификации
PKI играет жизненно важную роль в Интернете, поскольку многим пользователям и устройствам требуется метод установления доверия в самой ненадежной сети в мире – Интернете. Понимание компонентов, которые помогают PKI обеспечить доверие, необходимую как пользователям, так и устройствам, имеет важное значение для любого специалиста по кибербезопасности.
Вы можете рассматривать PKI как набор процедур, правил, аппаратного и программного обеспечения, а также людей, которые работают вместе для управления цифровыми сертификатами. Цифровой сертификат-это официальная форма идентификации объекта, которая проверяется доверенной стороной. Эти цифровые сертификаты выдаются доверенной стороной в сети или Интернете. Они известны как Центр сертификации (Certificate Authority - CA).
В каждой стране существует государственное учреждение, которое обычно отвечает за проверку личности своих граждан и выдачу удостоверений личности, такой как паспорт.
Этот паспорт будет содержать важную информацию о владельце и сроке действия, например, дату окончания срока действия. В сети и в Интернете центр сертификации выполняет похожую роль и функции. В Интернете есть множество поставщиков, которые являются доверенными центрами сертификации, которые позволяют вам приобретать цифровой сертификат для личного использования. Примеры доверенных центров сертификации включают GoDaddy, DigiCert, Let's Encrypt, Comodo, Cloudflare и многие другие.
Важное примечание! Цифровой сертификат создается при объединении ключа и цифровой подписи. Сертификат будет содержать сведения о владельце сертификата, например, об организации.
ЦС выдаст объекту цифровой сертификат только после того, как его личность будет проверена. После того, как ЦС создает цифровой сертификат, он сохраняется в базе данных сертификатов, которая используется для безопасного хранения всех утвержденных ЦС цифровых сертификатов.
Важное примечание! По истечении срока действия цифрового сертификата он возвращается в ЦС, который затем помещается в список отзыва сертификатов (Certificate Revocation List - CRL), который поддерживается ЦС.
Цифровой сертификат форматируется с использованием стандарта X.509, который содержит следующие сведения:
Номер версии
Серийный номер
Идентификатор алгоритма подписи
Название эмитента
Срок годности
Не раньше, чем
Не после
Имя субъекта
Информация об открытом ключе субъекта
Алгоритм открытого ключа
Открытый ключ субъекта
Уникальный идентификатор эмитента (необязательно)
Уникальный идентификатор субъекта (необязательно)
Расширения (необязательно)
Алгоритм подписи сертификата
Подпись сертификата
Регистрирующий орган (RA)
Следующий рисунок - это цифровой сертификат, который используется для проверки веб-сайта Cisco:
Как показано на предыдущем рисунке, видно, что CA - это HydrantID SSH ICA G2, который выдает сертификат на www.cisco.com на срок действия с 20 сентября 2019 года по 20 сентября 2021 года.
Как показано на следующем рисунке, цифровой сертификат содержит дополнительную информацию, которая хранится с использованием стандарта X.509:
Далее давайте рассмотрим, как создается цифровая подпись и ее роль в PKI.
Цифровая подпись
При совершении деловых операций на документах требуется подпись, чтобы гарантировать, что сделка санкционирована соответствующим лицом. Такая же концепция требуется в сети, так что цифровая подпись отправляется вместе с сообщением на конечный хост. Затем узел назначения может использовать цифровую подпись для проверки подлинности сообщения.
При использовании PKI используются следующие алгоритмы для создания и проверки цифровых подписей:
DSA
RSA
Elliptic Curve Digital Signature Algorithm (ECDSA)
Чтобы создать цифровую подпись, между Алисой (отправителем) и Сергеем Алексеевичем (получателем) происходит следующий процесс:
1) Алиса будет использовать алгоритм хеширования для создания хэша (дайджеста) сообщения:
2) Затем Алиса будет использовать свой закрытый ключ для шифрования хэша (дайджеста) сообщения:
Цифровая подпись используется в качестве доказательства того, что Алиса подписала сообщение.
Чтобы лучше понять, как используются цифровые подписи в реальной жизни, давайте представим, что в сети есть два пользователя. Алиса хочет отправить Сергею Алексеевичу сообщение. Алиса может использовать цифровую подпись с сообщением, чтобы заверить Сергея Алексеевича в том, что сообщение исходило именно от нее. Это шаги, которые Алиса будет использовать для обеспечения подлинности, целостности и неотрицания:
Алиса создаст пару открытых и закрытых ключей для шифрования данных.
Алиса даст Сергею Алексеевичу только открытый ключ. Таким образом, закрытый ключ хранится у Алисы.
Алиса создаст сообщение для Сергея Алексеевича и создаст хэш (дайджест) сообщения.
Затем Алиса будет использовать закрытый ключ для шифрования хэша (дайджеста) сообщения для создания цифровой подписи.
Алиса отправит сообщение и цифровую подпись Сергею Алексеевичу.
Сергей Алексеевич будет использовать открытый ключ Алисы для расшифровки цифровой подписи, чтобы получить хэш сообщения.
Сергей Алексеевич также сгенерирует хэш сообщения и сравнит его с хэшем, полученным из цифровой подписи Алисы. Как только два значения хэша (дайджеста) совпадают, это просто означает, что сообщение подписано и отправлено Алисой.
Цифровые подписи используются не только для проверки подлинности сообщений. Они также используются в следующих случаях:
Цифровые подписи для цифровых сертификатов: это позволяет отправителю вставить цифровую подпись в цифровой сертификат.
Цифровые подписи для подписи кода: это позволяет разработчику приложения вставить свою цифровую подпись в исходник приложения, чтобы помочь пользователям проверить подлинность программного обеспечения или приложения.
На следующем рисунке показан пример приложения, содержащего цифровой сертификат:
На следующем рисунке показана дополнительная проверка цифровой подписи подписавшего:
Система доверия PKI
Ранее мы узнали, что организация может получить цифровой сертификат от доверенного центра сертификации в Интернете. Однако во многих крупных организациях вы обычно найдете корневой ЦС и множество промежуточных ЦС. Корневой ЦС отвечает за создание первичного цифрового сертификата, который затем делегируется каждому подчиненному ЦС или промежуточному ЦС. Промежуточный ЦС будет использовать цифровой сертификат корневого сервера для создания новых цифровых сертификатов для конечных устройств, таких как внутренние серверы.
На следующем рисунке показана иерархия корневого и промежуточного ЦС:
Использование этого типа иерархической структуры снимает нагрузку с корневого центра сертификации по управлению всеми цифровыми сертификатами в организации. Некоторые из этих обязанностей делегированы промежуточным серверам ЦС в сети. Представьте, что в вашем головном офисе вы развернули корневой ЦС, а в каждом удаленном филиале развернули промежуточные ЦС. Следовательно, каждый промежуточный ЦС отвечает за управление сертификатами своего собственного домена или филиала. Это также снижает риски взлома корневого ЦС злоумышленником, так что в случае взлома промежуточного ЦС корневой ЦС может быть отключен от сети, не затрагивая другие конечные устройства или промежуточные ЦС.
В небольших сетях можно развернуть один корневой ЦС для предоставления цифровых сертификатов каждому конечному устройству, как показано на следующем рисунке:
Как показано на предыдущем рисунке, одним ЦС легко управлять. Однако по мере роста сети наличие единственного центра сертификации в сети не позволит легко масштабироваться, поэтому необходимо использовать иерархическую структуру с корневым центром сертификации и промежуточными (подчиненными) центрами сертификации.
Недавно я просматривал некоторые общедоступные репозитории Google на их GitHub. И я заметил, что у них есть репозиторий для непрерывного фаззинга. Я понятия не имел, что такое фаззинг, не говоря уже о непрерывном.
Что же такое фаззинг?
Фаззинг (иногда его называют нечетким тестированием) – это способ автоматического тестирования программного обеспечения. Обычно фаззер вводит в программу большое количество неправильных или случайных входных данных. Таким образом пытаются вызвать сбои, ошибки, утечки памяти и т.д.
Обычно фаззинг лучше всего работает с программами, которые принимают входные данные, такие как веб-сайты, которые могут запрашивать ваше имя или возраст.
Можно попробовать вводить самые различные строки, чтобы попытаться вызвать какие-то проблемы, например, что-нибудь вроде такого: «Power?????????????????? ? ?h ? ??» (это когда-то вызвало аварийный сбой iOS), «??????h??e???????? ???????N??e??z?????p??????e????r????????d??????i??????a?????n?? ?????h??i??v?????-?????m???i????n???? ????????????f ????????c?????????a?????????s?.?? ?Z????????a?????l?????g????????o??.?», «?» или «undefined».
В целом идея фаззинга заключается в том, чтобы попытаться найти пограничные случаи в кодовой базе. Его используют для того, чтобы убедиться, что синтаксический анализ данных, их прием, сохранение и чтение не вызывают ошибок.
Это довольно полноценный тест, поскольку вы можете протестировать весь процесс хранения, например, пробела нулевой длины (U+200B в Юникоде) на своем сайте, чтобы проверить, возникнут ли какие-то проблемы.
Некоторые пытаются внедрить код в поля ввода (это часть фаззинга, которая называется «внедрение кода»), например, в качестве имени.
Злоумышленники не заинтересованы в том, чтобы вы тестировали нестандартный ввод, так как вы можете обнаружить ошибки, которые нарушают работу приложения, а они могли бы использовать их для кражи данных или повторного сбоя в вашем приложении/сервере.
На GitHub есть список под названием «Big List of Naughty Strings» («Большой список сомнительных строк»). Это список строк, которые с большей долей вероятности вызовут проблемы.
Вы можете взглянуть на некоторые в файлах .json и .txt и почитать некоторые комментарии, чтобы понять, почему именно эти строки вызывают проблемы.
Например, некоторые строки написаны вверх ногами «u?op?p?sd?». Есть строки, которые могут быть помечены как ненормативная лексика или как неприемлемые, но на самом деле они к этому не имеют никакого отношения (это называется проблемой Скантропа). И даже есть такие строки, которые могут раскрыть системные файлы, если они вдруг будут проанализированы плохо настроенным синтаксическим анализатором XML.
Кто использует фаззинг?
Как я уже говорил, фаззинг используется в процессе тестирования программного обеспечения для поиска ошибок в ваших программах. Но он также применяется в кибербезопасности и при взломах.
Что касается применения в кибербезопасности, то здесь хакеры пытаются пересечь границу доверия. Граница доверия – это место в компьютерных системах, где данные из доверенного источника передаются из одной области в другую.
В качестве примера давайте представим, что вы получаете имя пользователя в клиентской части, убеждаетесь, что оно является допустимым, а затем передаете его на серверную часть. Ваша граница доверия – это воображаемая линия, по которой данные передаются от клиента к серверу.
Если ваша серверная часть просто «доверяет» данным и не проверяет их (поскольку клиент уже проверил их!), то это может стать проблемой. В случае, если хакеры смогут пройти проверку клиента, они станут поставщиками доверенных входных данных и смогут попытаться вставить туда вредоносные строки.
Именно в этой ситуации фаззинг может посодействовать выборочной проверке, чтобы убедиться, что вы можете выявлять эти проблемы.
Допустим, кто-то должен был фаззить Google Chrome. Один из способов это сделать – запустить браузер в инструменте отладки для того, чтобы отслеживать команды, которые выполняет Chrome, и профилировать его управление памятью.
Позже хакеры направляют программу Chrome, за которой они наблюдают, на один из своих серверов. Их серверы создают миллионы различных веб-страниц, которые Chrome будет загружать. Все эти веб-страницы немного отличаются с точки зрения JS, CSS и HTML. Это нужно для того, чтобы попытаться сломать Chrome, который профилируют хакеры.
Эти хакеры могут осмысленно запускать эти автоматические тесты в течение нескольких месяцев, собирать огромный список журналов Chrome (сбои, любые переполнения памяти и т.д.) и пытаться выяснить, что вызвало сбой.
Просто заставить Chrome «рухнуть» не является их конечной целью. Как только эти хакеры узнают, какие входные данные вызывают сбои, они также могут выяснить, почему эти данные вызывают сбои, и проанализировать, могут ли они использовать эти эксплойты, чтобы исполнить свой зловещий план, или получить доступ к чему-то, к чему доступа у них не должно быть.
На сегодняшний день Google фаззит свои приложения на 30 000 виртуальных машинах! Таким образом, вы вряд ли добьетесь какого-либо успеха, поскольку они очень сильно постарались.
OSS-Fuzz от Google обнаружил более 25 000 ошибок в коде Google Chrome и примерно 22 000 ошибок в других общедоступных кодовых базах, которые используют OSS-Fuzz.
Итак, вернемся к основному заголовку. Кто использует фаззинг? Держу пари, что почти все компании, которые должны защищать свои цифровые активы или информацию, либо наймут тестировщиков для фаззинга своих продуктов, либо будут делать это самостоятельно.
Заключение
Я надеюсь, что эта статья помогла вам понять, что такое фаззинг и для чего он применяется.