ЗАШИТНИ СТЕНИ - iseca.orgФакултет по математика и...

1

Софииски университет „Климент Охридски”

Факултет по математика и информатика

проект за курса

„МРЕЖОВА СИГУРНОСТ”

на тема

ЗАШИТНИ СТЕНИ

(Firewalls)

на

Дарин Йончев Йончев

ф.н. 43524, информатика II курс IV група

и

Изидор Йосиф Калев

ф.н. 43338, информатика II курс IV група

2004

2

Какво представлява защитната стена Защитна стена може да бъде всяко устройство, използвано Като механизъм за контрол на достъпа до конкретна мрежа или набор от мрежи. В повечето случаи защитните стени служат да предотвратят достъпа на външни лица до врешната мрежа. Но защитните стени могат да служат за създаване на по-сигурни участъци Вътре във вътрешната локална мрежа за особено важни функции като ведомости, разплащания и R.&D системи. Те могат да се разполагат не само по външните граници. Самите устройства „защитни стени" обикновено са отделни Компютри, маршрутизатори или защитни приспособления. Защитните приспособления обикновено са специфични хардуерни устройства, често работещи под специфична операци на система. Серията С1зсо РIХ е добър пример за защитно приспособление. Защитните стени са проектирани да служат като контролно-пропускателна точка към и от мрежата ви.Те обработват пристигащите заявки. Проверяват дали трябВа да бъде пропуснат или не мрежовият трафик, на базата на предварително дефинирани правила или „политики". Пропускат се само заявките за връзка от оторизирани хостове към оторизирани дестинации; останалите заявии се отхвърлят. Повечето защитни стени го правят, като проверяват адресите на изпращача и получателя заедно с номерата на портовете. Например, ако не искате хората от hacker.com да използват услугата FТР на локания sever, може да се блокират заявките за връзка от 206.246.131.227 на порт 21.

Други възможности на защитните стени Защитните стени могат да анализират входящите пакети от различни протоколи. На базата на този анализ, защитната стена може да предприеме различни действия. Тези условни конструкции се наричат правила. По принцип, когато издигате защитна стена, Вие я обзавеждате с правила, отразяващи политиката за достъп на вашата организация. Например, да речем, че имате счетоводен и търговски отдел, фирмената политика изисква само търговският отдел да има достъп до FTP услугата. За да се наложи тази политика,се въвежда правило на защитната стена което гласи; заявите за връзка от счетоводството към 21 порт на фирмения server да се отхвърлят. В това отношение, защитните стени са за мрежите това, което са схемите на потребителските привилегии за операционните системи. Например, във Windows NT/2000/2003 и стандартно във всички UNIX базирани опрационни системи можете да се укаже кои потребители да имат достъп до даден файл или директория. Това е Контрол на достъпа на ниво операционна система. Аналогично, чрез защитните стени може да се прилага такъв контрол на достъпа към дадена работна станция или сървърни услуги. Но проверката за право на достъп е само част от това, което могат съвременните системи „защитни стени”. През последните години създателите на „защитни стени” започнаха интегриратвсе повече и повече възможности във своите продукти.Някой от които са следните: • филтриране на съдържанието. Някои организации искат да попречат на потребителите си да

разглеждат определени Web сайтове (разпространяващи нелегален софтуеар, с порнографско садържание и т.н.). Филтрирането на съдържанието помага за блокиране на такива сайтове, а също и защитава от някой видове опасни аплети и код на ActiveX и Java.

• Виртуални частни мрежи (VPN). VPN се използват за сигурно пренасяне на трафика от точка А до точка B, обикновено през враждебна мрежа (като Интернет). Въпреки, че сега на пазара има широка гама специализирани VPN приспособления, CheckPoint и Cisco успешно вграждат VPN услуги в своите продукти на „защитни стени”. Много защитни стени сега предлагат и двете: VPN ой клиент до организация и LAN-до-LAN връзка.

• Транслиране на мрежови адреси (Network Address Transformation NAT). Транслирането на мрежовите адреси често се използва за асоцииране на забранени или резервирани блокове адреси ( RFC 1918) с валидни такива (например, асоцииране на 10.0.100.3 с 206.246.131.227). Макар че NAT не е непременно защитно средство, първите NAT устройства, появили се в корпоративните мпежи обикновено са част от защитна стена.

• Балансиране на натоварването. Едно от най-основните понятия. Балансирането на натоварването е възможността за сегментиране и разпределяне на трафика. Някои защитни стени сега позволяват да насочите Web и FTP трафика по разпределен начин

• Повишена отказо-устойчивост. Някои от съвременните защитни стени, като Cisco PIX и комбинацията Nokia/Checkpoint: подържат няkои много хитроумни средства за справяне със сривове на системата. Често наричани High-Availabilty (HA), усъвършенстваните средства за устойчивост на срив често позволяват защитните стени да работят на чифтове, като едното

3

устройство стои в готовност и може да поеме работата, ако другото се срине. • Откриване на проникване( Intrusion detection ). Това само по себе си не създава проблем, но

допълнително натоварва защитната стена и може да предизвика забавяне на мрежовия трафик и понижаване на работоспособността на защитната стена.

Защитните стени винаги се постявят като ключово звено в защитата. Като заключение, може да се каже, че претрупването с допълнителни функции които нямат пряко отношение към основната цел на приложжението не е добро, когато става дума за защитен продукт. Най-новите уязвимости на защитните стени се пораждат в голяма степен от тези нововъведения .

Идейна страна при изграждането на защитна стена В екзотичен смисъл, компонентите на защитната стена съществуват в главата на създателя й. Тя е идея, а не продукт; идеята за обвивка на механизъма за контрол на достъпа. В по-конкретен смисъл, защитната стена се състои от софтуер и хардуер. Софтуерът може да бъде частен или свободен. Хардуерът може да бъде всеки хардуер, който поддържа софтуера. Технологиите на защитна стена могат да бъдат Класифицирани в три категории: • Базирани на филтриране на пакети (обикнвени маршрутизатори, Cisco IOS и т.н.) • Защитни стени с пакетно филтриране и състояние (Checkpoint FW-1, Cisco PIX и т.н) • Прокси-базирани (Gauntlet, Axent Raptor и т.н.)

Да разгледаме накратко всяка.

Защитни стени базирани на филтриране на пакети Филтриращите пакети защитни стени обикнобено са маршрутизатори със способности да филтрират пакети. Чрез филтриращ пакети маршрутизатор можете да дадете или откажете достъп до даден ресурс на базата на няколко обективни фактора:

• Адрес на изпращача

• Адрес на получателя

• Протокол

• Номер на порт Маршрутизаторите - защитни стени са популярни защото лесно се реализират. (Инсталира се и просто се въвежда списак с правила. за филтриране на трафика) Освен това, маршрутизаторите са интегрално решение. Ако мрежата на дадена организация е постоянно сбързана с Интернет, то неизбежно съществъва такъв маршрутизатор и е по-лесно и ефтино да се използва като защитна стена. От друга страна, маршрутизаторите - защитни стени имат няколко недостатъка. Първо, те обикнобено не могат да се справят с някой видобе DoS атаки Много от днес използваните DoS атаки се основават на модифицирани пакети, SYN flood или използвне на други TCP/IP аномалии. Обикновените маршрутизатори не са проектирани да се справят с този вид атаки. Второ, повечето маршрутизатори не следят състоянието на сесията., което налага отварянето на допълнители портове за да се договарят и обработват правилно TCP сесиите. Накрая, използването на ACL (Access Control Lists - списъци за Контрол на достъпа) в големите маршрутизатори на извънредно натоварени мрежи може да допринесе за спад на скоростта и натоварване на процесорите им. Но при бавните връзки (Като Т1 мрежи) през по-малките маршрутизатори (Като серията Cisco 2500), нормалното филтриране на пакети не добавя значително натоварване. От доста време се води спор далие удачно подържането на ACL от маршрутизаторите.Някои изследвания по темата могат да се намерят на http://www.wiretrip.net/ . Добро решение на отзи проблем е да се използват ACL на гранични (периметърни) маршрутизатори заедно с по-усъвършенствана защитна стена за по-добра защита

4

Защитни стени с пакетно филтриране и състояние Защитните стени с пакетно филтриране и състояние надграждат концепцията за филтриране на пакети с няколко стъпки. Защитните стени от този модел помнят сесиите и връзките във вътрешни таблици на състоянието и могат да реагират съобразно него. Поради това, тези продукти са погъвкави от аналозите, които само филтрират пакети. В допълнение, повечето защитни стени с пакетно , филтриране и състояние са проектирани да защитават срещу различни видове DoS атаки. CheckPoint въведоха метода „инспекция на състоянието" (stateful inspection” SI), който извежда „пакетното филтриране със състояние" една крачка напред. SI позволява на администраторите да изграждат защитни стени с правила за проверяване на полезния товар на пакета, а не само на адреса и порта Понеже защитните стени с пакетно филтриране и състояние следят състоянието на сесиите, те могат да държат по подразбиране портовете над 1024 затворени и да ги отварят само при нужда.

Прокси-базирани защитни стени Друг тип защитна стена е прокси-базираната защитна стена (понякога наричана шлюз на приложенията или прокси на приложенията). Когато отдалечен потребител се свърже с мрежа, използваща прокси-базираната защитна стена, тя служи като прокси на връзката. При този метод IP пакетите не се предават директно към вътрешната мрежа. Вместо това има някакъв вид превеждане, като прокси-базираната защитна стена служи за посредник и интерпретатор. Доакто пакетното филтриране и пакетното филтриране със състояние проверяват входящите и изходящи пакети на мрежовия и сесийния слой, т.е те проверяват адресите на изпращача и получателя, заедно с флаговете на портовете и състоянието, сравняват ги със зададените правила и решават дали да пропуснат пакета, прокси-базираните защитна стените защитни стени, инспектират трафика на приложния слой в допълнение на по-долните слоеве. Пакетът пристига в защитната стена и бива предаден на специфично за приложението прокси, Което инспектира валидността на пакета и на самата заявка на приложния слой. Например, ако WEB (НТТР) заявка постъпи в прокси-базирана защитна стена, полезният товар на НТТР заявката ще бъде предаден на НТТР -прокси процес. FTP заявка ще бъде предадена на FTP - прокси процес, Telnet на Telnet - прокси процес и т.н. Концепцията на този подход „протокол по протокол" е по-сигурна от пакетното филтриране (обикновено или със състояние) понеже защитната стена разбира самите приложни протоколи (НТТР, FТР, SМТР, РОР и т.н.).. На практика обаче, този подход среща достатъчно много проблеми. Прокси-базираните защитни стени Винаги са били по-бавни от онези с пакетно филтриране със състояние. За повечето мрежи (10 МЬрs или по-бавни) тази разлика не е съществена. Но за силно натоварени мрежи (ТЗ на 45МЬрs, мулти ТЗ със 100МЬрs и т.н.) проблемат не е малък.. С подобряването на технологията, разликата може да намалее, но засега прилагането на чисто прокси-базирана технология Все още е проблем.

