Защита от хакеров корпоративных сетей
Шрифт:
В этой главе будут рассмотрены некоторые коммерческие и свободно распространяемые инструментальные средства оценки безопасности и обсуждены их ближайшие перспективы.
Краткие сведения об автоматизированных средствах оценки безопасности
Функциональные возможности автоматизированных инструментальных средств оценки безопасности изменяются в очень широких пределах. Некоторые из них могут сканировать хосты, находясь вне сети и не требуя для своей работы необходимых учетных записей с параметрами доступа пользователя, сформированными после его успешной аутентификации. В то время как другие успешно сканируют хосты только в том случае, если они находятся внутри корпоративной сети и им предоставлены достаточные права (обычно права администратора или суперпользователя). Кроме того, некоторые инструментальные средства не в меру навязчивы из-за того, что они пытаются воспользоваться только что найденной уязвимостью. Другие скромны и пытаются идентифицировать уязвимые хосты, проверяя различные признаки, по которым можно судить об установке на хосте патчей (например, проверяют существование определенных файлов, установленных патчем производителя). Существует жюри, которое молчаливо отбирает лучшие инструментальные средства. О них можно узнать после прочтения изложенного ниже вложения «Автоматизированные инструментальные
Инструментарий и ловушки
Автоматизированные инструментальные средства: обзор программ
Ниже приведены ссылки на различные обзоры большого числа ныне доступных автоматизированных инструментальных средств. Большинство авторов обзоров сходится во мнении о том, что скрытно работающие, малозаметные инструментальные средства проверяют лишь наличие патчей, а не их эффективность. Это оправдано в тех случаях, когда патч не в полной мере решает проблему и поэтому проверка установки патча позволяет решить вопрос об уязвимости системы.
Читатель может найти обзоры рассматриваемых инструментальных средств по приведенным ниже адресам:
• сравнительный обзор обычно используемых сканеров www.nwc.com/1201/1201f1b1.html
• всесторонний обзор различных сканеров www.westcoast.com/securecomputing/2001_07/testc/prod2.html
• сравнительный обзор некоторых из наиболее популярных коммерческих сканеров www.infosecuritymag.com/articles/january01/features1.shtml
• обзор наиболее покупаемых автоматизированных инструментальных средств, подготовленный Info Security www.westcoast.com/asiapacific/articles/2000_07/testc/testc.html
• CyberCop Scanner 5.5 компании Network Associates (NAI) www.secadministrator.com/Articles/Index.cfm?ArticleID=9203
• NetRecon 3.0 компании Axent (ныне Symantec) www.secadministrator.com/Articles/Index.cfm?ArticleID=9204
• ISS Internet Scanner 6.1 www.secadministrator.com/Articles/Index.cfm?ArticleID=9205
• BindView HackerShield (ныне BV–Control for Internet Security) www.secadministrator.com/Articles/Index.cfm?ArticleID=9206
• Webtrends (ныне NetIQ) Scanner 3.0 www.secadministrator.com/Articles/Index.cfm?ArticleID=9207
Для тестирования каждого хоста инструментальные средства сканирования используют ряд проверок или просмотров сигнатур. Большинство коммерческих и свободно распространяемых сканеров поддерживают легкий для понимания и использования язык создания сценариев. Любой, кто хоть немного знаком с программированием, может понять алгоритм работы проверок и определить, что именно они ищут. Ниже показан пример реализации алгоритма сканирования в сканере Nessus – одном из свободно распространяемых сканеров. Сканирование выполняется с целью поиска хостов, не защищенных от атаки на информационный сервер Интернет с использованием его уязвимости под названием уязвимость обхода директорий (Internet Information Server(IIS) Directory Traversal Vulnerability – CVE ID 2000–0884).
Полная версия плагина (подключаемой программы plug-in) Nessus доступна на сайте http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/scripts/iis_dir_traversal.nasl.
script_description(english:desc[“english”]);
summary[“english”] = “Determines if arbitrary commands can
be executed thanks to IIS”;
script_summary(english:summary[“english”]);
script_category(ACT_GATHER_INFO);
script_copyright(english:“This script is Copyright (C) 2001
H D Moore”);
family[“english”] = “CGI abuses”;
script_family(english:family[“english”]);
script_dependencie(“find_service.nes”, “http_version.nasl”);
script_require_ports(“Services/www”, 80);
script_require_keys(“www/iis”);
exit(0);
}
port = get_kb_item(“Services/www”);
if(!port)port = 80;
dir[0] = “/scripts/”;
dir[1] = “/msadc/”;
dir[2] = “/iisadmpwd/”;
dir[3] = “/_vti_bin/”; # FP
dir[4] = “/_mem_bin/”; # FP
dir[5] = “/exchange/”; # OWA
dir[6] = “/pbserver/”; # Win2K
dir[7] = “/rpc/”; # Win2K
dir[8] = “/cgi-bin/”;
dir[9] = “/”;
uni[0] = “%c0%af”;
uni[1] = “%c0%9v”;
uni[2] = “%c1%c1”;
uni[3] = “%c0%qf”;
uni[4] = “%c1%8s”;
uni[5] = “%c1%9c”;
uni[6] = “%c1%pc”;
uni[7] = “%c1%1c”;
uni[8] = “%c0%2f”;
uni[9] = “%e0%80%af”;
function check(req)
{
soc = open_sock_tcp(port);
if(soc)
{
req = http_get(item:req, port:port);
send(socket:soc, data:req);
r = recv(socket:soc, length:1024);
close(soc);
pat = “
”;
pat2 = “Directory of C”;
if((pat >< r) || (pat2 >< r)){
security_hole(port:port);
return(1);
}
}
return(0);
}
cmd = “/winnt/system32/cmd.exe?/c+dir+c:\\+/OG”;
for(d=0;dir[d];d=d+1)
{
for(u=0;uni[u];u=u+1)
{
url = string(dir[d], “..”, uni[u], “..”, uni[u], “..”,
uni[u], “..”, uni[u], “..”, uni[u], “..”, cmd);
if(check(req:url))exit(0);
}
}Как читатель может понять, программа проверки, написанная Муром (H D Moore) для сканера Nessus, активно попытается воспользоваться известной ей уязвимостью. В случае обнаружения уязвимого хоста будет послано сообщение. С другой стороны, программа может проверить ту же самую уязвимость путем простой проверки соответствующего ключа реестра:
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%HOTFIX_NUMBER%
Последний способ проще, и вероятно, его легче запрограммировать, но у него есть несколько недостатков. Во-первых, для проверки ключа реестра требуется доступ с правами администратора. Во-вторых, рассматриваемый способ может как подтвердить факт инсталляции заплаты системы безопасности Hotfix, так и не подтвердить его, если заплата была установлена правильно или если система на самом деле неуязвима. Часто инсталляция этой возможности в Windows NT вынуждает операционную систему затребовать чтение файлов с оригинального инсталляционного CD-диска, что в значительной степени ведет к возврату в небезопасное состояние системы после ее первой инсталляции. Причем после инсталляции ключ останется в реестре, хотя исправляемая заплатой ошибка не будет еще исправлена патчем.
Современные традиционные инструментальные средства, столкнувшись с такой ситуацией, прекратят свою работу и отошлют отчет с результатами сканирования обратно оператору. Некоторые из новейших, ныне разрабатываемых инструментальных средств способны продвинуться на шаг дальше. Далее на примере той же самой уязвимости CVE ID 2000–0884 информационного сервера Интернет IIS будут объяснены подходы к ее разрешению, которые используются в некоторых разрабатываемых инструментальных средствах тестирования на проникновение.
Алгоритм работы подобных
Анализ коммерческих инструментальных средств
Сегодня на рынке доступны многочисленные коммерческие инструментальные средства. Покупка любого из них является задачей, которая может привести в замешательство и отпугнуть потенциального покупателя своей сложностью. Как и в случае с большинством других продуктов, группа маркетинга каждого производителя будет убеждать покупателя, что их программа лучшая и что она выполняет больше всех проверок. Проблема при покупке рассматриваемого инструментария состоит в том, что не все производители оценивают их по единым критериям. Финансируемая федеральным правительством США организация проектно-конструкторских работ Mitre (www.mitre.org) частично обратила внимание на эту проблему, создав словарь распространенных уязвимостей и дефектов CVE (Common Vulnerabilities and Exposures). Этот словарь является стандартизированным соглашением по именованию уязвимостей и дефектов информационной безопасности. Создание словаря CVE преследовало цель облегчить для производителей инструментария безопасности и конечных пользователей установку соответствия между информацией об уязвимости и многочисленными инструментальными средствами. В настоящее время ряд коммерческих и свободно распространяемых инструментальных средств установили или находятся в процессе установления соответствия между своими базами данных и идентификаторов словаря CVE. Следует отметить, что такое соответствие очень важно для оценки использования рассматриваемых инструментальных средств. В таблице 17.1 приведены некоторые сканеры и число обнаруживаемых ими уязвимостей.
Таблица 17.1.
Сканеры и число обнаруживаемых ими уязвимостей
Читатель может заметить, что если учитывать лишь число обнаруживаемых уязвимостей, то разница между сканерами приобретает драматический характер. Если бы каждый производитель находил и подсчитывал бы уязвимости, основываясь на словаре CVE, то это было бы идеальным выходом из сложившейся путаной ситуации. Это не такая уж простая задачка, поскольку для большинства производителей переход на словарь CVE означает не только пересмотр правил подсчета проверок, но и переписывание самих проверок. Производители постоянно находят новые способы продемонстрировать значительное преимущество своих программ. При использовании словаря CVE игра в проверки перестанет существовать, и сделается возможным справедливое сравнение инструментальных средств с помощью таких их характеристик, как процент ложных срабатываний, удобство и простота использования, эффективность сканирования и возможности выдачи отчетов. Именно эти показатели станут ключевыми показателями при определении лучшей программы.
Ниже приводится краткий перечень некоторых из критериев, которыми следует руководствоваться при покупке коммерческого сканера:
• процент ложных срабатываний;
• производительность;
• возможности выдачи отчетов;
• интерфейс пользователя.
Следует понять, что большинство коммерческих сканеров рождается неравными. Каждый из них имеет собственные достоинства и недостатки. Обычное дело – встретить администраторов безопасности, использующих в своей работе более одного коммерческого инструментального средства, потому что ни одно из них не годится на все случаи жизни. Даже бесповоротно решив купить сканер уязвимости, не следует торопиться с покупкой до тех пор, пока не будет произведена основательная оценка удовлетворения каждой программой специфических потребностей покупателя и его среды. Почти все производители программных средств, пытаясь продать свою программу, бесплатно предложат ее демонстрационную копию. Воспользуйтесь эти предложением. В худшем случае покупателю придется позвонить продавцу и попросить его помочь разрешить возникшие проблемы применения его программы. Если продавец не может ответить на вопросы покупателя в полном объеме, то переговорите с одним из разработчиков программы. Опыт автора общения с продавцами свидетельствует о полезности общения в том случае, если продавцы рады помочь покупателю и готовы ответить на любой его вопрос. Но не поддавайтесь на различные маркетинговые уловки. В конечном счете следует принять собственное решение относительно соответствия программы предъявляемым к ней требованиям.
По всей видимости, процент ложных срабатываний является наиболее раздражающим результатом использования сканеров уязвимости. Ложное срабатывание – это такая ситуация, когда сканер сообщает о существовании проблемы, хотя на самом деле ее нет. Высокий процент ложных срабатываний приводит к тому, что пользователь сканера уязвимости перестает ему доверять и начинает проверять, обычно вручную, каждую уязвимость, найденную сканером. Очевидно, что это трудоемкое непроизводительное занятие заставит пользователя задаться, по крайней мере, одним вопросом: «Зачем был куплен такой дорогой сканер?» С другой стороны, упущения – это такая ситуация, когда сканер не обнаруживает фактически существующую проблему. Это более опасная вещь. К счастью, упущения встречаются не так часто, и разработчику их легче исправить, но тем не менее следует знать об их существовании. Сказанное уже является причиной использования более одного сканера и, конечно, постоянного мониторинга своей системы.
Если читатель обслуживает большую сеть, то для него, вероятно, очень важна производительность сканера. На производительность сканера оказывают влияние много факторов. Двумя наиболее очевидными факторами являются механизм сканирования и выбранные производителем алгоритмы проверки существования уязвимости. В настоящее время большинство программ являются многопоточными приложениями, которые предусматривают их настройку пользователем. В результате пользователь может многое сделать для настройки производительности и сравнить производительность сканеров во время сканирования различных машин. Некоторые производители обратили внимание на эту проблему, предложив распределенные решения сканирования. В них используются многочисленные механизмы сканирования различных машин с выводом сообщений о результатах сканирования на центральную консоль отчетов. Теоретически это звучит как вполне приемлемое решение, но на практике приводит к проблемам, например к уменьшению пропускной способности сети и, конечно, к потенциальным проблемам защиты, если трафик не обрабатывается безопасным способом.