# Форум на русском языке  > Решения по информационной безопасности  > Межсетевые экраны (firewall)  >  Итересное тестирование- Хардмауэры и брандмауэры

## SDA

Первый раз встретил тестирование железных и программных бранмауэров
Участники: 

Определимся с составом участников.

В красном углу ринга – программы в составе:

   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 - пресечь скажем передачу данных по нестандартному порту, да и то при условии, что заранее созданы правила и в них обозначено, по каким портам можно работать, а по каким - нет. Автор же делает диаметрально противоположный вывод, вводя читателей в опасное заблуждение. 
У меня есть подозрение (я проверил его экспериментально - сработало  :Smiley:  ), что из-за кривых настроек модемы автора тестов просто банально не работали, в результате обмен с Инет был невозможен и естетственно все запускаемые тесты показывали, что они пройдены (так как не могли обменяться с Инет и думали, что это заслуга FW) - это единственное разумное объяснение описанной в статье картины

----------


## SDA

Решил посмотреть, кто и чем занимается автор статьи: Дмитрий Родионов 

Возраст: 26 лет

Работа: гарантийный отдел Ultra Electronics

Основные увлечения(связанные с компьюторами):  разгон всего, что имеет отношение к компьютерам
Оверлокер и специалист по информационной безопасности далекие от друг друга направления  :Smiley: 

*Добавлено через 51 минуту*

Кстати при прописанных правилах аппаратный FW вполне эффективен, например:

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

----------


## Зайцев Олег

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


И в принципе без правил тоже ... по умолчанию NAT односторонний, т.е. при получении запроса на подключение по порту X извне он просто не знает, что с ним делать и кому его отдать - и в результате входящие подключения становятся невозможными (для получения такой возможности нужно в явном виде прописать, что при коннекте скажем по порту 80 нужно отнатить запрос на порт X хоста Y во внутренней сети). Однако зверь может это обойти - периодически коннектиться к заданному хосту по собственно инициативе и запрашивать, какие есть указания. В этом случае прослушивание портов не требуется и зловред может работать из сети за Firewall и NAT

----------


## Jolly Rojer

Прочел статью, бред! Автору незачет!

----------


## DVi

> зверь может ... периодически коннектиться к заданному хосту по собственно инициативе и запрашивать, какие есть указания. В этом случае прослушивание портов не требуется и зловред может работать из сети за Firewall и NAT


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

----------