Освен проблема с производителността, прокси-базиното решение има проблема на адаптиране. т.е. ако например е създаден нов протокол който използва TCP и работи на порт 432 Администраторите на защитни стени с пакетно филтриране и състояние просто ще трябва да добавят ново правило относно ТСР трафика през порт 432 и това е всичко. Администратори те на прокси-базирани защитни стени, обаче, имат проблем. Те нямат прокси за този протокол . Макар, че някои прокси-базирани защитни стени (например Gauntlet на NAI) имат генерално прокси за подобни проблеми. От теоретична гледна точка прокси-базираният подход е малко по-сигурен от чистото пакетно филтриране и състояние но продуктите, базирани на този подход могат да създават доста трудности.

Някои правила при изграждане на защитна стена 1. Платформите защитни стени се променят - не съществува съвършена платформа. Например,

производителят Х може да е затънал в няколко поредни версии и накрая да ги събере в една добра. По същото Време, производител У и производител Z може да имат чудесни продуКти една година и да затънат следващата. Добре е да се следят тестовете в специализираните списания като Network computing и InfoWorld,или Security ориентирани wab сайтове и най-вече да се тестват продуктите, когато това е възможно.

5

2. Формулиране на изискванията които трябва да покрива защитната стена която ще се изгражда. Трябва ли защитната стена да поддържа Token Ring или само Ethernet? Трябва ли да поддържа превръщане на мрежовите адреси (Network Address Transformations - NАТ)? ТрябВа ли да може да работи върху определена платформа? Хората прекалено често затъват в цифрите на тестовите резултати и в дългите списъци на опциите. Защитната стена предимно ще контролила достъпа към и от дадена мрежата .

3. Определяне на средата в която ще се оперира защитната стена и квалификацията на административния екип. Например ако ще се използва предимно на Windows NT базирана мрежа, и администратора и е без опит с UNIX, купуването на UNIX базирана защитна стена, искаща познаването на много UNIX Команди, не е най-добрата идея.Факт е, че голяма част от пробивите на защитни стени са причинени от грешка при конфигурирането им - т.е. провалила се е не стената, а администраторът. Също така не трябва да се избира защитната стена по красивия интерфейс, но не е добра идея и изискващият научна степен за да работиш с него. Най-доброто решение е това което предоставя лесен достъп до циялата функционалнист на зашитната стена .

4. Добре е да се избере продукт, който има поне сертификат ICSA и за предпочитане доста потребители до момента. Това означава че избраната защитна стена е успяла да докаже своите достойнства в реални ситуации и са отсранени повечето проблеми свързанои с експлоатацията и .

5. Един от проблемите е, че защитата може да бъде конфигурирана толкова строго, че на практика да пречи на мрежовата работа. Например, някои изследвания твърдят, че употребата на защитни стени е непрактично в мрежови среди, където потребителите са силно зависими от разпределени приложения. Понеже защитни стени могат да наложат много строги политики, тези среди не могат да работят пълниценно, каквото печелят в сигурност, губят във функционалност. За някого това може да изглежда само неудобство. Но В дългосрочен план проблемът може да бъде разрушителен.

Преди да се закупи защитна стена, трябва сериозно да проучи собствената мрежа, потребителите и техните нужди. Добе е да се направят графични схеми на връзките, които ще преминават през стената. Това не само ще помогне да определите изискванията към нея, но и ще остави документ уточняващ защо са оставени определени отворени места и кои процеси и хора стоят зад тях. Този документ може да бъде полезен след години на бъдещия системен администратор.

Основни етапи при изграждането на защитна стена: 1. Определяне нуждите на топологията, приложенията и протоколите. 2. Анализиране на доверените отношения и комуникационите пътища във вашата мрежа .

3. Тестване и избор на защитна стена.

4. Планиране на разположението на зашитната стена.

5. Тестване зададените на стената правила.

Определяне нуждите на топологията, приложенията и протоколите Първо би трябвало да се започне с определянето на нуждите на топологията, приложенията и протоколите. Тази стъпка е по-трудна, отколкото изглежда, в зависимост от размера и композицията на мрежата. Ако управлявате една малка хомогенна мрежа и се нуждаете само от оснвните протоколи (SМТР, НТТР, FТР и т.н.). Предстоящата би задача е лесна. Но ако като в повечето организации, се налага да поддържате смесени платформи, протоколи и приложения. Това може да изглежда лесно, но бързо може да създаде хаос. Например, различните приложения ше се нуждаят от различен достъп до различните ресърси на организацията , като при това могат да възникнат голям брои конфликти , допълнителен набор от отворени портове , подържане на права за достъп за различните приложения или потребители. Често един проблем пожлича сле д себе си и други и .т.н Компаниите, фокусирани върху електронната търговия, понякога разделят продуктовата си мрежа от бътрешните LAN услуги. Това позволява да се отделят критичните от по-мако критичните системи в организацията, например on-line банкирането от локалния FTP трафик, или вътрешният

6

SMTP трансфер.Този проблем се решава чрез подходящо избрана топология.

Колко интерфейса ще се нуждае защитната стена за да поддържа тази . топология? Колко защитни стени ще трябват? Има ли нужда от изгражадане на клъстер система (работеща резерва, готоба да се включи веднага, ако има срив на първата)?.

Анализиране на доверените отношения и комуникационите пътища Както трябва да знаете външните връзки на организацията, така трябва да се определят вътрешните. Причините са няколко. Първо, приложенията трябва да работят. Ако преместите приложните сървъри в сегмента зад защитната стена и ги отрежете от сървърите на бази данни, приложенията няма да работят. Ако пък отворен за Интернет сървър има неограничен достъп до вътрешната мрежа, това е потенциална дупка в сигурноста. Трябва предварително да се допитате с различните отдели или потребители. Някои мрежови сегменти може би имат нужда от достъп до ресурсите на други сегменти. Тези отношения трябва да се анализират.

Тестване и избор на защитна стена Първоначално трябва да се обобщят изискваниятакъм защитната стена и да се изберете такава, която ги удолетворява наи-цялостно. Най-добрият начин да го направите е да се извършат тестове в лаборатория. Но за това са необходими лаборатория и няколко свободни седмици за тестове. Ако това е невъзможно по една или друга причина най-добре е да се попита производителя къде може да се видити продукта в действие. Ако производителят е добър, най-вероятно ще може да ви помогне. Обичайните критерии за избор на защитна стена са: • Капацитет. Може ли защитната стена да поддържа предвиждания трафик? Може ли да се

скалира (разширява)? Обикновено, ако става дума за ТЗ (45МЬрs) или по-малКо, почти всяка защитна стена Върши работа.

• Възможности. Претрупването с опции е опасно, но ако ги има трябва да сотговарят на задачите които се поставят пред зашитната стена. Възможностите на защитната стена трява да са по възможност оганичени до това което ни е небходимо и нишо повече.

• Административен интерфейс. Ако интерфейсът не е удобен или е неразбираем, това повишава верятноста за сгрешки от грешно конфигуриране на зашитната стена или невъзможност за използване на целия и капацитет.

• Цена. Винаги е от значение. Но да се купи наи-добрият продук на пазара не винаги е най-добрата инвестиция Понякога вторият от списъка продукт е достатъчно добър и много по-евтин.

