По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Все, кто так или иначе причастен к миру IT, точно слышал это слово из трех букв - DNS. Domain Name System это своего рода телефонный справочник, в котором указаны адреса всех веб-сайтов в интернете. Также DNS это довольно простой протокол, работающий, как правило, через 53 порт и который используется системными администраторами в буквально каждой сети - ну а куда без него? В данной статье мы не будем подробно разбирать схему работы DNS и типа DNS серверов - это мы оставим на потом.
Каждый раз когда приложение или человек пытается попасть на какой-нибудь веб-сайт, DNS запрашивает в образном "телефонном справочнике" IP-адрес этого ресурса и отправляет вас по нужному адресу.
Темой этой статьи будет некорректное использование службы злоумышленниками: в какой-то момент умные товарищи поняли, что DNS также является прекрасным вектором атаки и научились использовать DNS в целях передачи информации и команд на компьютер жертвы, и это, по сути является основным принципом DNS туннелирования.
Принцип работы DNS туннелирования на пальцах
Пять шагов DNS туннелирования:
Злоумышленник использует DNS для маскировки вредоносных действий, т.к DNS трафик в 99,99% разрешен и не проверяется;
Далее злодеи туннелирует другие протоколы (к примеру, http) через DNS
Далее они туннелируют IP-трафик и передают украденную информацию
Украденную информация снова преобразуют в удобный для восприятия вид
Установленный туннель используют для передачи вредоносного ПО
Обратите внимание на скриншот - я запросил IP-адрес gismeteo.ru. В терминах технологии DNS, вы сделали запрос типа А (от слова Address). Типов подобных запросов существует несколько, и чуть ниже я попробую это продемонстрировать.
В любом случае, под капотом у DNS работает простая схема клиентский запрос на сервер, который в свою очередь отвечает клиенту обратно. А что если можно было бы "зашить" сообщение внутрь запроса?
Представьте себе, что хакеры контролируют DNS сервер: в таком случае, они смогут просто собирать всю нужную информацию без риска оказаться замеченными. Опять же - как DNS запрос может быть нелегитимным? Все привыкли к тому, что эта служба работает всегда и не несет никакой угрозы. Но если служба оказалась скомпрометированной, злоумышленники могут фальсифицировать запросы и использовать информацию, скрытую в различных полях ответных пакетов для контроля вредоносного ПО на компьютере жертвы.
Самая интересная часть - это туннелирование, то есть маскировка информации и передаваемых команд. Делается это, очевидно для того, чтобы подобный трафик прошел незамеченным мимо защитных систем и ПО. Для маскировки используются base32, base 64, а порой и полноценное шифрование.
Base32 и Base64 - это способы кодировки информации используя 32 символа и 64 соответственно. Суть данного упражнении в передаче любой информации в текстовом виде.У обоих методов есть минусы - Base32 код оказывается в 1,6 раза больше оригинальной информации, а Base64 - регистрозависим.
Когда возник данный тип атак?
Впервые подобный вид атак был упомянут в рассылке Buqtraq неким Оскаром Пирсоном в апреле 1998 года.
Далее в 2004 на ежегодной конференции Black Hat была представлена подробная техника - то есть буквально руководство по использованию данной атаки. Шло время и данный тип атак становился все популярнее - сегодня этот механизм встроен буквально в каждый вирус-шифровальщик.
Попробуйте погуглить словосочетание Sea Turtle - это все еще активная кампания, целью которой является взлом легитимных DNS серверов для перенаправления запросов на свои собственные сервера. То есть злоумышленники смогут отвечать на эти запросы ложными сайтами. К примеру пользователь будет пытаться зайти на Facebook или свой аккаунт Ozon, но на самом деле это будут копии страниц, созданные для перехвата пользовательской информации. Честно говоря, такой тип атак не имеет ничего общего с туннелированием DNS, но вектор атаки остается тем же. И представьте себе последствия от украденных учетных данных - лично я бы не хотел, что злоумышленники получили доступ к моим аккаунт в онлайн банках и социальных сетях.
Основные опасности DNS туннелирования
Как вы уже могли понять из моей спутанной и слегка аутичной статьи, DNS туннелирование является механизмом, который является катализатором для различного вида неприятностей, а именно:
Утечка данных: злоумышленники используют DNS для банального вывода текстовой информации с помощью определенной маскировки. Объемы вывода небольшие, но порой много и не требуется - к примеру, данные паспорта улетят очень быстро;
Удаленный контроль: злоумышленники отправляют различные команды через DNS, к примеру для управления RAT-ами (троянами с удаленным управлением). К слову, большое количество шифровальщиков именно так получают свои инструкции и ключи шифрования;
IP-Over-DNS туннелирование: сейчас уже можно найти специальные утилиты, в которых IP стэк имплементирован в клиент-серверную модель работы DNS. То есть такие утилиты позволяют относительно просто передавать информацию используя стандартные штуки вроде FTP, Netcat, ssh и пр. То есть через DNS можно будет передать буквально любую информацию
Техники детектирования DNS - туннелирования
Существует два основных метода по обнаружения некорректного использования DNS службы: анализ трафика и анализ полезной нагрузки.
При анализе полезной нагрузке необходимо обращать внимание на странные и аномальные запросы, особенно если они содержат в себе странные доменные имена, странные символы и пр. Для выявления подобного используются различные статистические техники.
В свою очередь, при анализе трафика, нужно обращать внимание на общее количество запросов к домену и сравнивать это число со средними значениями. Хакеры, осуществляющие DNS туннелирование, будут создавать большой объем DNS трафика - что сразу должно вызвать подозрения, так как отличия в объемах будут буквально на порядки.
Утилиты для создания DNS туннеля:
Если вам хочется посмотреть, уязвима ли ваша инфраструктура к такому виду атак, то можете попробовать несколько утилит из списка ниже (только на свой страх и риск). Все эти утилиты реализуют IP-over-DNS механизм атак.
Iodine: данная утилита доступна на большинстве платформ (Linux, Mac OS, Windows, FreeBSD) и позволяет установить SSH туннель между целью и вашим компьютером. Утилита не самая простая, когда-нибудь мы напишем статью чс примером ее использования;
OzymanDNS: функционал схож с Iodine, то есть утилита также позволяет строить SSH туннель. Интересно то, что это проект целиком и полностью написан на Perl;
DNSCat2: многофункциональный комбайн, который создает зашифрованный канал для управления (C2) и позволяет скачивать/загружать файлы, запускать cmd/powershell и пр.
Утилиты для мониторинга DNS туннеля:
dnsHunter: модуль на питоне, написанный для Mercenary-Linux. Данный модуль читает .pcap файлы, выделяет из них DNS-запросы и осуществляет геолукапы, что также может помочь при расследовании;
reassemble_dns: также утилита, написанная на питоне, которая позволяет читать .pcap файлы и реконструировать DNS запросы;
Первая часть тут
Как только изменение в топологии сети было обнаружено, оно должно быть каким-то образом распределено по всем устройствам, участвующим в плоскости управления. Каждый элемент в топологии сети может быть описан как:
Канал или граница, включая узлы или достижимые места назначения, прикрепленные к этому каналу.
Устройство или узел, включая узлы, каналы и доступные места назначения, подключенные к этому устройству.
Этот довольно ограниченный набор терминов может быть помещен в таблицу или базу данных, часто называемую таблицей топологии или базой данных топологии. Таким образом, вопрос о распределении изменений в топологии сети на все устройства, участвующие в плоскости управления, можно описать как процесс распределения изменений в определенных строках в этой таблице или базе данных по всей сети.
Способ, которым информация распространяется по сети, конечно, зависит от конструкции протокола, но обычно используются три вида распространения: поэтапное (hop-by-hop) распространение, лавинное (flooded) распространение и централизованное (centralized) хранилище некоторого вида.
Лавинное (flooded) распространение.
При лавинной рассылке каждое устройство, участвующее в плоскости управления, получает и сохраняет копию каждой части информации о топологии сети и доступных местах назначения. Хотя существует несколько способов синхронизации базы данных или таблицы, в плоскостях управления обычно используется только один: репликация на уровне записи. Рисунок 6 иллюстрирует это.
На рисунке 6 каждое устройство будет рассылать известную ему информацию ближайшим соседям, которые затем повторно рассылают информацию своим ближайшим соседу. Например, A знает две специфические вещи о топологии сети: как достичь 2001: db8: 3e8: 100 :: / 64 и как достичь B. A передает эту информацию в B, который, в свою очередь, передает эту информацию в C. Каждое устройство в сети в конечном итоге получает копию всей доступной топологической информации; A, B и C имеют синхронизированные базы данных топологии (или таблицы).
На рисунке 6 связь C с D показана как элемент в базе данных. Не все плоскости управления будут включать эту информацию. Вместо этого C может просто включать подключение к диапазону адресов 2001: db8: 3e8: 102 :: / 64 (или подсети), который содержит адрес D.
Примечание. В более крупных сетях невозможно уместить все описание подключений устройства в один пакет размером с MTU, и для обеспечения актуальности информации о подключении необходимо регулярно задерживать время ожидания и повторно загружать данные.
Интересная проблема возникает в механизмах распространения Flooding рассылки, которые могут вызывать временные петли маршрутизации, называемые microloops. Рисунок 7 демонстрирует эту ситуацию. На рисунке 7, предположим, что канал [E, D] не работает. Рассмотрим следующую цепочку событий, включая примерное время для каждого события:
Старт: A использует E, чтобы добраться до D; C использует D, чтобы добраться до E.
100 мс: E и D обнаруживают сбой связи.
500 мс: E и D рассылают информацию об изменении топологии на C и A.
750 мс: C и A получают обновленную информацию о топологии.
1000 мс: E и D пересчитывают свои лучшие пути; E выбирает A как лучший путь для достижения D, D выбирает C как лучший путь для достижения E.
1,250 мс: лавинная рассылка A и C информации об изменении топологии на B.
1400 мс: A и C пересчитывают свои лучшие пути; A выбирает B для достижения D, C выбирает B для достижения E.
1500 мс: B получает обновленную информацию о топологии.
2,000 мс: B пересчитывает свои лучшие пути; он выбирает C, чтобы достичь D, и A, чтобы достичь E.
Хотя время и порядок могут незначительно отличаться в каждой конкретной сети, порядок обнаружения, объявления и повторных вычислений почти всегда будет следовать аналогичной схеме. В этом примере между этапами 5 и 7 образуется микропетля; в течение 400 мс, A использует E для достижения D, а E использует A для достижения D. Любой трафик, входящий в кольцо в A или D в течение времени между пересчетом E лучшего пути к D и пересчетом A лучшего пути к D будет петлей. Одним из решений этой проблемы является предварительное вычисление альтернативных вариантов без петель или удаленных альтернатив без петель.
Hop by Hop
При поэтапном распределении каждое устройство вычисляет локальный лучший путь и отправляет только лучший путь своим соседям. Рисунок 8 демонстрирует это.
На рисунке 8 каждое устройство объявляет информацию о том, что может достигнуть каждого из своих соседей. D, например, объявляет о достижимости для E, а B объявляет о доступности для C, D и E для A. Интересно рассмотреть, что происходит, когда A объявляет о своей доступности для E через канал на вершине сети. Как только E получит эту информацию, у него будет два пути к B, например: один через D и один через A. Таким же образом у A будет два пути к B: один напрямую к B, а другой через E. Любой из алгоритмов кратчайшего пути, рассмотренные в предыдущих статьях, могут определить, какой из этих путей использовать, но возможно ли формирование микропетель с помощью лавинного механизма распределения?
Рассмотрим:
E выбирает путь через A, чтобы добраться до B.
Канал [A, B] не работает.
A обнаруживает этот сбой и переключается на путь через E.
Затем A объявляет этот новый путь к E.
E получает информацию об измененной топологии и вычисляет новый лучший путь через D.
В промежутке между шагами 3 и 5 А будет указывать на Е как на свой лучший путь к В, в то время как Е будет указывать на А как на свой лучший путь к В—микропетля. Большинство распределительных систем hop-by-hop решают эту проблему с помощью split horizon или poison reverse.
Определены они следующим образом:
Правило split horizon гласит: устройство не должно объявлять о доступности к пункту назначения, который он использует для достижения пункта назначения.
Правило poison reverse гласит: устройство должно объявлять пункты назначения по отношению к соседнему устройству, которое оно использует, чтобы достичь пункта назначения с бесконечной метрикой.
Если разделение горизонта (split horizon) реализованный на рисунке 8, E не будет объявлять о достижимости для B, поскольку он использует путь через A для достижения B. В качестве альтернативы E может отравить путь к B через A, что приведет к тому, что A не будет иметь пути через E к B.
Централизованное Хранилище.
В централизованной системе каждое сетевое устройство сообщает информацию об изменениях топологии и достижимости контроллеру или, скорее, некоторому набору автономных служб и устройств, действующих в качестве контроллера. В то время как централизация часто вызывает идею единого устройства (или виртуального устройства), которому передается вся информация и который передает правильную информацию для пересылки всем устройствам обработки пакетов в сети, это чрезмерное упрощение того, что на самом деле означает централизованная плоскость управления. Рисунок 9 демонстрирует это.
На рисунке 9, когда канл между D и F не работает:
D и F сообщают об изменении топологии контроллеру Y.
Y пересылает эту информацию другому контроллеру X.
Y вычисляет лучший путь к каждому месту назначения без канала [D, F] и отправляет его каждому затронутому устройству в сети.
Каждое устройство устанавливает эту новую информацию о пересылке в свою локальную таблицу.
Конкретный пример шага 3 - Y вычисляет следующий лучший путь к E без канала [D, F] и отправляет его D для установки в его локальной таблице пересылки. Могут ли микропетли образовываться в централизованной плоскости управления?
Базы данных в X и Y должны быть синхронизированы, чтобы оба контроллера вычисляли одинаковые пути без петель в сети
Синхронизация этих баз данных повлечет за собой те же проблемы и (возможно) использование тех же решений, что и решения, обсуждавшиеся до сих пор в этой статье.
Подключенным устройствам потребуется некоторое время, чтобы обнаружить изменение топологии и сообщить об этом контроллеру.
Контроллеру потребуется некоторое время, чтобы вычислить новые пути без петель.
Контроллеру потребуется некоторое время, чтобы уведомить затронутые устройства о новых путях без петель в сети.
Во время временных интервалов, описанных здесь, сеть все еще может образовывать микропетли. Централизованная плоскость управления чаще всего переводится в плоскость управления не запущенными устройствами переадресации трафика. Хотя они могут казаться радикально разными, централизованные плоскости управления на самом деле используют многие из тех же механизмов для распределения топологии и достижимости, а также те же алгоритмы для вычисления безцикловых путей через сеть, что и распределенные плоскости управления.
Плоскости сегментирования и управления.
Одна интересная идея для уменьшения состояния, переносимого на любое отдельное устройство, независимо от того, используется ли распределенная или централизованная плоскость управления, заключается в сегментировании информации в таблице топологии (или базе данных). Сегментация-это разделение информации в одной таблице на основе некоторого свойства самих данных и хранение каждого полученного фрагмента или фрагмента базы данных на отдельном устройстве. Рисунок 10 демонстрирует это.
В сети на рисунке 10 предположим, что оба контроллера, X и Y, имеют информацию о топологии для всех узлов (устройств) и ребер (каналов) в сети. Однако для масштабирования размера сети доступные места назначения были разделены на два контроллера. Существует множество возможных схем сегментирования - все, что может разделить базу данных (или таблицу) на части примерно одинакового размера, будет работать. Часто используется хеш, так как хеши можно быстро изменить на каждом устройстве, где хранится сегмент, чтобы сбалансировать размеры сегментов.
В этом случае предположим, что схема сегментирования немного проще: это диапазон IP-адресов. В частности, на рисунке представлены два диапазона IP-адресов: 2001: db8: 3e8: 100 :: / 60, который содержит от 100 :: / 64 до 10f :: / 64; и 2001: db8: 3e8: 110 :: / 60, который содержит от 110 :: / 64 до 11f :: / 64. Каждый из этих диапазонов адресов разделен на один контроллер; X будет содержать информацию о 2001: db8: 3e8: 100 :: / 60, а Y будет содержать информацию о 2001: db8: 3e8: 110 :: / 64. Не имеет значения, где эти доступные пункты назначения подключены к сети. Например, информация о том, что 2001: db8: 3e8: 102 :: / 64 подключен к F, будет храниться в контроллере X, а информация о том, что 2001: db8: 3e8: 110 :: / 64 подключен к A, будет храниться на контроллере Y. Чтобы получить информацию о доступности для 2001: db8: 3e8: 102 :: / 64, Y потребуется получить информацию о том, где этот пункт назначения соединен с X. Это будет менее эффективно с точки зрения вычисления кратчайших путей, но он будет более эффективным с точки зрения хранения информации, необходимой для вычисления кратчайших путей. Фактически, возможно, если информация хранится правильно (а не тривиальным способом, используемым в этом примере), чтобы несколько устройств вычислили разные части кратчайшего пути, а затем обменивались только результирующим деревом друг с другом. Это распределяет не только хранилище, но и обработку.
Существует несколько способов, с помощью которых информация о плоскости управления может быть разделена, сохранена и, когда вычисления выполняются через нее, чтобы найти набор путей без петель через сеть.
Согласованность, доступность и возможность разделения.
Во всех трех системах распределения, обсуждаемых в этой статье, - лавинной, поэтапной и централизованных хранилищ - возникает проблема микропетель. Протоколы, реализующие эти методы, имеют различные системы, такие как разделение горизонта и альтернативы без петель, чтобы обходить эти микропетли, или они позволяют микропетлям появляться, предполагая, что последствия будут небольшими для сети. Существует ли объединяющая теория или модель, которая позволит инженерам понять проблемы, связанные с распределением данных по сети, и различные сопутствующие компромиссы?
Есть: теорема CAP.
В 2000 году Эрик Брюер, занимаясь как теоретическими, так и практическими исследованиями, постулировал, что распределенная база данных обладает тремя качествами: Согласованностью, Доступностью и устойчивость к разделению (Consistency, Accessibility Partition tolerance-CAP). Между этими тремя качествами всегда есть компромисс, так что вы можете выбрать два из трех в любой структуре системы. Эта гипотеза, позже доказанная математически, теперь известна как теорема CAP. Эти три термина определяются как:
Согласованность: Каждый считыватель видит согласованное представление содержимого базы данных. Если какое-то устройство С записывает данные в базу данных за несколько мгновений до того, как два других устройства, А и В, прочитают данные из базы данных, оба считывателя получат одну и ту же информацию. Другими словами, нет никакой задержки между записью базы данных и тем, что оба считывателя, А и В, могут прочитать только что записанную информацию.
Доступность: каждый считыватель имеет доступ к базе данных при необходимости (почти в реальном времени). Ответ на чтение может быть отложен, но каждое чтение будет получать ответ. Другими словами, каждый считыватель всегда имеет доступ к базе данных. Не существует времени, в течение которого считыватель получил бы ответ «сейчас вы не можете запросить эту базу данных».
Устойчивость к разделению: возможность копирования или разделения базы данных на несколько устройств.
Проще изучить теорему CAP в небольшой сети. Для этого используется рисунок 11.
Предположим, что A содержит единственную копию базы данных, к которой должны иметь доступ как C, так и D. Предположим, что C записывает некоторую информацию в базу данных, а затем сразу же после, C и D считывают одну и ту же информацию. Единственная обработка, которая должна быть, чтобы убедиться, что C и D получают одну и ту же информацию, - это A. Теперь реплицируйте базу данных, чтобы была копия на E и еще одна копия на F. Теперь предположим, что K записывает в реплику на E, а L читает из реплики на F. Что же будет?
F может вернуть текущее значение, даже если это не то же самое значение, что только что записал К. Это означает, что база данных возвращает непоследовательный ответ, поэтому согласованность была принесена в жертву разделению базы данных.
Если две базы данных синхронизированы, ответ, конечно, в конечном итоге одинаковым, но потребуется некоторое время, чтобы упаковать изменение (упорядочить данные), передать его в F и интегрировать изменение в локальную копию F. F может заблокировать базу данных или определенную часть базы данных, пока выполняется синхронизация. В этом случае, когда L читает данные, он может получить ответ, что запись заблокирована. В этом случае доступность теряется, но сохраняется согласованность и разбиение базы данных.
Если две базы данных объединены, то согласованность и доступность могут быть сохранены за счет разделения.
Невозможно решить эту проблему, чтобы все три качества были сохранены, из-за времени, необходимого для синхронизации информации между двумя копиями базы данных. Та же проблема актуальна и для сегментированной базы данных.
Как это применимо к плоскости управления? В распределенной плоскости управления база данных, из которой плоскость управления черпает информацию для расчета путей без петель, разделена по всей сети. Кроме того, база данных доступна для чтения локально в любое время для расчета путей без петель. Учитывая разделение и доступность, необходимые для распределенной базы данных, используемой в плоскости управления, следует ожидать, что непротиворечивость пострадает - и это действительно так, что приводит к микропетлям во время конвергенции. Централизованная плоскость управления не «решает» эту проблему. Централизованная плоскость управления, работающая на одном устройстве, всегда будет согласованной, но не всегда будет доступной, а отсутствие разделения будет представлять проблему для устойчивости сети.
Несмотря на то, что системы на базе Linux считаются самыми неуязвимыми, всё же существуют риски, к которым нужно относиться серьезно.
Руткиты, вирусы, программы-вымогатели и многие другие вредоносные программы часто могут атаковать и вызывать проблемы на серверах Linux.
Независимо от установленной операционной системы, для серверов необходимо принимать повышенные меры безопасности. Крупные корпорации и организации взялись за повышение уровня безопасности и разработали инструменты, которые не только обнаруживают недостатки и вредоносные программы, но и исправляют их и принимают меры для предотвращения разного вида неприятностей. Но такие ПО стоят дорого и не все могут позволить себе их покупать.
К счастью, есть инструменты, по приемлемой цене или вовсе бесплатные, которые могут помочь с поиском и устранением уязвимостей. Они могут обнаруживать слабые места в различных разделах сервера на базе Linux.
Lynis
Lynis это известный инструмент безопасности, который пользуется популярностью среди Linux специалистов. Он также работает на системах на базе Unix и macOS. Это программное обеспечение с открытым исходным кодом, которое с 2007 года распространяется под лицензией GPL.
Lynis не требует установки. Можно извлечь его из загруженного пакета или tar архива и запустить. Чтобы получить доступ к полной документации и исходному коду, можно скачать его с Git,
Lynis был создан автором Rkhunter Майклом Боеленом. Она имеет две версии: для домашнего пользования и для предприятий. Обе версии показывают отличные результаты.
Chkrootkit
Как вы уже наверно предположили, chkrootkit утилита для сканирования системы на наличие руткитов. Руткиты это вид вредоносного ПО, который дает неавторизованному пользователю право на вход в систему. Если в парке есть сервера на базе Linux, то руткиты могут стать настоящей проблемой.
Chkrootkit одна из самых популярных программ на базе Unix, которая помогает обнаруживать руткиты в системе. Для обнаружения проблем она использует команды "strings" (команда Linux для просмотра содержимого бинарного файла) и "grep".
Она может быть запущена как с альтернативной директории, так и внещнего накопителя в случае работы с уже скомпрометированной системой. Различные компоненты chkrootkit занимаются поиском удалённые записи в "wtmp" и "lastlog" файлах, находят записи сниффера или конфигурационных файлов руткитов, а также проверяют на наличие скрытых записей в "/proc" или вызовов программы "readdir".
Чтобы использовать эту утилиту нужно скачать последнюю версию, распаковать, скомпилировать и запустить.
Rkhunter
Майкл Болин разработчик, который создал в 2003 году Rkhunter. Эта очень полезная программа для POSIX систем помогает обнаруживать руткиты и другие уязвимости в системах Linux. Rkhunter тщательно просматривает файлы (скрытые или видимые), каталоги по умолчанию, модули ядра и неправильно настроенные разрешения в поисках слабых мест.
После обычной проверки, он сопоставляет результаты с безопасными и правильными записями баз данных и ищет подозрительное ПО. Так как программа полностью написана на Bash, его можно использовать не только на Linux, но и на всех версиях Unix.
ClamAV
Написанный на C++ ClamAV антивирус с открытым исходным кодом, который помогает выявлять вирусы, трояны и другие виды вредоносных программ. Он полностью бесплатен, ввиду чего очень много пользователей используют его для сканирования персональных данных включая электронную почту на наличие вредоносных файлов любого типа. Он так же может быть использован для сканирования серверов.
Изначально он был создан только для Unix. Несмотря на это, есть сторонние версии, которые можно использовать на Linux, BSD, AIX, MacOS, OpenVMS, Solaris. ClamAV регулярно выполняет автоматическое обновление баз данных для выявления самых последних угроз. Есть возможность сканирования в режиме командной строки, а также включает в себя расширяемый многопоточный демон, благодаря чему, существенно увеличивается скорость сканирования.
Он проверяет различные типы файлов на наличие уязвимостей. Антивирус поддерживает все типы сжатых файлов включая RAR, Zip, Gzip, Tar, Cabinet, OLE2, CHM, SIS format, BinHex и почти все типы почтовых систем.
LMD
Linux Malware Detect LMD другой очень популярный продукт для Linux систем, специально разработанный для часто встречающихся угроз. Как и другие подобные продукты для поиска вредоносных программ и руткитов, LMD использует базу сигнатур для выявления и прекращения работы любого вредоносного кода.
LMD не ограничивается собственными базами сигнатур. Для лучшего поиска он может использовать базы ClamAV и Team Cymru. Для заполнения своих баз, LMD собирает данные об уязвимостях на пограничных системах обнаружения угроз. Тем самым он генерирует новые сигнатуры для вредоносных ПО, которые активно эксплуатируются в атаках.
Radare2
Radare2 (R2) фреймворк для анализа и реверс-инжиниринга двоичных файлов с превосходными возможностями обнаружения. Он может выявить заражённые файлы, даёт пользователю инструменты для управления ими, нейтрализует потенциальные угрозы. Фереймворк использует NoSQL базу sdb. Исследователи безопасности и разработчики ПО предпочитают эту программу за возможность отличного визуального представления данных.
Одной из отличительных особенностей Radare2 является то, что пользователь не должен использовать командную строку для выполнения таких задач, как статический/динамический анализ и использование программного обеспечения. Рекомендуется для любого типа исследований по бинарным данным.
OpenVAS
Open Vulnarability Assessment System или OpenVAS эта размещённая система для сканирования уязвимостей и управления ими. Она предназначена для предприятий любого размера и помогает выявлять невидимые проблемы безопасности в инфраструктуре. Изначально этот продукт был известен под названием GNessUs, до тех пор, пока новый владелец, Greenbone Networks, не сменил название на OpenVAS.
Начиная с версии 4.0, OpenVAS предоставляет непрерывное обновление Сетевой базы Тестирования Уязвимостей обычно менее чем за 24 часа. На июнь 2016 система имеет больше 47 тысяч баз.
Эксперты безопасности используют OpenVAS из-за возможности быстрого сканирования. Он также отличается превосходной возможностью конфигурирования. Программы OpenVAS могут использоваться на автономных виртуальных машинах для проведения безопасных исследований вредоносных программ. Его исходный код доступен под лицензией GNU GPL. Многие другие средства обнаружения уязвимостей зависят от OpenVAS - именно поэтому его принимают как важнейшую программу в платформах на базе Linux.
REMnux
REMNux использует метод обратного-инжиниринга для анализа вирусов. Он может обнаруживать большинство проблем на основе браузера, скрытых в изменённых фрагментах кода JavaScript и апплетах Flash. Он также способен сканировать PDF-файлы и выполнять экспертизу памяти. Средство помогает обнаруживать вредоносные программы внутри папок и файлов, которые сложно проверить с помощью других программ обнаружения вирусов.
Он эффективен благодаря своим возможностям декодирования и обратного проектирования. Он может определять свойства подозрительных программ, и, будучи легким, он в значительной степени не обнаруживается интеллектуальными вредоносными программами. Он может использоваться как на Linux, так и на Windows, а его функциональность может быть улучшена с помощью других инструментов сканирования.
Tiger
В 1992 году Техасский Университет A&M начал работать над Tiger для повышения безопасности компьютеров кампуса. Сегодня же она самая популярная система для Unix-подобных платформ. Уникальность этого решения заключается в том, что оно является не только средством аудита безопасности, но и системой обнаружения вторжений.
Программа свободно распространяются под лицензией GPL. Она зависит от средств POSIX, и вместе они могут создать идеальную инфраструктуру, которая может значительно повысить безопасность вашего сервера. Tiger полностью написан на shell - это одна из причин его эффективности. Он подходит для проверки состояния и конфигурации системы, а его многоцелевое использование делает его очень популярным среди людей, использующих инструменты POSIX.
Maltrail
Maltrail - это система обнаружения трафика, способная обеспечить чистоту трафика вашего сервера и помочь ему избежать любых угроз. Она выполняет эту задачу, сравнивая источники трафика с сайтами в черном списке, опубликованными в Интернете.
Помимо проверки сайтов, включенных в черный список, она также использует усовершенствованные эвристические механизмы для обнаружения различных видов угроз. Даже если это необязательная функция, она пригодится, когда вы считаете, что ваш сервер уже подвергся атаке.
Эта система имеет особый сенсор, способный обнаруживать трафик сервера, и посылать информацию на сервер Maltrail. Система обнаружения проверяет, достаточно ли безопасен трафик для обмена данными между сервером и источником.
YARA
Созданная для Linux, Windows и macOS, YARA (Yet Another Ridiculous Acronym) является одним из наиболее важных инструментов, используемых для исследования и обнаружения вредоносных программ. Он использует текстовые или двоичные шаблоны для упрощения и ускорения процесса обнаружения, что упрощает и ускоряет решение задачи.
У YARA есть некоторые дополнительные функции, но для их использования необходима библиотека OpenSSL. Даже если у вас нет этой библиотеки, вы можете использовать YARA для базового исследования вредоносных программ с помощью механизма, основанного на правилах. Также его можно использовать в песочнице Cuckoo - песочнице на основе Python, идеальной для проведения безопасных исследований вредоносного программного обеспечения.
Как выбрать лучшую утилиту?
Все инструменты, о которых мы говорили выше, работают очень хорошо, и когда инструмент популярен в среде Linux, вы можете быть уверены, что его используют тысячи опытных пользователей. Нужно помнить, что каждое приложение обычно зависит от других программ. Например, это касается ClamAV и OpenVAS.
Необходимо понять, что нужно вашей системе и в каких компонентах она может иметь уязвимости. Во-первых, используйте легковесный инструмент, чтобы изучить, какой раздел требует внимания. Затем используйте соответствующий инструмент для решения проблемы.