-
Итересное тестирование- Хардмауэры и брандмауэры
Первый раз встретил тестирование железных и программных бранмауэров
Участники:
Определимся с составом участников.
В красном углу ринга – программы в составе:
1. Agnitum Outpost Firewall PRO (32-bit) 6.0.2172.214.422.270
2. Sunbelt Kerio Personal Firewall 4.5.916
3. ZoneAlarm Free 7.0.408.000
4. Встроенный в Windows XP SP2 брандмауер
В синем углу – аппаратные версии файерволлов в составе:
1. D-Link DI-604, 4-port UTP Switch Hub Router, 10/100 Mbps
2. TRENDnet TW100-BRF114 4-port Firewall Router, 10/100 Mbps
http://www.xakep.ru/post/42593/default.asp
-
-
Будь в курсе!
Будь в курсе!
Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:
-
Что-то я не понял. Как аппаратный фаервол может блокировать ликтесты??? То ли я стал плохо соображать, то ли это тестирование есть полный бред.
-
-
Сообщение от
Geser
Что-то я не понял. Как аппаратный фаервол может блокировать ликтесты??? То ли я стал плохо соображать, то ли это тестирование есть полный бред.
Вот я тоже только что дочитал статью, два раза перечитал ... имхо изложенное там - бред, попытка сравнения ежа с удавом.
"аппаратного" Firewall в природе не существует - аппаратный Firewall - по сути своей микроЭВМ под Linux или иной операционкой, с двумя сетевыми карточками (или LAN + xDSL), и под ней крутится Firewall+NAT, настраиваемый через WEB интерфейс или Telnet. И этот самый "аппаратный" Firewall работает согласно заложенным в него правилам фильтрации трафика на уровне сетевых пакетов - и ему совершенно по барабану, кто послал пакет (и уж те более - какая программа его послала и что там в нее было при этом инжектировано) - для него важны только адреса и порты ... Поэтому тестирование аппаратного Firewall при помощи лик-теста, основанного на инжекте чего-то в процессы в сравнении с программными - совершенно недопустимая вещь ... и откуда берется вывод о том, что аппаратный Firewall справляется с тестом на инжект - загадка и нонсенс (как раз это аргумент сторонников программных FW - что программный может засечь модификацию контекста потока/памяти/инжект и т.п. в легитимный процесс, равно как работу нелегитимного и блокировать для них сетевую активность, а железке все это по барабану). Второй непонятный момент - в xDSL модемах по дефолту включен NAT (что приводит к автоматическому отрубанию всех входящих пакетов, если они не идут в ответ на запрос) и Firewall, но в Firewall стоит единственное разрешительное правило "пускать всех изнутри куда угодно". Никакого режама обучения и т.п. у железки нет - ее предварительно настраивать нужно, прописывая правила. В статье про это нет ни слова - следовательно тестированию подвергается не Firewall, а всего лишь NAT.
Второй момент - аппаратный Firewall не может защитить ПК от шпиона и трояна (и не мог никогда). Рассмотрим типовой случай - обычного пинча. Pinch собирает пароли, затем генерит содержащий их бинарник и передает его заданным методом, в большинстве современных - методом POST на заданый хост, где его принимает и сохраняет скрипт. Так вот, если компьютеру X разрешено на аппаратном FW работать в Инет, то FW без проблем пропустит передаваемые пинчем данные, так как с точки зрения FW это обычное обращение к некоему сайту по протоколу HTTP. И аналогичное произойдет с практически всеми троянами-шпионами и т.п. Аналогично если зловред инжектируется в браузер и будет открывать странички или подменять их контекст, если он будут перенаправлять запросы на другой сайт и т.п. - аппаратный FW тут не поможет. Единственное, что может сделать аппаратный FW - пресечь скажем передачу данных по нестандартному порту, да и то при условии, что заранее созданы правила и в них обозначено, по каким портам можно работать, а по каким - нет. Автор же делает диаметрально противоположный вывод, вводя читателей в опасное заблуждение.
У меня есть подозрение (я проверил его экспериментально - сработало ), что из-за кривых настроек модемы автора тестов просто банально не работали, в результате обмен с Инет был невозможен и естетственно все запускаемые тесты показывали, что они пройдены (так как не могли обменяться с Инет и думали, что это заслуга FW) - это единственное разумное объяснение описанной в статье картины
Последний раз редактировалось Зайцев Олег; 01.06.2008 в 15:42.
Причина: добавлено
-
-
Решил посмотреть, кто и чем занимается автор статьи: Дмитрий Родионов
Возраст: 26 лет
Работа: гарантийный отдел Ultra Electronics
Основные увлечения(связанные с компьюторами): разгон всего, что имеет отношение к компьютерам
Оверлокер и специалист по информационной безопасности далекие от друг друга направления
Добавлено через 51 минуту
Кстати при прописанных правилах аппаратный FW вполне эффективен, например:
при возможности локального (не сетевого) заражения бекдором - приложением, открывающим доступ к системе через сеть. Бекдор, как правило, устанавливается как сервис при запуске злонамеренной программы и ожидает соединения на какой-либо порт в системе (как правило, в целях получения команд от злоумышленника). Если закрыть возможность установления соединения на все порты, кроме разрешенных, бекдор никогда не дождётся соединения клиентской части.
Последний раз редактировалось SDA; 01.06.2008 в 16:58.
Причина: Добавлено
-
-
Сообщение от
SDA
Кстати при прописанных правилах аппаратный FW вполне эффективен, например:
при возможности локального (не сетевого) заражения бекдором - приложением, открывающим доступ к системе через сеть. Бекдор, как правило, устанавливается как сервис при запуске злонамеренной программы и ожидает соединения на какой-либо порт в системе (как правило, в целях получения команд от злоумышленника). Если закрыть возможность установления соединения на все порты, кроме разрешенных, бекдор никогда не дождётся соединения клиентской части.
И в принципе без правил тоже ... по умолчанию NAT односторонний, т.е. при получении запроса на подключение по порту X извне он просто не знает, что с ним делать и кому его отдать - и в результате входящие подключения становятся невозможными (для получения такой возможности нужно в явном виде прописать, что при коннекте скажем по порту 80 нужно отнатить запрос на порт X хоста Y во внутренней сети). Однако зверь может это обойти - периодически коннектиться к заданному хосту по собственно инициативе и запрашивать, какие есть указания. В этом случае прослушивание портов не требуется и зловред может работать из сети за Firewall и NAT
-
-
Прочел статью, бред! Автору незачет!
-
-
Сообщение от
Зайцев Олег
зверь может ... периодически коннектиться к заданному хосту по собственно инициативе и запрашивать, какие есть указания. В этом случае прослушивание портов не требуется и зловред может работать из сети за Firewall и NAT
По мнению вирусных аналитиков, это так и происходит в подавляющем числе ботнетов.
-