• Репутация. Дали пробивите се дължат на производителя? Каква е историята на продукта? Дали има Вече доста потребители или е нов?Добре е да се направи справка в независимите тестови лаборатории и уважавани списания и on-line източници (.http://www.nwc.com )

Планиране на разположението на зашитната стена Накрая, след закупуването на защитна стена, се налага инсталирането и и въвеждане на правилата и полотиките които ще подържа. Първо се уверете, че самата защитна стена е защитена. Ако това е приспособление, Вероятно ще трябва само да промените подразбиращите се пароли. Но ако това е базирана на Windows NT или UNIX защитна стена, уверете се, че операционната система, върху която я разполагате, е без пропуски в сигутността Следващата стъпка е да включите защитната стена в продуктовата мрежа Ако предварителното планиране е добро, ще можете да преместите сървърите един по един зад стената. Но най-често не става толкова лесно. Очаквайте проблеми и бъдете готоби мрежата би да не е налице известно време докато се наложат желаните права и се изчистят несъвместимостите. Накрая остава да тествате зададените правила. Препоръчвам ви обширни тестове. Има две фази:

• Тестване на правилата отвън

7

• Тесване на правилата отвътре

Може да се използва инструмента NMAP за да направи моментна снимка на мрежата от вътрешна перспектива (зад стената) и от външна перспектива (отвън стената). Най-важния принцип, - DEFAULT DENY (по подразбиране „забранено"). Ако не се разбира дадена опцията, не бивада се пропуска през стената. Важно е след разполагането на стената да се установи процес на перио-дично преглеждане на регистровите файлове на защитната стена. Така ще се открият потенциалните проблеми и тенденциите на конфигурацията и потенциалните нарушители.

Някои основни аспекти на защитните стени под Linux

Ще разгледаме какви настройки са необходими за един сървър от нисък клас, като ще се разгледа конфигурационения файл за iptables. Хубаво е да се знае, че важни машини/мрежи седят зад специален компютър, конфигуриран само като защитна стена firewall. Такива комбинации могат да са (firewall/server): BSD/w2k; linux/nt с т.н. Ако се налага наистина тежка защита този вариант е едно добро решение

Конфигуриране на iptables за Линукс. Като начало трябва да се добави поддръжката на защитна стена в ядрото на опрационата система. Товастава от (menuconfig) → Networking Support→ [Network firewalls,

TCP/IPNetworking, IP: firewalling, IP: firewall packet logging] →

Network packetfiltering → IP: Netfilter configuration. Сега трябва да се прекомпилира ядрото и да се направи активно. iptables се използва както за конфигурирането на IP филтрирането, така и за транслирането на мрежови адреси. За улеснение са добавени 2 таблици с правила - filter и nat. Първата таблица е по подразбиране ако не е зададена опцията -t. За таблицата filter съществуват 3 вериги (chains) а те са: INPUT; FORWARD и OUTPUT. Тук ще разгледаме само таблица filter. Общия вид на командата е: iptables команда правило разширения. Ето и списък на някои от опциите (за пълен списък → man iptables).

-A верига Добавя едно или повече правил акъм края на указаната верига. Ако е подадено име на хост като изпращач или като получател и то съответства на повече от 1 IP адрес, правилото ще бъде добавено за всеки адрес. -I верига номер_на_правило Вмъква едно или повече правила в началото на указаната верига. Ако е подадено имена хост като изпращач или като получател и то съответства на повече от 1 IP адрес, правилото ще бъде добавено за всеки адрес.

-D верига Изтрива едно или повече правила от зададената верига, съответстващо на спецификацията на правилото.

8

-D верига номер_на_правило Изтрива правилото намиращо се на позиция номер-на-правило в указаната верига. Позицията на правилото започва от 1 за първото правило на веригата. -R верига номер_на_правило Замества правилото, намиращо се на позиция номер-на-правило в дадената верига с дефинираната спецификация на правило. -C верига Проверява дали дейтаграмата, описана от зададеното правило, съотвтства на определената верига. Тази команда ще върне съобщение, описващо как веригата обработва дейтаграмата. Много ползно при тестването на защитната стена.

-L [верига] Генерира списък на правилата в посочената верига или във всички вериги, ако не е посочена верига.

-F [верига] Изчиства правилата в посочената верига или във всички вериги, ако не е посочена такава. -Z [верига] Нулира броячите на дейтаграми и байтове за всички правила в посочената верига или във всички вериги, ако не е посочена такава. -N [верига] Създава нова верига с посоченото име. Верига със същото име не трябва да съществува. Така се създават потребителско-дефинирани вериги.

-X [верига] Изтрива посочената потребителска верига или всички потребителски вериги, ако не е посочена такава. За да бъде успеша тази команда, не трябва да има препратки към посочените вериги в коятои да е друга верига от правилата. -P верига политика Задава подразбираща се политика за посочената верика като указаната политика. Валидните политики за защитна стена са ACCEPT, DROP, QUEUE и RETURN. ACCEPT позволява на дейтаграмата да премине, при DROP дейтаграмата се игнорира, при QUEUE дейтаграмата се изпраща в потребителското пространство за по - нататъшна обработка, а при RETURN кодът за IP защитна стена се връща към веригата от защитната стена, която е извикала веригата, съдържаща това правило и продължава обработката от правилото, следващо извикващото правило. Параметри за задаване на правила Има множество параметри на iptables, които съставят спецификацията на правило. Където е необходима спецификаци на правило, трябва да се подаде всеки един от тези параметри или ще се възприемат техните стойности по подразбиране.

9

-p [!]протокол Определя протокола на дейтаграмата, която ще съответства на това правило. Валидните имена за протоколо са tcp, udp, icmp или число ако знаете номера на IP протокола (cat /etc/protocols). Ако се изплзва знак !, правилото се инвентира и дейтаграата ще съответства на всеки протокол, различен от посочения. Ако този параметър не е подаден, по подразбиране ще се възприеат всички протоколи. -s [!]адрес[/маска] Определя изходния адрес на дейтаграмата, която съответства на това правило. Адресът може да бъде подаден като име на хост, име на мрежа или IP адрес. Маската е незадължителна и може да се подаде по 2 начина - 255.255.255.0 или с /24 вариант-а...

-d [!]адрес[/маска] Задава адрес и порт на получателя на дейтаграмата, която съответства на това правило. Кодирането на този параметър е същото както при -s. -j цел Задава какво действие трябва да се предприеме, при откриване на съответствие с това правило. За този параметър можете да мислите като за команда "иди на". Валидни цели са ACCEPT, DROP, QUEUE и RETURN. Можете да посочите името на потребителски дефинирана верига, където да продължи обработката. Можете да зададете името на целта чрез разширение. Ако този параметър е пропуснат, при съответствие на дейтаграмата не се предприемат никакви действия освен да се актуализират броячите на дейтаграми и байтове за това правило.

-i [!]име-на-интерфейс Задава интерфейса, на който е получена дейтаграмата. Ако името на интерфейса завършва с + тогава всеки интерфейс с подадения низ ще действа (пример: -i ! eth+ -- всички интерфейси освен мрежовите устройства) -o [!]име-на-интерфейс Задава интерфейса, на който ще бъде предадена дейтаграмата. Този аргумент се кодира по същия начин както -i. Опции

-v Указва на iptables да генерира по - подробен изход. Това предоставя овече информация.

-n Указва на iptables да показва IP адреса и портовете като номера, без да с опитва да ги свърже с техните съответстващи имена.

-x Указва всички числа в изхода на iptables да бъдат разшиени до тяхната пълна стойност без закръгляване. -line-numbers Указва при изброяване на правилата да бъдат показвани номерата на редовете. Номерът на реда ще съответства на позицията на правилото във веригата. Разширения iptables е обновена версия на защитната стена на Линукс при 2.4 ядрата. Разликата м/у ipchains и по - старите версии не е особено голяма, с изключение на разширяемостта. Можете да разширите до известна степен възможностите му, като използвате различни модули - споделени библиотеки.

10

Съществуват някои стандартни разширения, които осигуряват част от възможностите, предлагани от iptables. За да се използва едно разширение, трябва да се зададе неговото име чрез аргумента на iptables -m име. Следващия списък показва опциите -m и -p, които определят контекста на разширението, както и опциите, предоставяни от това разширение. TCP разширения: използвани с -m tcp -p tcp -sport [!] [порт[:порт]] Задава порта, който трябва да използва от изпращача на дейтаграмата, за да съответства на това правило. Портовете могат да бъдат посочени като интервал, разделени с двоеточие. Пример: 80:82 за портове 80, 81 и 82 вкл. -dport [!] [порт[:порт]] Задавапорта, който трябва да се използва от получателя на дейтаграмата, за да съответства на това правило. Кодира се както при --sport. -tcp-flags [!] маска комп Указва, че това правило ще съответства, когато TCP флаговете в дейтаграмата съвпадат с посочените от маска и комп. Маската е списък от разделени със запетая флагове, които трябва да бъдат проверени при извършване на теста. комп е списък от разделени със запетая флагове, които трябва да бъдат подадени, за да съвпада правилото. Валидни флагове са: SYN, ACK, FIN, RST, URG, PSH, ALL и NONE. See RFC-793. -tcp-flags SYN,RST,ACK SYN Указва. че правилото съответства само на дейтаграми с вдигнат бит SYN и свалени битове ACK и FIN. Дейтаграмите с тези опции се използват за отваряне на TCP връзки, затова тази възможност може да бъде изпозлвана за управление на заявките за връзки. UDP разширения: използвани с -m udp -p udp -sport [!] [порт[:порт]] Определя порта, който трябва да се използва от изпращача на дейтаграмата, за да съответства на това правило. Портовете могат да бъдат посочени като интервал, разделени с двоеточие. Пример: 80:82 за портове 80, 81 и 82 вкл. -dport [!] [порт[:порт]] Определя порта, който трябва да се използва от получателя на дейтаграмата, за да съвпада с това правило. Кодира се както при --sport ICMP разширения: използвани с -m icmp -p icmp -icmp-type [!] име-на-тип Определя типа на ICMP съобщението, на което трябва да съотетства това правило. Типът може да бъде зададен чрез номер или чрез име. Някои валидни имена са: echo-request, echo-reply, source-quench, time-exceeded, destination-unreachable, network-unreachable, host-unreachable, protocol-unreachable. MAC разширения: използвани с -m mac -mac-source [!] адрес Задава Ethernet адрес на хоста, който е предал дейтаграмата, за да съответства на това правило. Това има смисъл само в правило във входящата или препредаващата верига, защото ще предаваме всяка дейтаграма, която премине изходящата верига. Най - лесно е да се направи стартов файл в /etc/rc.d. (например rc.firewall)от вида: #!/bin/sh # chmod 755 rc.firewall IPT=/usr/sbin/iptables

11

# Our IP space OURNET="192.168.1.0/24" OURBCAST="192.168.1.255" OURDEV="eth0" # Out OUTADDR="0/0" OUTDEV="eth1" # TCP Services TCPIN="ssh ftp" TCPOUT="smtp www ftp ftp-data irc ssh telnet" # UDP Services UDPIN="domain" UDPOUT="domain" # ICMP Services # 0 Echo Reply # 3 Destination Unreachable # 4 Source Quench # 5 Redirect (change route) # 8 Echo Request # 11 Time Exceeded # 12 Parameter Problem # 13 Timestamp Request # 14 Timestamp Reply # 15 Information Request # 16 Information Reply # 17 Address Mask Request # 18 Address Mask Reply ICMPIN="0 3 11" ICMPOUT="8 3 11" # Chisti rulez wyw whodqshtata tablitza $IPT -F FORWARD # Otkazwane na whodqsht dostyp $IPT -P FORWARD deny # Ignorira polucheni datagrams $IPT -A INPUT -i $ANYDEV -j DROP # Spoof protection $IPT -A FORWARD -s $OURNET -i $ANYDEV -j DROP # Smurf protection $IPT -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET -j DENY # Priemane na fragmenti $IPT -A FORWARD -f -j ACCEPT # TCP datagramz ACK (+) $IPT -A FORWARD -m multiport -p tcp -d $OURNET --dports $TCPIN / ! --tcp-flags SYN,ACK ACK -j ACCEPT $IPT -A FORWARD -m multiport -p tcp -s $OURNET --sports $TCPIN / ! --tcp-flags SYN,ACK ACK -j ACCEPT # TCP Incoming $IPT -A FORWARD -m multiport -p tcp -i $ANYDEV -d $OURNET $TCPIN / --syn -j ACCEPT # TCP Outgoing $IPT -A FORWARD -m multiport -p tcp -i $OURDEV -d $ANYADDR / --dports $TCPOUT --syn -j ACCEPT #UDP Incoming $IPT -A FORWARD -m multiport -p udp -i $ANYDEV -d $OURNET /

12

--dports $UDPIN -j ACCEPT $IPT -A FORWARD -m multiport -p udp -i $ANYDEV -s $OURNET / --sports $UDPIN -j ACCEPT # UDP Outgoing $IPT -A FORWARD -m multiport -p udp -i $OURDEV -d $ANYADDR / --dports $UDPOUT -j ACCEPT $IPT -A FORWARD -m multiport -p udp -i $OURDEV -s $ANYADDR / --sports $UDPOUT -j ACCEPT # ICMP Incoming $IPT -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET / --dports $ICMPIN -j ACCEPT # ICMP Outgoing $IPT -A FORWARD -m multiport -p icmp -i $OURDEV -d $ANYADDR / --dports $ICMPOUT -j ACCEPT Придавт му се права за изпълнение с chmod 755 rc.firewall . Сега можете да се напише ./rc.firewall (cd /etc/rc.d ) start|stop|restart в зависимост от конкретните нужди.. Този скрипт може да се промени по желание

Пример за изграждане на зашитна стена под OpenBSD В този пример PF работи на OpenBSD система като firewall и NAT gateway за малка мрежа вкъщи или в малък офис. Необходимо е също да се предостави ограничен достъп до този firewall от Интернет.

Мрежата

Мрежата е реализирана както следва: [ COMP1 ] [ COMP3 ] | | ADSL ---+----+---+----- fxp0 [ OpenBSD ] ep0 ---- ( Internet ) | [ COMP2 ]

Броят на компютрите във вътрешната мрежа не е от първостепенна важност, затова на схемата са показани само 3. Компютрите са обикновени работни станции, използвани за web, email, chat и т.н. На вътрешната мрежа е отделен блок от мрежови адреси 192.168.0.0 / 255.255.255.0 .

OpenBSD системата е Pentium 100 с две мрежови карти: 3com 3c509B (ep0) и Intel EtherExpress Pro/100 (fxp0). Връзката на мрежата към Интернет е ADSL, като се използва NAT за да се разпредели тази връзка между всички компютри от вътрешната мрежа. IP адресът на външния интерфейс се получава динамично от Интернет провайдъра (ISP).

13

Целите

Основните цели са:

• Неограничен достъп за всички компютри от вътрешната мрежа • Използване на "забрана по подразбиране" набор от правила за филтриране • Разрешаване на firewall-ът на следния входящ от Интернет трафик:

o SSH (TCP port 22): ще бъде използван за поддръжка отвън на firewall машината o Auth/Ident (TCP port 113): използва се от услуги като SMTP и IRC o ICMP Echo Requests: тип на ICMP пакета, използван от ping

• Запазва статистическа информация за външния интерфейс • По подразбиране отговаря с TCP RST или ICMP Unreachable за блокираните пакети • Наборът с правила да бъде колкото е възможно по-прост и лесен за управление

Подготовка

Предполага се, че OpenBSD системата е правилно конфигурирана за да действа като рутър. Това включва: проверка на IP мрежовите настройки, връзката към Интернет и установяването на net.inet.ip.forwarding в "1".

Реализация на наборът с правила

Макроси

За упростяване на четенето и поддръжката на набора с правила са дефинирани следните макроси:

int_if = "fxp0" ext_if = "ep0" tcp_services = "{ 22, 113 }" icmp_types = "echoreq" priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

Първите два реда задават мрежовите интерфейси, на които ще се реализира филтрирането. Третият и четвъртият ред съдържат списък с номерата на TCP портовете на услугите, достъпни за ползване от Интернет (SSH and ident/auth) и типовете ICMP пакети, на които е разрешено да достигат до firewall машината. Последният ред дефинира адреса на loopback интерфейса и RFC 1918 блоковете от адреси. Всъщност ако ADSL връзката изисква PPPoE, тогава филтрирането и NAT трябва да се реализират на tun0 интерфейса, а не на ep0.

Параметри

Следните два параметъра дефинират отговора по подразбиране на block правилата за филтриране и разрешават събирането на статистическа информация за външния интерфейс:

set block-policy return set loginterface $ext_if

14

"Пречистване"

Няма причина да не използваме препоръчителното пречистване на целия входящ трафик, затова ето едноредово правило за това:

scrub in all

Трансформация на мрежовия адрес (NAT)

За да реализираме NAT за цялата вътрешна мрежа се използва nat правило:

nat on $ext_if from $int_if:network to any -> ($ext_if)

Поради това, че IP адресът на външния интерфейс се получава динамично, около името на интерфейса има скоби, за да бъде уведомен PF за промени в адреса.

Пренасочване

Пренасочване е необходимо единственото за ftp-proxy, така че FTP клиентите от вътрешната мрежа да се свързват безпроблемно с FTP сървърите в Интернет.

rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021

Това правило обхваща само връзки към порт 21. Ако потребителите редовно се свързват с FTP сървърите на други портове, трябва да се укаже списък с портове, например: from any to any port { 21, 2121 }.

Правила за филтриране

Нека първо да започнем със забраната по подразбиране:

block all

На този етап нищо не преминава през firewall-а, дори от вътрешната мрежа. Правилата, които следват ще отворят firewall-а, както и необходимите виртуални интерфейси според целите, поставени по-горе.

Всяка Unix система има "loopback" интерфейс. Това е виртуален мрежов интерфейс, с помоща на който приложенията в самата система комуникират помежду си. Обикновено целият трафик на този интерфейс трябва да е разрешен. В OpenBSD, loopback интерфейса е lo(4)

pass quick on lo0 all

След това, RFC 1918 (http://www.geektools.com/rfc/rfc1918.txt) адресите ще бъдат блокирани от навлизане или напускане на външния интерфейс - пакети от/за тези адреси не би трябвало никога да се появяват в Интернет. Филтрирането им ще ни гарантира, че рутерът няма да "изтърве" такива адреси от вътрешната мрежа, а също и няма да пропусне такива пакети отвън, насочени за някои от вътрешните адреси.

block drop in quick on $ext_if from $priv_nets to any block drop out quick on $ext_if from any to $priv_nets

15

block drop се използва за да укаже на PF да не отговаря с TCP RST или ICMP Unreachable пакети. Понеже такива адреси по принцип не съществуват в извън вътрешната мрежа ( в Интернет) няма смисъл да се връща отговор към тях. Параметърът quick се използва да укаже на PF да прекрати обхождането на оставащите правила за филтриране, ако даден пакет отговаря на зададените по-горе правила за RFC 1918 адреси - пакети за/от $priv_nets мрежите се отхвърлят веднага.

Следва да се отворяне на портове за достъпните за използване от Интернет услуги:

pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $tcp_services flags S/SA keep state

Указването на мрежови портове в $tcp_services макроса прави възможно отварянето на допълнителни услуги за използване от Интернет чрез редактиране на макроса и презареждане на набора с правила. По подобен начин предлаганите UDP услуги също могат да се укажат чрез създаване на $udp_services макрос и добавяне на правило, подобно на описаното по-горе, но съдържащо proto udp.

ICMP трафика би трябвало да се пропусне:

pass in inet proto icmp all icmp-type $icmp_types keep state

Подобно на $tcp_services макросът и $icmp_types макросът може да бъде лесно редактиран за да се промени типът на ICMP пакетите, на които е разрешено да достигат системата. Това правило се отнася за всички мрежови интерфейси.

Освен това трябва да се пропуска трафикът от/за вътрешната мрежа. Предполага се, че потребителите от вътрешната мрежа знаят какво правят и няма да са причина за неприятности. Това не винаги е правилно предположение. В такъв случай е необходим по-строг набор от правила.

pass in on $int_if from $int_if:network to any keep state

Правилото по-горе разрешава на всяка вътрешна машина да изпраща пакети през firewall-а, но не разрешава на самия firewall да се свързва към някоя от вътрешните машини. Дали това е добра идея , зависи от конкретната ситуация. Ако firewall-ът е също и DHCP сървър, необходимо е той да "ping"-ва даден адрес за да провери съществуването му, преди да го предостави за използване. Разрешението за firewall-ът да се свързва към вътрешни машини дава възможност на този които се е свързал с ssh към самия firewall да има достъп до тези машини. Не забравяйте, че да не се разрешава на firewall-а да се свързва към вътрешни машини не предоставя много по-голяма сигурност - ако някой е получил достъп до самия firewall, той вероятно може да промени правилата за филтриране. Добавянето на следното правило разрешава на firewall-а да се свързва към машини от вътрешната мрежа:

pass out on $int_if from any to $int_if:network keep state

Ако са зададени и двата реда, описани по-горе, не е необходим параметърът keep state - всички пакети ще преминават на вътрешния интерфейс, защото има редове за пропускането им и в двете посоки. Ако обаче не е включен pass out редът, то

16

pass in редът задължително трябва да включва keep state. Запазването на състоянието подобрява също така и производителността - преди да се приложи дадено правило, първо се проверява таблицата на състоянията и ако се намери запазено състоянието на даден пакет, то той се пропуска през firewall-а, без да е необходимо да се изпълняват правилата за филтриране. Това подобрява производителността на изключително натоварени firewall-и, но разглежданата система е твърде проста за да генерира достатъчно натоварване.

Накрая се пропуска изходящият трафик на външния интерфейс:

pass out on $ext_if proto tcp all modulate state flags S/SA pass out on $ext_if proto { udp, icmp } all keep state

TCP, UDP и ICMP трафикът може да напуска firewall-а. Запазва се информация за състоянието на пакетите за да могат да се пропуснат върнатите в отговор пакети.

Завършеният набор с правила # макроси int_if = "fxp0" ext_if = "ep0" tcp_services = "{ 22, 113 }" icmp_types = "echoreq" priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }" # параметри set block-policy return set loginterface $ext_if # "пречистване" scrub in all # nat/rdr nat on $ext_if from $int_if:network to any -> ($ext_if) rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 \ port 8021 # правила за филтриране block all pass quick on lo0 all block drop in quick on $ext_if from $priv_nets to any block drop out quick on $ext_if from any to $priv_nets pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $tcp_services flags S/SA keep state pass in inet proto icmp all icmp-type $icmp_types keep state pass in on $int_if from $int_if:network to any keep state pass out on $int_if from any to $int_if:network keep state

17

pass out on $ext_if proto tcp all modulate state flags S/SA pass out on $ext_if proto { udp, icmp } all keep state

Описание на някои решения „Защитна стена” от различни производители

Microsoft

Защита с Microsoft Internet Security and Acceleration Server 2000 Microsoft Internet Security and Acceleration Server 2000 e разработен с основна цел да се ускорят интернет комуникациите. Решението осигурява бърз, надежден и сигурен достъп до Интернет. ISA Server предоставя защита чрез ”firewall” на няколко нива, бърз достъп чрез високоефективен Web Cache и вградени системи, които значително опростяват процеса и намаляват разходите по управлението на интернет комуникациите.Включването на мрежи и потребители към Интернет води със себе си редица проблеми, свързани с производителността и корпоративната защита. ISA Server притежава системи, с чиято помощ всяка организация получава инструментариум за контрол върху достъпа и продължителността на ползването на Интернет. ISA Server осигурява защитата на мрежите от неразрешен достъп, ползвайки firewall на различни нива; наблюдава трафика с помощта на интелигентни филтри и предупреждава администраторите за възможни атаки.

ISA Server е разработен с възможност за значително разширение. Разработен е богат набор от допълнителни решения, включително сканиране за вируси, инструменти за управление, филтриране на данни, блокиране на сайтове, контрол в реално време и генериране на отчети. Освен това, системата разполага с пълноценен Software Developement Kit за вътрешен развой, както и опция за администриране с възможности за значителни разширения.

Основните възможности и и технологии за защита които ISA Server Firewall включват:

1. Многослоина защитна стена - осигурява скрининг и филтриране на 3 нива: • Филтриране на пакетите- когато е активирано от външния интерфейс се допускат само

пакети явно разрешени чрез IP филтри, политика за достъп или првила за публикуване • Филтър на ниво контур – инспектира сесии. Една сесия може да включва много връзки.

Сесии се установяватт само по заявка на потребител и се осигурява вградена поддръжка на протоколи със вторични връзки.

• Филтри за приложения – анлизира потока от данни за конкретни приложения и осигурява специфична за него обработака като проверка, скрининг или блокиране. Използва се за блокировка срещу известни дупки в сигурността (exploits).

2. Проверка на състояние. Проверява Source и Destination в IP header-a и порта в TCP или UDP header-a, като идентифицира Интернет услугата или използваното приложение .

3. Интегриран VPN (Virtual Private networking). Пзволява да се изградят VPN връзки. VPN връзката се явява сигурен тунел за данни в Интернет, между отдалечени географски Интранет мрежи.

18

4. Втвърдяване на системата – като се използват предврително дефинирани образци в системата може да се установят следните нива на сигурност :

• Secure – когато на ISA Server компютъра има инсталирани други приложения като date base, IIS, SMTP сървер и др.

• Limited Services –ч подходящ когато ISA Server работи комбинирано защитна стена и cashe сървер..

• Dedicated- когато ISA Server работи само като защитна стена. 5. Откриване на външно проникване . Може да идентифицира общи мрежови атаки като:

• Windows out-of-band (WinNuke) • Land • Ping of Death • IP half scan • UDP bomb • Port scan

6. Филтри за POP и DNS приложения. Те анализират целият входящ трафик за специфични прониквания в сървери за кореспонденция. Администраторът може да конфигуриара филтъра да проверява за следните опити за проникване:

• DNS host name overflow • DNS length overflow • DNS zone transfer from privileged ports (1-1024) • DNS zone transfer from high ports (above 1024) • POP buffer overflow

7. Умни филтри за приложения. Такъв филтър може да анализира, блокира, пренасочва или да модифицира потока от данни знаейки спецификата на протокаола на приложението и структурата данни. Вградени са следните филтри:

• HTTP • FTP • SMTP • SOCKS • RPC (Remote Procedure call) • H.323 – насочва H.323 пакетите използвани за мултимедийни комуникации

телеконференция. • Откриване на POP и DNS проникване

19

8. Силна аутентикация. ISA сървер може да се конфигурира да изисква от клиентите следните методи за аутентикация:

• Basic (plain text) authentication • Digest authentication (in Windows 2000 Domain) • Integrated Windows authentication (NTLM and Kerberos) • Client certificates (for incoming requests) and server certificates (for published

servers) ISA Server поддържа NTLM pass-through authentication – способността да предаде аутентикацията на клиента до дестинейшън сървера за входящите и изходящи Web

Cisco Описание на PIX506E: Хардуерен Firewall,

• Захранване 220 волта • Поне два 10/100 Ethernet порта • Network Address Translation – поддръжка на протоколи FTP, HTTP, H.323, SIP, RTSP, ICMP • Производилтеност – минимум 100Мбит/с пакетна комутация, минимум 20000

едновременно отворени сесии за Network Address Translation • Вграден VPN сървър. Поддръжка на протоколи PP2P, L2TP и IPSEC за VPN (за да могат да

се използват вградените във Windows VPN Клиенти). Минимум 20 едновременни VPN сесии. Възможност потребителите да се оторизират през RADIUS сървър

• Поддръжка на IPSec. Протоколи за оторизация SHA1-HMAC, MD5-HMAC. Протоколи за криптация: 3DES и AES256

• Производителност за криптиране с AES256 и 3DES – минимум 10Мбит/с • Пакетна филтрация • Конзолен порт за конфигурация • Графично конфигуриране през мрежата, без изискване за спецялно инсталиран клиент за

това • Поддръжка на SNMPv1 • Поддръжка на Syslog за отбелязване на всички събития • Вградена поне минимална IDS функционалност, с възможност да се отбелязват и да се

предприемат автоматизирани действия към нежеланият трафик • Възможност за блокиране на Java и ActiveX компоненти от WWW трафика • Поддръжка на оторизация на отворените сесии към Интернет през външен софтуер и

RADIUS протокол • Поддръжка на филтриране на достъп до определени WWW сайтове чрез външна база данни

или софтуер (например Websense)

20

3Com 3Com-Internet Firewall I. ОСНОВНИ ФУНКЦИИ НА INTERNET FIREWALL(3Com-Internet Firewall)

1. Функции по Сигурността Tази защитна стена е предварително конфигурирана да осъществява мониторинг на Интернет трафик, да открива и предотвратява автоматично следните DoS атаки: • Ping of death • SYN Flood • LAND Attack • IP Spoofing • Teardrop -( DoS Хакерски инструмент широкодостъпен по Интернет) 3Com-Internet Firewall извършва пълна инспекция на пакета за да определи дали пакета с данни от Интернет е разрешен за частната Локална Мрежа. (ЛМ). Напредналите потребители могат да разширят функциите по сигурността на 3Com-Internet Firewall с добавяне на правила за мрежови достъп (ПМД) и Потребителски Привелегии.

2. Филтриране 3Com-Internet Firewall може да се използва за мониторинг и ограничаване на потребителите на ЛМ да имат достъп до неподходяща информация по Интернет. Може да се блокира достъпът до такава информация или да се записват опитите за достъп в дневник.

Може да се зададе списък на забранените URL както и да се ограничи достъпа само до определени Доверени (trusted) URL.

Web site технологиите като cookies , JAVA, ActiveX applets разширяват възможностите на web страниците, но хакери могат да използват технологиите да откраднат или повредят информация. 3Com-Internet Firewall може да блокира определени потенциално опасни приложения да бъдат сваляни от Интернет или да разрешава това само от Доверени сайтове.

Web site fилтрите дават възможност да предоставят на 3Com-Internet Firewall списък от категории сайтове които могат да се считат за неподходящи за Бизнес дейността. Te снабдяват защитнат стена с актуализиран списък на URL адреси които отговарят на зададените категории. Има възможност да се блокира достъпа до тях или да се записват в дневник. За Web филтрите има и абонамент.

3. Дневници и Предупреждения Защитната стена поддържа дневник на всички събития които могат да бъдат смятани за заплаха за сигурността. Тя също може да записва ключови събития като например определен брой най- посещавани сайтове. Също защитната стена може да се настрои да изпраща предупредително съобщение чрез e-mai когато е открита опасност с висок приоритет като например хакерска атака.

4. Отдалечен Достъп (по Интернет) Потребител може да има достъп до Интранет ресурси в частна (LAN) мрежа, ако успешно се влезе (logging) в 3Com-Internet Firewall от Интернет. Това изисква валидна парола и потребителско име.които се предават на 3Com-Internet Firewall от отдалечения потребител в криптиран вид (напр. MD5 kриптиращ механизъм) с използване на Web Browser. Веднъж влязъл отдалечения потребител може да достъпва всички IP ресурси в частната мрежа, използвайки DHCP услугата на защитната стена.

5. Автоматично поделяне на IP адреси и Конфигурация

3Com-Internet Firewall предоставя поделяне на публичен IP адрес чрeз NAT (Network Address Translation). както и опростено администриране на IP адрес използвайки DHCP (Dynamic Host Configuration Protocol)

21

NAT автоматично транслира IP адреси на малка ЛМ към един публичен IP адрес който се изпраща навън към Интернет. Той също позволява защитната стена да се използва с broadband модеми и евтини Интернет акаунти когато Интернет доставчика е предоставил само един адрес.

DHCP сървера присвоява на всички PC-та в часната мрежа правилната IP информацият т.е. явява се и средство комютрите в мрежата да получват своите IP настройки от един централизиран сървер. DHCP предлага пълен централизиран менъджмент на IP конфигурацията на клиента като IP адреси, gateway адрес, DNS адрес и др.

II. Свързване

3Com-Internet Firewall притежава няколко типа Ethernet портове които се използват за разделяне на мрежата на отделни области: • (Wide Area Network)-Големи Мрежи (ГМ) порт към който се свързва устройството за връзка с

Интернет - LAN модем, кабелен модем,, рутер. • LAN (ЛМ) порт към който се свързва ЛМ чрез hub и switch. • Специлаизирани портове като напр. DMZ(Demilitarized zone) на 3 COМ Office connect Firewall,

се използва от публичните Интернет сървери напр. Web, FTP, E-Mail и др.Машините вързани към този порт са видими от към WAN порта, но са защитени от хакерски атаки.Потребитилите от към LAN порта също може да имат достъп до този порт.

Така мрежата се конфигурира на 3 области : WAN, LAN и DMZ като се обезпечава следната политика на сигурност: • Интернет сърверите имат достъп до DMZ областта • LAN машините имат достъп DMZ областта • LAN машините имат достъп до Интернет • Неоторизирани потребители нямат достъп до LAN от Интернет • Хакери/DoS атаки в LAN и WAN областите се блокират • Оторизирани потребители за Отдалечен Достъп се допускат до LAN областта III. Настройки и администриране

Фирмите предоставят програма за настройка и поддръжка както и възможност за използване на Web Browser за достъп до интерфейса на 3Com-Internet Firewall за настройка и администриране.

1. Началната настройка включва задачи като: • IP адрес на защитната стен в мрежата от диапазона адреси на LAN и маската на подмрежата • IP адреса на устройството за достъп до Интернет • Адреси на DNS, SMTP сървери и др. • Настройка за менъджмент станция -може да бъде всеки компютър от ЛМ • Настройки за паролата • Конфигуриране на мрежовата информация (LAN & WAN) като режим на адресиране-

стандартен (всяка машиан от ЛМ има отделен Интернет IP адрес), NAT (общ Интернет IP адрес), NAT с DHCP

2. Текущото администриране дава възможност за: • Определане на тек. статус на 3Com-Internet Firewall • Смяна на паролата • Настройка на мрежата- адреси на LAN, WAN, DMZ, DNS – сървери

3. Режима на адресиране

4. Настройка на DHCP сървера текущ статус 5. Ping и Packet trace функции за диагностика

22

Атаки върху защитните стени

Тъи като системите ”защитна стена” са просто един набор от правила и политики, то атаките върху тях се изразяват предимно в откриването и заобикалянето им. Което от своя страна води до създаването на реални предпоставки за истинска атака към състемата или мрежата зад защитната стена.

Директно скениране Най-лесният начин за откриване на защитна стена е да се направи сканиране на специфични портове по подразбиране. Някои от продаваните защитни стени ще се идентифицират уникално при обикновено сканиране на портове. Например, Firewall 1 на Checkpoint прослушва TCP портове 256,257, 258, а Proxy Server на Microsoft: обикновено прослушва ТСР портове 1080 и 1745. Търсенето на такъв тип защитни стени става със средство за сканиране на портове като nmap, например:

nmap -p -vv -p0 -p256, 1080, 1745 192.168.50.1-60.254

Използването на ключа –p0 забранява възможността за ICMP ping преди сканиране. Това е важно, тъй като повечето защитни стени не отговарят на ICMP ЕСНО заявки. Повечето IDS системи имат подразбираща се конфигурация, с която могат да открият само най-шумните и най-глупаво реализирани сканирания на портове. Освен ако изрично не се направи IDS система особено чувствителна , повечето атаки от този тип ще преминат съвсем незабелязано.

Предпазните мерки срещу директно сканирането на защитна стена

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

Проследяване на маршрута

Едни по-безшумен и неуловим начин за откриване на защитни стени в мрежа е да се използва traceroute . Използвайки traceroute на UNIX или tracert.exe на Windows NT, можете да се открие всяко стъпало по пътя до целта и да се направят съответните изводи за защитната стена. Във версията на traceroute на UNIX има опция -i , която извършва проследяването на маршрута чрез изпращане на ICMP пакети, а не с подразбиращата се техника с UDP пакети.Например:

[sm]$ tracaroute -i 192.168.51.100

traceroute to 192.168.51.101 (192.168.51.100), 30 hops max, 40 byte packets

1 attack-gw (192.168.50.21) 5.801 ms 5.105 ms 5.445 ms

2 gwl.smallisp.net (192.169.51.1)

3 gw2.smallisp.net (192.168.52.2)

...

13 hssi.bigisp.net (10.55.201.2)

14 seriall.bigisp.net (10.55.202.1)

23

15 192.168.51.101 (192.168.51.100)

Съществува голяма вероятност стъпалото точно прели целта (10.55.202.1) да е защитна стена, но все още не може да се твърди със сигурност. Ще трябва да продължим с изследването.Този пример е много добър, ако маршрутизаторите, разположени между нас и целевите сървъри, реагират на пакети с изтичащ срок. Но някои маршрутизатори и защитни стени са настроени така, че да не връщат обратно ICMP пакети с изтекъл TTL (и при ICMP, и при UDP пакети). Тогава изводите, които ще сe направят, ще са по скоро догатка. Всичко, което можете да се направи, е да стартирате traceroute, да се види от кое стъпало ще дойде последният отговор и да се прецени, дали това е или истинска защитна стена, или поне първият маршрутнзатор по пътя, с които започва блокирането на пакети с изтекъл TTL. Например, в този случай ICMP пакета е блокиран по пътя към местоназначението си и няма никакъв отговор от маршрутизаторите след client-gw.smallisp.net :

1 stoneface (192.168.10.33) 12.640 ms 8.367 ms 2 gwl.localisp.net (172.31.10.1) 214.582 ms 197.992 ms 3 gw2.localisp.net (172.31.10.2) 206.627 ms 38.931 ms 4 dsl.localisp.net (172.31.12.254) 47.167 ms 52.640 ms 14 ATM6.LAX2.BIGISP.NET (10.50.2.1) 250.030 ms 391.716 ms 15 ATM7.SDG.BIGISP.NET (10.50.2.5) 234.668 ms 384.525 ms 16 client-gw.smallisp.net (10.50.3.250) 244.065 ms !X * * 17 * * * 18 * * *

Предпазна мярка срещу проследяване на маршрута

Решението на проблема с изтичането на информация при използване на traceroute с да се ограничи отговора от колкото е възможно повече защитни стени и маршрутизатори при подаване на пакети с изтекъл TTL. За разкриване стандартното използване на traceroute спрямо граничните устройства, ще трябва да се следи за ICMP н UDP пакети с TTL стойност 1. Това може да стане, например , с помощта на продукта RealSecure като се в SecurityEvent на Network Engine Policy се маркира TRACE_ROUTE decode name.

За да предотвратяване на възможността на гранични устройства да бъде стартирано средство за проследяване на маршрути, можете да се конфигурират маршрутизаторите така, че при получаване на пакети с TTL стойност 0 или 1 да не реагират сьс съобщения или най-добре би било изобщо да се блокира целия ненужен UDP трафик кьм граничните маршрутизатори.

Прихващане на банери Сканирането за портове на защитни стени може да помогне за откриването им, но повечето от тях не следят подразбиращите се портове като Checkpoint и Microsoft, така че откриването им ще трябва да бъде направено на основата па изводи. Много от широко използваните защитни стени ще съобщят за присъствието си, когато просто се свържем към тях. Например, много прокси-сървъри ще съобщят, че изпълняват функции на защитна стена, а някои ще обявят типа и версията си. Например, когато чрез netcat на порт 21 (FTP) се свържете към някоя машина, за която смятате, че изпълнява функциите на защитна стена, ще се види следната информация: C:\>nc -v -n 192.168.51.129 21 (UNKNOWN) [192.168.51.129] 21 (?) open 220 Secure Gateway FTP server ready.

Банерът "Secure Gateway FTP server ready" е знак, че Eagle Raptor работи на този host. Ако след това се свържем към порт 23 (Telnet) , предположението ни, че марката на тази защитна стена е Eagle Raptor ще се потвърди:

C:\>nc -v -n 192.168.51.129 23 (UNKNOWN) [192.168.51.129] 23 (?) open

Eagle Secure Gateway.

Hostname:

24

И накрая, за да се определи със сигурност, че тази отдалечена машина е защитна стена, можете да се използва netcad на порт 25 (SМТР) н отговорът, който ще сеполучи е:

C:\>nc -v -n 192.168.51.129 25 (UNKNOWN) [192.168.51.129] 25 (?) open 421 3.acme.com Sorry, the firewall does not provide mail service to you.

Което само говори по себе си.Както се вижда в показаните примери, информацията, съдържаща се в бaнеритe, може да се окаже много ценна за разпознаването на защитна стена

Предпазна мярка срещу прехващане на банери

Решението на проблема с този вид изтичане на информация е да се ограничи предоставяната в банерите информация. Добре направеният банер би могъл да извежда предупреждение да не продължавате и че всеки опит за връзка ще бъде регистриран. Начинът на промяна на подразбиращите се банери е специфичен за всяка отделна защитна стена, така че за информация ще трябва да се потърси нейния производител.

За предотвратяване възможността атакуващ да получи твърде много информация за защитната стена, чрез банерите, в много случаи ще помогне промяната на конфигурационните файлове на банерите. Специфичните препоръки зависят от създателя на защитната стена. При Eagle Raptor можете да се промени FTP и telnet банерите като се модифицират файловете със съобщенията за деня: ftp.motd и telnet.modt.

Обикновенна дедукция с nmap Nmap е чудесен инструмент за откриване на информация за защитни стени. Когато nmap сканира някоя отдалечена машина, той не съобщава просто кой порт е отворен и кой затворен, а и кои портове са блокирани. Количеството информация (или липсата на информация), получена от сканирането на даден порт може да покаже много за конфигурацията на защитната стена. Ако някой порт е филтриран в nmap, това може да означава три неща:

• Не е получен SYN / АСК пакет. • Не е получен RST / АСК пакет. • Получено с ICMP съобщение от тип 3 ( "Destination unreachable" - не може да се достигне до

местоназначението) с код 13("Communication Administratively Prohibited" — Комуникацията е административно забранена) — [RFC1812].

nmap свързва тези три условия и съобщава за "филтриран" порт. Например, ако сканираме www.mycompany.com, ще се получат два ICMP пакета, показващи, че съответната защитна стена блокира портове 23 и 111 на системата. [root]* nmap -p20,21,23,53,80,111 -PO -w 192.168.51.100

Starting nmap V. 2.08 by Fyodor ([email protected],

www.insecure.org/nmap/)

Initiating TCP connect!) scan against (192.168.51.100)

Adding TCP port 53 (state Open).

Adding TCP port 111 (state Firewalled).

Adding TCP port 80 (state Open).

Adding TCP port 23 (state Firewalled).

Interesting ports on (192.168.51.100):

Port State Protocol Service

23 filtered tcp telnet

53 open tcp domain

80 open tcp http

111 filtered tcp sunrpc

Състоянието „Firewalled”в предишния подробен резултат следва от получаването на ICMP тип 3 съобщение с код 13 (Admin Prohibitted Filter), както се вижда от tcpdump резултата:

25

23:14:01.229743 10.55.2.1 > 172.29.11.207: icmp: host 172.32.12.4 Unreachabls - admin prohibited filter

23:14:01.979743 10.55.2.1 > 172.29.11.207: icmp: host 172.32.12.4 Unreachable – admin

ICMP пакетът, изпратен обратно към машината, която извършва сканирането, съдържа всички данни, които са необходими, за извличането на необходимата информация. Блокираният порт е записан в еднобайтовата част от заглавната част на ICMP - байт 0x41 (един байт), а филтриращата защитна стена, която изпраща съобщенията, е записана в IP частта на пакета - байт 0x1b (четири байта).

И накрая, "нефилтрираните" от nmap портове се появяват само, когато се сканират много портове и се получи обратно SYN / АСК пакет. "Нефилтрирано" състояние означава, или че сканирането преминава през защитната стена и целевата системата показва, че тя не следи този порт, или че тази защитна стена отговаря вместо системата и изпраща своя IР адрес с установен SYN/АСК флаг. Например, ако се сканира локалната система и се получат два SYN/АСК пакета от една и съща машина, значи има два нефплтрпрани порта. Това може да се случи и при някои защитни стени като Checkpoint ( с правило REJECT), когато защитната стена реагира вместо системата като изпраща обратно SYN/АСК пакет и подменя IP адреса на системата.

(root)* nmap -sS -pl-300 172.18.20.55

Starting nmap V. 2.08 by Fyodor ([email protected], www.insecure.org/nmap/) Interesting ports on (172.18.20.55): (Not showing ports in state: filtered)

Port State Protocol Service

7 unfiltered tcp echo

53 unfiltered tcp domain

256 open tcp rap

257 open tcp set

258 open tcp yak-chat

Nmap run completed — 1 IP address (1 host up) scanned in 15 seconds

Ако се направи проследяване на пакети с tcpdump, ще се видят получените RST/ACK пакети.

21:26:22.742482 172.18.20.55.258 > 172.29.11.207.39667: S

415920470:1415920470(0) ack 3963453111 win 9112 <mss 536> (DF)

(ttl 254, id 50438)

21:26:23.282482 172.18.20.55.53 > 172.29.11.207.39667:

R 0:0(0) ack 3963453111 win 0 (DF) (ttl 44, id 50439)

21:26:24.362482 172.18.20.55.257 > 172.29.11.207.39667: S

1416174328:1416174328(0) ack 3963453111 win 9112 <mss 536>

(DF) (ttl 254, id 50440)

21:26:26.282482 172.18.20.55.7 > 172.29.11.207.39667:

R 0:0(0) ack 3963453111 win 0 (DF) (ttl 44, id 50441)

Предпазна мярка срещу използване на проста дедукция с nmap

За да се предотврати възможността атакуващ да открива списъците с права за достъп на вашите маршрутизатори и защитни стени чрез техниката "admin prohibited filter", можете да се забрани възможността на маршрутизаторнте да отговарят с ICMP тип 13 пакети. При Cisco това може да се направи като се блокира устройството, така че да не отговаря при съобщения за невъзможно достигане на IP адрес ("IP unreachable"): no ip unreachable

Предаване на небработени пакети

Продуктът hping създаден от Salvatore Sanfilippo работи като изпраща ТСР пакети до определен порт н

26

съобщава за пакетите, които получава обратно. hping може да върне различни отговори в зависимост от различните условия. Всеки пакет частично или цялостно може да предостави доста ясна картина за правилата за управление на достъпа до съответната защитна стена. Например, катосе използв hping , може да се открият отворените, блокираните, пропуснатите и отхвърлените пакети.

В следващия пример hping съобщава, че порт 80 с отворен и готов да приеме връзката, тъй като този порт с получил пакет, в който SA флагът е бил установен (SYN/АСК пакет).

(root)* hping 192.168.51.101 -c2 -S -p80 -n

HPING www.yourcomapany.com (ethO 172.30.1.20): S set, 40 data bytes 60 bytes from 172.30.1.20: flags=SA seq=0 ttl=242 id=65121 win=64240 time=144.4 ms

В следващия пример hping съобщава, че е получил от 192.168.70.2 съобщение "ICMP unreachable type 13". ICMP type 13 е всъщност ICMP "admin prohibited filter" пакет, който обикновено се изпраща от филтриращ пакетите маршрутпзатор като IOS на Cisco.

[root]* hping 192.168.51.101 -c2 -S -p23 -n

HPING 192.168.51.101 (ethO 172.30.1.20): S set, 40 data bytes

ICMP Unreachable type 13 from 192.168.70.2

Това потвърждава, че 192.168.70.2 най-всроятно е защитна стена и че тя блокира порт 23 на системата. С дути думи, ако системата е Cisko маршапутизатор и неговия конфигурационен файл има следния ред :

access-list 101 deny tcp any any 23 ! telnet

В следващия пример се получава обратно SYN/АСК пакет, което означава едно от следните две неща: (1) че пакетът е преминал през защитната стена и машината не следи този порт или (2) че тази защитна стена е отх-върлила пакета (какъвто е случаят с правилото за отхвърляне в Checkpoint).

[root] ft hping 192.168.50.3 -c2 -S -p22 -n


60 bytes from 192.168.50.3: flags=RA seq=0 ttl=59 id=0 win=0 time=0.3

Ms

Тъй като по-рано е получен ICMP тип 13 пакет, можем да се предположи, че тази защитна стена (192.168.70.2) е позволила на този пакет да премине, но машината просто не следи този порт.

Ако се сканира през Checkpoint защитна стена, hping ще съобщи IP адреса на източника, но всъщност пакетът се изпраща от външния NIC на CheckPoint. Хитростта при CheckPoint е, че тя ще отговори от името на вътрешните си системи, изпращайки отговор и имитирайки адреса на системата, която предпазва. Когато атакуващия попадне на някое от тези условия , той няма да може да го разпознае тъй като МАС адресът никога няма да достигне до неговата машина. И накрая, когато една защитна стена напълно блокира пакетите към определен порт, най-често няма да се получи обратно никаква информация.

[rootH hping 192.168.50.3 -c2 -S -p22 -n


Този резултат от изпълнението на hping може да означава две неща: (1) пакетът не е достигнал до местоназначението си и се е загубил по пътя или (2), което е по-вероятно, някое устройство ( защитната стена) с отхвърлило пакета в съответствие с ACL правилата си.

Предпазна мярка при предаване на необработени пакети

Трудно е да се предпазите от атака с hping. Най-добре е просто да се блокират всички ICMP тип 13 съобщения.

27

Firewalk

Firewalk е средство, което, подобно на средство за сканиране на портове, открива отворени портове зад защитна стена. Този продукт, създаден от Mike Scheiffman и Dave GoldSmith сканира информацията за машината, преминала през защитната стена и съобщава правилата, разрешени за нея, без в действителност да се е докоснал до целевата система.

Firewalk работи като създава пакети с така изчислени IP TTL , че разрешението за използването им изтича при първото стъпало след преминаване на защитната стена. Идеята с, че ако преминаването на пакета се разреши от защитната стена, тои ще бъде пропуснат и след това, както се очаква, ще изтече, извеждайки съобщението "IСМР TTL expired in transit ". От друга страна, ако пакетът е блокиран от списъка с права за достъп на защитната стена,

той ще бъде отхвърлен и няма да се получи никакъв отговор или ще се изпрати ICMP тип 13 "admin prohibited filter" пакет. [root]* firewalk -pTCP -S135-140 10.22.3.1

192.168.1.1

Ramping up hopcounts to binding host...

Probe: 1 TTL: port 33434 expired from [exposed.acme.com]

Probe: 2 TTL: port 33434 expired from [rtr.isp.net)

probe: 3 TTL: port 33434 Bound scan at 3 hops [rtr.isp.net]

port 135: open

port 136: open

port 137: open

port 138: open

port 139. *

port 140: open

Единственият проблем, с който се сблъскваме при използването на Firewalk е, че резултатите му понякога са непредвидими, тъй като някои защитни стени ще открият, че времето на пакета е изтекло преди да проверят своите ACL и ще изпратят съобщение ICMP TTL EXPIRED. В резултат на това Firewalk често приема, че всички портове са отворени.

Предпазна мярка срещу Firewalk

Можете да се блокират ICMP TTL EXPIRED пакети на ниво външен интерфейс, но това може да има отрицателни последици върху работата му, тъй като клиентите, които съвсем законно се свързват към него, няма да могат да разберат какво се е случило с връзката им.

Сканиране на изходните портове

Традиционните защитни стени, работещи чрез филтриране на пакети, като IOS на Cisco, имат един основен недостатък: не запазват състоянието. Ако една защитна стена не може да поддържа състояние, то тя не може да каже дали свързването е започнало отвън или отвътре. С други думи, тя не може да управлява изцяло някои предавания. В резултат от това може да се настрои изходния порт така, че да позволява портове като ТСР 3 (прехвърляне на зони) и ТСР 20 (FTP — данни) и да се осъществи сканиране (или атака) чак до сърцевината. За да се открие дали дадена защитна стена позволява сканирания през нея през изходния порт 20 (например, FTP канала за данни), може да се използва опцията -g на nmap:

28

Nmap –sS –p0 –g 20 –p 139 10.1.1.1

Ако информацията, върната от порта, показва че той е отворен, това означава че вероятно по средата има уязвима защитна стена.

След като се открие, че дадена защитна стена не поддържа състоянието на своите връзки, атакуващия ще може да се възползва от този факт и да започнете да атакувате уязвимите системи зад тази защитна стена. Като използвате средство за пренасочване на портовете, като продукта Рр1ре на РоигкЬюпе, можете да дефинирате изходния порт като 20 и после да стартирате атака след атака през тази защитна стена. Предпазна мярка срещу сканиране на изходни портове

Решенията на проблема с този вид уязвимост са прости, но не всички са много ефективни. Ще трябва или да се забрани всяка комуникация, изискваща използването на повече от една комбинация от портове (каквато е традиционното FTP), или да се премине към използване на поддържаща състоянието или приложна прокси защитна стена, която по-добре контролира връзките, влизащи и излизащи от системата. Не можете напълно да се контролира как начина, по който защитна стена, работеща чрез филтриране на пакетите, поддържа състоянието.

Либерални списъци за контрол на достъпа

Работата на защитните стени, конто филтрират пакети (включително и тези, конто поддържат състояние), като Firewall -1 на Checkpoint, PIX и IOS на Cisko, зависи от (ACL- Access Control Lists)списъците за управление на достъпа или от правила, които определят дали на трафика е позволено да премине към или от вътрешната мрежа. В повечето случаи тези ACL списъци са добре замислени и трудни за заобикаляне. Но често ще срещнете и защитни стени с доста либерални ACL, които позволяват на някои пакети да преминават безпре-пятствено Либералните списъци за контрол на достъпа се срещат при толкова много защитни стени, че е трудно да се изброят. Ще разгледаме случая, в който една организация иска да позволи на своя Интернет доставчик да извършва прехвърляния на зони. В такъв случай може да се приложи по-лнбералсн ACL, като "Разрешават се всякакви действия от изходен ТСР порт 53", вместо ACL 'Тазрешават се действия от DNS системата на Иптернет доставчика с изходен ТСР порт 53 и приемащ порт 53". Рисковете, които крие това неправилно конфигуриране, могат да се окажат наистина опустошителни, тъй като това позволява да се сканира цялата корпторативна мрежа отвътре. Повечето такива атаки започват като атакуващия сканира машина зад защитна стена и имитира нейния изход като ТСР порт 53 (DNS).

Предпазна мярка срещу използване на либерални ACL

Най-добре е да се направи така , че правилата на защитна стена да ограничават кой къде може да се свързва. Например, ако Интернет доставчикът изисква да му се предостави възможност за прехвърляне на зони, това изрично трябва да се упомене в правилата на защитната стена. Трябва да се изискат IP адреса на източника, и твърдо да се кодира в правилата IP адреса на местоназначението (вътрешния DNS сървър). Ако се работи с Checkpoint защитна стена, ето правилото, което може да се използва, за да се ограничи изходения порт 53 (DNS) само до DNS-а на Интернeт доставчикa. Например, ако неговата DNS система е 192.168.66.2 , а вътрешна DNS система е 172.30.140.1, може да се използва следното правило:

Source Destination Service Action Track

191.168.66.2 172.30.140.1 doamin-tcp Accept Short

ICMP и UDP тунелиране

ICMP тунелиране (ICMP tunneling) е възможността истински данни да бъдат обвити в ICMP заглавие. Много маршрутизатори и защитни стени, които сляпо пропускат ICMP ЕСНО, ICMP ЕСНО REPLAY и UDP пакети, ще бъдат уязвими към такава атака. Подобно на DNS уязвимостта на CheckPoint, атаката чрез ICMP и UDP тунелиране се разчита, че има система зад защитната стена, в която атакуващия вече е проникнал. Концепцията за тунелиране с приложена от Jeremy Rauch и Mike Schiffman. Те са създали два продукта, които

29

използват този подход: loki и lokid (за клиентската част и за сьрвъра); пълна информация за тях можете да се намерите на адрес: http://phrack.infonexus.com/search.phtlm?view&article=p49-6. Стартирането на lokid на система, разположена зад защитна стена, пропускаща ICMP ЕСНО и ЕСНО REPLY, позволява на атакуващия да стартира клиентското средство (loki), което пакетира всяка команда, изпратена в IСМР ЕСНО пакети към сървъра (lokid). След това средството lokid ще разопакова командите, ще ги стартира локално и ще пакетира резултатите от изпълнението им в ICMP ЕСНО REPLY пакети обратно към атакуващия. Чрез използването на тази техника атакуващите могат изцяло да заобиколят вашата защитна стена.

Предпазна мярка срещу ICMP и UDP тунелиране

Може да се предотврати този вид атака като изцяло се забрани ICMP достъпа през защитна стена или като се предостави гранулярен контрол на достъпа за ICMP трафика. Ето един пример за ACL за Cisco устройства, чрез който може да се забрани целият ICMP трафик, освен трафика от 172.29.10.0 за администраторски цели:

access-list 101 permit icmp any 172.29.10.0 0.255.255.255 8 I echo

access-list 101 permit icmp any 172.29.10.0 0.255.255.255 0 f echo-reply

access-list 102 deny ip any any log t deny and log all else

Заключение: В истинския живот една добре конфигурирана защитна стена може да се окаже изключително трудна за преодоляване. Като използват различни продукти, чрез които събират информация за системата, например traceroute, hping и nmap, атакуващите могат да открият (или поне да предположат) пътища за достъп през маршрутнзатори и защитни стени и какъв вид защитна стена стои пред тях. Много от сега съществуващите уязвимост се дължат на неправилни конфигурации в използваната защитна стена или на това, че администраторът не следи работата на системата, но и в двата случая, ако някои се възползва от това, атаката може да има катастрофални последици. И трите вида защитни стени — и прокси-сървърите, и защитните стени, филтриращи пакети (запазващи състоянието и тези които не го пазят ) - си имат някои специфични слабости и. В повечето случаи могат да се приложат различни предпазни мерки, за да се предотврати използването на тези слабости, но в някои случаи е възможно само тяхното откриване. Много хора вярват, че неизбежно бъдещето на защитните стени е в комбинацията от свойствата на приложен прокси-сървър и поддържаща състоянието технология с филтриране на пакети, като по този начин ще се ограничат възможноспгге за неправилни конфигурации.

Допълнителна информация за някои комерсиални защитни стени

BorderManeger Производител: Novell Inc Подържани платформи: Novell Net Ware, UNIX, Windows NT Допълнителна информация:http:// www.novell.com/products/bordermamager/index.html

FireBox Производител: Watchguard Подържани платформи: UNIX Допълнителна информация: http:// www.watchguard.com

30

Firewall-1 Производител: Check Point Software Technologies Ltd. Подържани платформи:Windows NT /UNIX Допълнителна информация: http:// wwwcheckpoint.com/

Firewall Server Производител: BorderWare Подържани платформи: Частни операционни системи, работещи върху Intel архитектури Допълнителна информация: http:// www.borderware.com

Gauntlet Intrenet Firewall Производител: Network Associates Подържани платформи: UNIX, Windows NT, DMS, ITSEC E3, IRIX Допълнителна информация: http:// www.nai.com/asp_set/products/introduction/default.asp

GNAT Box Firewall Производител: Global Technology Associates Подържани платформи: Hardware firewall Допълнителна информация: http:// www.gnatbox.com

Guardian Производител: NetGuard Inc. Подържани платформи: Windows NT Допълнителна информация: http:// www.netguard.com

NetScreen Производител: NetScreen Technologies Inc. Подържани платформи: Hardware firewall Допълнителна информация: http:// www.netscreen.com

PIX Firewall Производител: Cisco Systems Inc. Подържани платформи: Hardware firewall Допълнителна информация: http:// www.cisco.com/warp/public/751/pix/

31

Raptor Firewall Производител: Axent Подържани платформи: Solaris, Windows NT Допълнителна информация: http:// www.raptor.com/products/datasheets/

SideWinder Производител: Secure Computing Подържани платформи: UNIX (частна версия, разпространява све с продуката) Допълнителна информация: http:// www.secure computig.com

Sonicwall Производител: SonicSystems Подържани платформи: Hardware firewall Допълнителна информация: http:// www.sonicwall.com

WinGate Производител: Qbik Inc. Подържани платформи: Windows NT Допълнителна информация: http:// www.wingate.deerfield.com

Sygate Personal Firewall Производител: Sygate Technologies Inc. Подържани платформи: Windows NT Допълнителна информация: http:// www.sygate.com

Обобщение Защитните стени не са непробиваеми. При всяка една от горе изброените съществват пропуски в ведна илидруга степен, ето защо не бива да се оставя цялата грижа за сигурността върху защитната стена. Но в много случаи тя е крайно необходима и доказано може да бъде много полезна Както при всеки защитен продукт, тестването преди покупката е ключово. Ползата от защитната стена зависи от правилното конфигуриране и мониторинг извършвани върху нея.

32

Любопитни факти

15-ти януари 2004 година е официално обявен за Ден на Личният Файъруол или Personal Firewall Day. Създаден е уебсайт за това начинание, коeто има образователна цел и ще запознава новите потребители на Интернет как да защитават персоналните си компютри и информацията в тях от нежелан достъп. Тази кампания се спонсорира от McAfee, Microsoft, Sygate, TruSecure и Zone Labs. Може да посетите официалната страница: http://www.personalfirewallday.org/ или да прочетете съобщението за пресата: http://www.personalfirewallday.org/PFDPressRelease.pdf

• • •

Приложенията на Check Point са на първо мяс-то в класацията за 2003 г. на консултантската фирма META-spectrum за Firewall и VPN програми. Cisco и NetScreen са на второ и трето място сред компаниите с най-голям пазарен дял. Анализаторите очакват предприятията да увеличават разходите за защитни приложения и пазарът да нараства с 25 % годишно през следващите две или три години. От пет години пазарът е ясно очертан и вече е преминал фазата на консолидация на играчите, се казва в анализа на META-spectrum. Въпреки това потенциалът на технологията прави лидерските позиции достатъчно динамични. Анализаторите определят шест компании със сериозни шансове да завоюват най-големи дялове на пазара. Равностойна по технически параметри на лидерите, Secure Computing е на първо място сред претендентите. Все още обаче отстъпва по пазарен дял на Check Point, Cisco и NetScreen. Във втората група влиза CyberGuard, която е с по-слабо позната марка и по-ограничено пазарно присъствие. Sy- mantec и SonicWall, които анализаторите също класират в тази група, отстъпват по решения за вътрешните мрежи на организациите. Въпреки това всяка една от трите компании разполага с доминиращи позиции в някой сегмент на пазара. CyberGuard се използва във военните производства и правителствени организации, където се изисква високо ниво на сигурност. Продуктите й са познати с високата надеждност на Firewall и VPN програми, предлагащи вътрешно многостепенно ниво на сигурност, което отделя всеки слой на защитната операционна система и разделя мрежовия трафик от компонентите на системата. Symantec се използва в магазини, закупили други приложения на компанията. SonicWall е лидер в нишата на малките и средните предприятия. Към третата група претенденти спада Microsoft. Най-популярните продукти на пазара са приложения за демилитаризирани зони, защитни програ- ми, използвани като интерфейс към Интернет за малки и регионални офиси, и Firewall програми - във вътрешните мрежи на организациите.

33

КНИГИ И ПУБЛИКАЦИИ Internet Firewalls u Network Security (второ издание). Chris Hare u Karanjit Siyan. New Riders. ISBN: 1-56205-632-8. 1996. Internet Firewalls. Scott Fuller и Kevin Pagan. Ventana Communications Group Inc. ISBN: 1-56604-506-1. 1997. Building Internet Firewalls. D. Brent Chapman и Elizabeth D. Zwicky. O'Reilly & Associates. ISBN: 1-56592-124-0. 1995. Firewalls and Internet Security: Repelling the Wily Hacker. William R. Cheswick и Steven M. Bellovin. Addison-Wesley Professional ComputingISBN: 0-201-63357-4. 1994. Actually Useful Internet Security Techniques. Larry J. Hughes, Jr. New Riders. ISBN 1-56205-508-9. 1995. Internet Security Resource Library: Internet Firewalls and Network Security. Internet Security Techniques, Implementing Internet Security. New Riders. ISBN: 1-56205-506-2. 1995.

Network Firewalls. Steven M. Bellovin и William R. Cheswick. IEEECM, 32(9), стр. 50-57, септември 1994. Session-Layer Encryption. Matt Blaze и Steve Bellovin. Proceedings of the Usenix Security Workshop, юни 1995. IP v6 Release and Firewalls. Uwe Ellermann. 14th Worldwide Congress on Computer u Communications Security. Protection, стр. 341-354, юни 1996

34

Интеренет източници: Firewalls FAQ.

http://www.faqs.org/faqs/firewalls-faq

There Be Dragons. Steven M. Bellovin. Proceedings of the Third Usenix UNIX Security Symposium, Baltimore, September 1992. AT&T Bell Laboratories, Murray Hill, NJ. August 15,1992. http://www.zeuros.co.uk/generic/resource/firewall/papers.him

Keeping your site comfortably secure: An Introduction to Internet Firewalls. John P. Wack u Lisa J. Camahan. National Institute of Standards and Technology http://csrc.ncsl.nist.gov/nistpubs/800-10/

SQL .Net and Firewalls. David Sidwell and Oracle Corporation.

http://www.zeuros.co.uk/generic/resource/firewall/papers.htm

Covert Channels in the TCP/IP Protocol Suite. Craig Rowland. Rotherwick & Psionics Software Systems Inc.

http://csrc.ncsl.nist.gov/nistpubs/800-lO.p.s A Network Perimeter with Secure External Access. Frederick M. Avolio u Marcus J. Ranum. Документ,уточняващ реализацията на защитната стена на Белия Дом http://www.alw.nih.gov/Security/FIRST /papers/firewall/isoc94.ps Packets Found on an Internet. Steven M. Bellovin. Lambda. Интересен анализ на мрежовиа трафик от AT&T. ftp://ftp.research.att.com/dist/smb/packets.ps X Through the Firewall and Other Application Relays. Treese/Wolman. Digital Equipment Corp. Cambridge Research Lab. ftp://cri.dec.corn/ Pub/DEC/CRL/tech-reports/93.10.ps.Z

Benchmarking Methodology for Network Interconnect Devices (RFC 1944). S. Bradner u J.McQuaid. http://archives.neohapsis.com/irchives/rfcs/rfcl944.txt

ЗАШИТНИ СТЕНИ - iseca.orgФакултет по математика и...

Documents

Transcript of ЗАШИТНИ СТЕНИ - iseca.orgФакултет по математика и...