Top Banner
СУ Св. Климент ОхридскиФМИ КУРСОВ ПРОЕКТ по Мрежова сигурност-1 на тема FIREWALLSИзготвили: Борислава Спасова, фак. 30787 Петър Пировски, фак. 43720
60
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: FireWall

СУ „Св. Климент Охридски” ФМИ

КУРСОВ ПРОЕКТ по Мрежова сигурност-1

на тема

„FIREWALLS” Изготвили:

Борислава Спасова, фак. № 30787 Петър Пировски, фак. № 43720

Page 2: FireWall

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

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

Firewall е компонент или множество от компоненти, които ограничават достъпа между локалните мрежи и интернет или между самите локални мрежи. Те създават checkpoints на границите на частните мрежи, където проверяват всички преминаващи пакети, и определят дали да ги пропуснат или да ги игнорират в зависимост от това дали отговарят на линията на поведение, програмирана в firewall-а. Един правилно конфигуриран firewall предпазва както локалната ви мрежа от неауторизиран достъп от интернет, така и интернет от неблагоразумието на средно статистическия потребител.

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

Основни елементи на firewalls: Firewall-ите осигуряват възможно най-сигурна интернет връзка като проверяват

внимателно, приемат или отхвърлят всеки опит от външна мрежа за осъществяване на връзка с вътрешната ни мрежа. Един добър firewall трябва да защитава мрежата на всички нива - от data link до application. Firewall-ите са разположени на границата между вътрешната мрежа и директната й връзка с другите мрежи и затова често биват отнасяни към border security. Без border security всеки потребител от вътрешната мрежа трябва да играе ролята на firewall и ненужно да използва компютърните си ресурси, увеличавайки времето необходимо, за да се свърже, аутентикира и криптира данни в локалните високо скоростни мрежи. Firewall-те позволяват всички предлагани услуги за сигурността да се съсредоточат в машини, използвани единсвено за тази цел. Следенето на мрежовия трафик позволява да се избягва hacking трафик, който да използва bandwidth на мрежата. Идеята на firewall е да създаде единствена точка на границата между вътрешната и външните мрежи, където целия преминаващ трафик може да бъде кантролиран. Тъй като стандартните връзки са относително бавни в сравнение със скоростта на съвременните компютри, то латентността на връзката, причинена от използването на firewall-у, често е незабележима. За повечето потребители един сравнително евтин firewall е повече от задоволителен за поддържането на стандартна Т1 връзка с Интернет. За бизнес и ISP, чийто трафик е много по-голям, е създадена съвсем нова генерация от високо скоростни ( и доста скъпи) firewall-и, които могат да поддържат дори частни мрежи.

2

Page 3: FireWall

Firewall-те работят, използвайки три фундаментални метода: Филтриране на пакети – Отказва TCP/IP пакети от неауторизирани машини и опити

за осъществяване на връзка от неауторизирани services. Network Address Translation (NAT) – Транслира IP адресите на вътрешните машини,

за да ги предпази от следенe на трафика отвън. Proxy Сървъри – Осъществява връзки между приложенията от името на вътрешните

машини, за да раздели напълно връзките на мрежово ниво между машини от самата мрежа и външни такива.

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

Повечето firewall-и предлагат и други услуги за подобряване на сигурността като например:

Криптирана аутентикация – позволява на потребители от публични мрежи да се аутентикират пред firewall и да получат достъп до private мрежи.

Virtual Private Networking – установява сигурна отдалечена връзка между две частни мрежи през публично пространство като Интернет. Това позволява на физически разделени мрежи да използват Интернет вместо leased-line връзки, за да комуникират помежду си.

Някои firewall-и предлагат допълнителни услуги като: Сканиране за Вируси – претърсва получените данни за следи от вируси. Филтриране на съдържанието - позволява блокирането на достъпа до сайтове с

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

Филтриране на пакети: Филтрите на пакети всъщност са оригиналните firewall-и. Първите опити TCP/IP

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

Има два основни типа филтриране на пакети: − Оригинален или „stateless” филтър, който се използва най-често от router-ите

и операционните системи; − Stateful филтър, който се използва в съвременните firewalls;

Stateless филтър : Филтрите на пакети са гранични router-и, които увеличават нивото на сигурност

като преценяват дали да пуснат даден пакет или не в зависимост от информацията, която се съдържа в heather-а на всеки отделен пакет. Филтрите могат, поне на теория, да се конфигурират, така че да определят преминаването на пакета по коя да е част от heather-а

3

Page 4: FireWall

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

− Тип на протокола - ... − IP адрс - ... − TCP/UDPпорт - ... − Номер на фрагмента - ... − Source routing информация - ... Филтриране на протоколи – базира се на съдържанието на полето IP протокол и

може да се използва да спира цели семейства от протоколи като:UDP; TCP; ICMP; IGMP Например, ако разполагаме със сървър, занимаващ се единствено с обработка на TCP услуги като HTTP, можем да филтрираме всички UDP услуги. За съжаление полето, обозначаващо протокола, е толкова общо, че повечето сървъри са конфигурирани да пропускат всички протоколи.

Филтриране на IP адреси – дава възможност да се ограничават връзките с конкретни

машини и мрежи на основата на тяхното IP. Повечето филтри забраняват достъпа или на всички host-ове, или на специално посочени такива. Последното е безсмислено, тъй като това означава да се помни всеки хакер, който някога е атакувал мрежата, предполагайки, че той не може да стигне до информацията от друго IP (нещо твърде лесно осъществимо). Следователно филтрирането на отделни IP адреси не е много надеждно. По-голяма сигурност се осигурява като вместо това се дава достъп на определени IP адреси. Това е най-силната форма на сигурност, осигурявана от stateless филтъра. Като се блокира трафика от всички IP адреси, с изключение на добре познати такива, се гарантира, че до router-ите ще достигат само пакети от trusted host-ове или мрежи.

TCP/UDP портове – TCP и UDP портовете са широко използвани за филтриране на

пакети, тъй като те дават по-детайлна информация за това какъв е пакетът. TCP и UDP се отнасят често към филтруте на протоколи тъй като се отъждествяват с протоколи от по-високи нива.

Протоколи, които могат да се филтрират на базата на TCP и UDP портове: − DNS − NetBIOS Session − HTTP − IMAP − FTP − POP − Telnet − SNMP − RSH − SMTP − NNTP Както и при IP адресите, повечето филтри позволяват или да се разреши

преминаването на всички протоколи с изключение на тези в забранения списък, или да се забрани това на всички без някои предварително избрани. Второто е за предпочитане,

4

Page 5: FireWall

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

Портове, които е добре да се блокират: − Telnet − NetBIOS session − POP − NFS − X Windows − Windows Terminal Services

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

Source Routing – процес, който дефинира точния път, през който трябва да премине

пакетът, за да стигне до получателя. Среща се при IP връзки. Съществуват два вида source routing:

− Loose source routing, при който се оказват една или повече машини, през които трябва да премине пакета, но не всички.

− Strict source routing – оказва се точният път на пакета От двата вида първият е най-често използваният от хакерите, за да са сигурни, че пакетът ще се върне при тях. Затова е добре филтърът да бъде конфигуриран, така че да отказва source−routed пакети.

Фрагментация – използва се, за да се осигури преминаването на големи IP пакети

през връзки с малък MTU. Всеки router, през който премине пакета, може да го раздели на по-малки фрагменти, които да е в състояние да изпрати. Системата, която го получава, чака, докато събере всички фрагменти, и след това ги възстановява въз основа на данните в heather-а. Проблемът се състои в това, че TCP или UDP порта се намира в началото на IP пакета и затова се съдържа само във фрагмент 0, следователно следващите фрагменти не могат да бъдат филтрирани на базата на номера на порта. Повечето по-стари филтри просто пропускат тези пакети, предполагайки, че ако нулевият фрагмент е изхвърлен, то останалите са безполезни. За съжаление това не винаги е така. Някои версии на TCP/IP все пак могат да възстановят пакета и ако един от n пакета е валиден TCP пакет, то той ще бъде препратен към получателя. Това означава, че атакуващият може да преправи своя IP стек, така че всички фрагменти да започват от 1 и по този начин да заблуди филтъра.

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

5

Page 6: FireWall

Филтриране на пакети от ОС – за повечето ОС, включително Unix и Windows, филтрирането на пакети е неразделна част от TCP/IP стека, т.е. за всеки отделен сървър може да се конфигурира уникален филтър. Това се нарича end-system филтриране на пакети, тъй като машината, която получава пакета, е тази, която извършва филтрирането. На пръв поглед този тип филтриране изглежда излишен, но никоя гранична система за сигурност не може да предпази сървъра ви от атаки от вътрешната мрежа или от атаки, които се възползават от несигурна VPN или dial-up връзка. За да се предотврати подобна нежелана намеса, е добре да се използват възможностите, дадени от ОС за филтиране, за да се гарантира, че всеки сървър предлага само тези функции, които сме оказали.

Stateful филтри – За разлика от stateless филтрите, където всеки пакет се разглежда

сам за себе си, при този тип филтри се следят всички комуникации, които минават през firewall-а и използват тази информация, за да решат кои пакети да бъдат отказвани. Stateful филтрите проверяват целия комуникционен поток, а не само отделни пакети. Те помнят състоянието на връзките на мрежово и сесийно ниво като записват информация за всяка установена сесия, която преминава през filter gateway и я използват за да откажат валидни пакети от невалидни опити за осъществяване на връзка или hacking.

За разлика от обикновените филтри (които разрешават всички портове от 1024 нагоре и по този начин не осигурява защита срещу троянски коне, работещи на такива портове), stateful филтрите не разрешват други услуги освен тези, програмирани от тях, да преминавт през firewall-а.

Когато trusted host се свързва с TCP socket на външен untrusted host, той предава със SYN пакета и socket (IP адрес и порт), на който очаква отговор. Когато SYN пакета мине през stateful филтър, той прави нов запис в таблицата си, съдържащ destination socket и response socket, и след това препраща пакета към untrusted network. Когато пакета се върне обратно при филтъра, той просто проверява дали source и destination socket-ите на пакета съвпадат с тези, записани в таблицата. Ако запис в таблицата не съществува, пакета ще се изпусне, тъй като не е поискан от машина в мрежата. Филтърът премахва записа в таблицата при размяната на пакетите, приключващи TCP сесията или с няколко минути закъснение. Така се осигурява затварящите се връзки да не оставят „дупки” в таблицата.

Stateful филтрите се програмират по определени правила, наречени линия на поведение. Те включват правила за услугите, на които се разрешава достъп до конкретна машина в мрежата; възможност да се контролира NAT и proxying, както и да възприема IP адрсите, мрежите и портовете като обекти, области и услуги, и вместо да блокира порт 80 за мрежа 192.168.12.0, може просто да се блокират web услугите от "accounting."

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

1. TCP може да се филтрира в нулевия фрагмент – тъй като TCP heather-ът се намира само в нулевия фрагмент, дори той да не бъдат пуснат, останалите ще преминат. Ако TCP/IP стека конструира валиден пакет, той ще бъде предаден на ОС. Като изпращат фрагменти, започващи от 1 и въпреки това съдържащи TCP heather, хакерите могат да получат достъп до локалната мрежа, все едно филтъра не съществува. Решението на този проблем е използването на по-устойчив TCP/IP стек и state-base филтри, например истински firewall-и.

6

Page 7: FireWall

2. По-старите филтри разрешават всички портове над 1024 – само протоколи, които работят на портове над 1024 са уязвими при атаки от този тип. За да се предпазим, трябва да настроим филтъра да блокира всички опити за връзка, освен изрично посочените и такива стартирани от вътрешността на мрежата.

3. Публичните услуги трябва да се препращат през филтъра 4. Троянски коне могат да преминат през филтъра, използвайки NAT т.е. като

транслират протоколи от портове , които не се филтрират (напр. 8080), до порт 80 например, след което да го предадат на вътрешния сървър, за да дадат достъп до мрежата на използващия ги хакер. Един нищо неподозиращ потребител може да получи e-mail от e-mail-а на администратора на мрежата, съдържащ инструкциите да инсталира прикрепената програма, която всъщност е троянски кон. Хакерите могат да използват NAT чрез троянския кон и да заобиколят филтъра.

Няколко препоръки:

1. Aко не може да се използва proxy сървър, е добре да се използва поне stateful филтър.

2. Да се забраняват всички портове по подразбиране освен тези, които се използват.

3. Да се подсигури основната ОС, тъй като сигурността на филтъра зависи от сигурността на устройството, на което работи.

Network Address Translation (NAT):

Network Address Translation (NAT) превръща частните IP адреси от локалната мрежа в глобални IP адреси, които могат да бъдат използвани в интернет. NAT се използва, за да се скрие ефективно всяка информация на ниво TCP/IP за машините в локалната мрежа от хакери в интернет. Това се постига като се замаскира целият трафик, така че да изглежда все едно идва от едно единсвено IP.

NAT скрива вътрешните IP адреси като ги транслира до адреса на firewall-а (или адреса, на който отговаря firewall-а), така че всички пакети преминават през него. От своя страна той ги препредава от своя адрес на локалния потребител, използвайки translation table, където се пазят данни за това кой socket на външния интерфейс отговаря на socket от вътрешния интерфейс. За потребител в интернет целият трафик от локалната мрежа изглежда така все едно идва от една много заета машина. NAT всъщност представлява фундаментално proxy – един host изпраща request от името на всички локални потребители, скривайки по този начин тяхната самоличност от публичната мрежа. Всички ОС от Windows 2000 нататък предлагат NAT за компютри, които се свързват чрез тях към други мрежи или интернет. Повечето версии на Unix осигурват или могат да използват open source IP masquerade софтуер. Всички съвременни firewall-и предлагат NAT. NAT може да се имплементира само на транспртно ниво, което означава, че всяка информация, успешно скрита в data payload на TCP/IP трафика, може да бъде предадена на по-високо ниво и възползвайки се от слабостите на трафика там да комуникира с троянски коне. За тази цел е добре да се използва proxy сървър, за да се предотвратят подобни пробиви в сигурността. Накратко за NAT : За да може да извърши network address translation, firewall-ът поддържа таблица на вътрешните сокети, които отговарят на дадени външни такива. Когато локална машина осъществи връзка с host извън мрежата, firewall-ът заменя source сокета с един от своите

7

Page 8: FireWall

външни сокети и записва в таблицата source сокета, destination сокета, както и конкретния firewall сокет. Когато външната машина изпрати данни, firewall-ът извършва обратното транслиране. Ако не съществува запис в таблицата за source сокета или IP адреса на source е различен от този, очакван от firewall, пакетът се оказва. Това най-лесно се показва с пример. Нека локалната машина да е с IP адрес 192.168.1.9 и иска да останови web сесия с 10.50.23.11 . Като използва следващия свободен порт, 192.168.1.9:1234 започва предаването на TCP пакети към 10.50.23.11:80. Router/Firewall (с вътрешен адрес 192.168.1.1 и външен адрес 10.0.30.2) получава пакета и попълва следните полета в табицата: Source 192.168.1.9:1234 Public Host 10.50.23.11:80 Translation 10.0.30.2:15465 След това препраща пакета, използвайки транслиран IP адрес и порт, така че 10.50.23.11:80 получава пакета от 10.0.30.2:15465. публичната машина отговаря, изпращайки пакет на адреса, от който е получил request, т.е. 10.0.30.2:15465. Когато получи този пакет, firewall-ът претърсва таблицата за съществуващ такъв сокет и след като го намери, проверява дали източникът на пакета е същият като този записан в таблицата. Съществуването на запис в таблицата потврърждава, че този пакет е поискан от локален потребител. Ако такъв запис не същесвува, пакета се отхвърля. След като се потвърди съществуванто на такъв запис, firewall-ът модифицира пакета, слагайки за destination сокет, source сокета на клиента. След това препраща пакета към вътрешната мрежа. Web съвърът от своя страна също е защитаван от NAT, кофигуриран така че да получава пакети на публичното си IP и след това да ги препраща към вътрешността на мрежата. В този случай процесът се нарича пренасочване на портове. За разлика от NAT от страна на browser, този процес не е автоматичен. Транслиращото устойство трябва специално да се конфигурира от администратора на мрежата, за да извършва тази траслация. За конкретния пример – NAT получава HTTP заявка на 10.50.23.11:80. проверява своята таблица и вижда, че порт 80 е mapped на адрес 192.168.0.5:80. NAT заменя IP адреса 10.50.23.11:80 с 192.168.0.5:80 и препраща пакета. При обратната комуникация, праща пакета към 10.0.30.2:15465 като 192.168.0.5:80 се превръща в 10.50.23.11:80. Поради факта, че NAT прави промяна на IP адреса, е необходимо да се направят промени в routing таблиците, за да се подсигури получаването на пакетиие от локалния потребител. Тъй като NAT прави само прости замени в packet layer, той няма нужда да изследва вида на данните, както е при proxies. Затова и повечето имплементации на NAT са също толкова бързи, колкото и обикновеното routing. Firewall-ите, които извършват network address translation трябава да имат поне един валиден IP адрес, който не може да се скрие по никакъв начин. Тъй както NAT извършва промени в IP heather, системи, които разчитат на това данните да остават непроменени (например Heather Authentication при Internet Protocol Security), не могат да работят при NAT. Освен това NAT трудно различава трафика, идващ от няколко клиента едновременно, и затова повечето firewall, които пропускат IPSec трафик, позволяват във всеки момент само един клиент да отваря IPSec тунел към външен източник.

8

Page 9: FireWall

Начини за транслиране на адреси: Динамично транслиране (NAPT или IP Masquerade) – представлява замяна на IP

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

Трябва да се има в предвид, че NAT само замаскира IP адреса на клиента, а не го защитава, ако той осъществи връзка с неподходящ host или ако Trojan, случайно инсталиран на машината на клиента, се опитва да се свърже с конкретен външен host. Затова наличието само на NAT не е достатъчно, за да кажем, че локалната мрежа е добре защитена.

Когато се използва динамичмо транслиране е необходимо да се окаже IP адрес, до който да се транслират локалните адреси. Този адрес ще бъде видим за всички машини извън мрежата. Някои firewall-и позволяват за тази цел да се използва собсвеният им адрес или адрес, който е свързан с тях, и на който отговарят, използвайки ARP.

Всеки IP адрес може да поддържа на теория максимум от 65 536 връзки, тъй като полето, обозначаващо номер на порт, е с големина 16 бита. В дейсвителност се използват доста по-малко, тъй като известен брой портове са заделени за специални цели. Въпреки това оставащите портове са достатъчно много и проблем не би трябвало да съществува (освен ако стотици потребители не се опитат да осъществят интернет връзка едновременно). Ако случайно се окаже, че няма достатъчно портове, просто трябва да се използват повече от едно IP при траслиране.

Статично транслиране – използва се, когато зад firewall-а има ресурси, които трябва

да бъдат достъпни отвън, или когато протоколът, който се използва, изисква да работи на определен порт. Може да се използва и за транслирането на IP адреси от определен обхват. Например, за да транслира 128.110.121.0 – 128.110.121.255 до 10.1.2.0 – 10.1.2.255, firewall-ът извършва статично траслиране за всеки отделен адрес.

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

Load Balancing Translation – позволява трафика към натоварени web sites да се

разпределя между няколко сървъра, като се използва firewall, който да преценява към кой вътрешен сървър да пренасочи request-а. Това донякъде прилича на обратна динамична транслация– firewall-ът решава с кой сървър да се свърже конкретният клиент.

Този тип транслиране работи само с протоколи, които са stateless, и е особено подходящ за web sites, защото при тях не се пази информация за клиентите и е напълно безразлично дали един клиент се свързва към един и същ сървър всеки път. Използването на IP load balancing е от голямо значение за e−commerce sites, които изпозват Active Server

9

Page 10: FireWall

Pages, CGI или Perl scripts, или Java servlets. Тези технологии затрудняват работата на web сървъра, с което намаляват и броя на клиентите, които той може да обслужва.

Network Redundancy Translation – използва се или за балансиране на притока от

клиенти, или за автоматично компенсиране на разпадането на някоя връзка. Network redundancy работи с dynamic translation по подобен на работата на IP load balancing с static translation начин. При network redundancy firewall се свързва с наколко ISP-та чрез различни интерфейси, като за всяко ISP има различем маскиращ адрес. Всеки път, когато потребител от мрежата установява връзка чрез firewall, той решава, в зависимост от натовареността на трафика, към коя мрежа да насочи транслираната връзка. По този начин firewall-ът може да пренасочи вътрешните си потребители към няколко различни мрежи. Ако връзката с някоя от мрежите се прекъсне, то тази мрежа се счита за претоварена и към нея не се пренасочват нови клиенти.

Конфигуриране на router-и за NAT: Когато използваме NAT с IP адрес, различен от IP адреса на firewall-а, трябва да се конфигурира routing на мрежата, за да минават пакетите през firewall, както и firewall, за да стигат пакетите до правилните interfaces. Това дали routing трябва да се конфигурира отделно от firewall-а, се определя от това дали firewall сам препраща пакетите или разчита на системата на host за това. Ако разчита на ОС на host за препращане, трябва предварително да е известно дали firewall транслира адреса преди или след routing.

При Unix може да се установи дали firewall разчита на ОС за предаване на пакетите по това дали firewall изисква използването на routed daemon. При Windows това се установява, ако firewall активира Enable IP Forwarding setting в network Control Panel или ако изисква да се активира ръчно от потребителя.

Ако firewall разчита на ОС, трябва да се подсигури верността на routing таблиците за различните видове трансиране. Някои firewall-и конфигурират routing таблиците и при тях се знае, че пренасят пакетите сигурно. При тези firewall-и, които не предлагат тази опция, е добре да се прочете документацията на тази тема и да се тества routing през firewall-а след пълното конфигуриране.

Проблеми при NAT : Съществуват няколко протоколи и програми, които не могат да работят с NAT : − H.323, CUSeeMe, and VDO Live – тези video teleconferencing програми не могат

да работят чрез NAT, тъй като изискават back channel с host-а. Някои firewall-и могат да правят подобрения в таблиците си, за да позволят на отделни потребители да установяват подобни канали.

− Xing, Rshell, IRC – по подобни причини на video teleconferencing. − PPTP - проблемът идва от факта, че PPTP разчита на криптираната IP

информация в потока от данни. Макар че протоколи, които не са основани на TCP/IP, могат да минават през PPTP тунелите.

− FTP – FTP поставя информация в ASCII текст за IP адреса в TCP пакети. Дължината на този текст може да бъде променена при транслирането

10

Page 11: FireWall

− ICMP – този софтуер често прибавя първата чат на оригиналния пакет в ICMP съобщение и тази част съдържа нетранслирания адрес. Едно просто решение е да не се разрешава ICMP трафик през firewall.

− IPSec - АH на IPSec не могат да преминат през NAT, тъй като AH използват hash за проверка дали пакета е бил променен. Целта на NAT е да променя IP адреса, следоватлно hash на AH ще се промени и системата ще го определи като невалиден.

Макар на пръв поглед NAT да изглежда надежден начин за скриване на IP адреси, така че потребителите да са защитени от атаки на хакери, в действителност това не е съвсем така.

Слабости при NAT : Статичната транслация не защитават потребителите в мрежата и при нея хакерските

атаки ще бъдат транслирани като всяка друга валидна връзка. Решението на този проблем е намаляването на attack vectors до един и използването на application proxy сървър за допълнителна защита на потребителите.

Internal Host Seduction – дори хакерите нямат достъп до мрежата, нищо не може да попречи на потребителите от нея да се свържат с хакерите. E-mail с website link, Trojan horse или website с примамливо съдържание могат да убедят потребителя да установи връзка с машина, която има за цел да се добере до информация за локалната мрежа. В този случай application proxies отново са решение. Чрез проверка на съдържанието на протоколи от типа на HTTP, могат да се откриват Java applets, ActiveX controls, downloadable executables, malformed URLs, както и други приспособления, използвани от хакерите..

Source Routing през NAT - Dynamic NAT защитава клиентите си като просто елиминира всеки директен път до тях от Интернет. Тъй като не съществува обратен път, повечето атаки от този тип се спират от NAT, освен ако хакерът не използва source routing и не знае IP адреса на host от мрежата. При нормална IP сесия heather съдържа само source и destination адрес, и разчита на устойствата межку комуникиращите страни да изберат пътя. Когато се използва source routing, source host може да окаже точния път, през който да премине пакета. За да заобиколи NAT, хакерът трябва да упомене само IP адреса на машината в мрежата, до коята иска да достигне, и адреса NAT като междинно устройство при loose source routing. Очевидното решение е да се конфигурира firewall, така че да изпуска всички source-routed пакети.

Application−Level Proxies: Proxy сървърите първоначално са създадени, за да кешират най-често използваните

web страници на локален сървър, така че да се избегне излишно свързване към Интернет при многократно им поискване. След скоростното развитие на Интернет кеширането на страниците става излишно или по-скоро значително по-трудно и се използва само от изключително големи огранизации и в ISPs. Въпреки многото си преимущества, новият Web има и своите недостатъци. Оказва се, че proxy сървърите притежават забележителни способности, които се справят с част от тях. Те могат да скриват всички потребители в мрежата зад една машина; могат да филтрират URLs; могат да изпускат пакети с подозрително или нелегално съдържание. Заради тези си възможности сега proxy сървърите са сред най-използваните компоненти на firewall.

11

Page 12: FireWall

Proxy сървърите регенерират high−level service requests на външна мрежа от името на клиентите си от частните мрежи като по този начин те ефективо скриват самоличността и броя на клиентите си. Поради специфичното си разположение между голям брой частни клиенти и публични сървъри, proxies се използват и за кеширане на често използвано съдържание от публичната мрежа, за да се намали достъпа до тази мрежа през много скъпи връзки. Повечето имплементации на security proxies включват филтър на пакети и Network Address Translation, за да оформят цялостен firewall. Комбинирайки тези технологии, се избягват някои от атаките, към които proxies са уязвими. Стандарните proxy сървъри работят на принципа на service protocol forwarding. Proxy сървърът за даден протокол работи на машина, с която всички потребители могат да говорят, а от своя страна тя говори с останалия свят. Клиентската програма на потребителя се свързва с proxy сървъра вместо с „истинския” сървър в интернет. Proxy сървърът обработва заявките на клиента и решава коя да пропусне и коя да спре. Ако заявката е одобрена, той осъщетвява връзка с Web или друг сървър от името на клиента и ,ако получи отговор, го препраща обратно към него. По време на комуникацията, както клиента, така и външният сървър си „въобразяват”, че осъществяват директна връзка (фиг.1). Тази система не изисква специален хардуер, но изисква специален софтуер за повечето услуги. Важно условие, за да работи, е клиентът и сървърът да нямат директна IP връзка помежду си. Ако това не е изпълнено, то клиентът лесно може да заобиколи proxy системата (естествено и някой от вън също може да я заобиколи).

Фиг.1 Защо се използват proxy сървър системите? От една страна, няма смисъл от връзка с интернет, която няма да ползват всички потребители. От друга, от гледна точка на сигурността, е недопустимо всеки потребител да има свободен достъп. Трябва да се постигне някакъв компромис. Най-очевидното решение е да се осигури интернет достъп на единствен host за всички потребители. Това обаче води до проблеми за потребителите. Те не могат да ползват интернет услугите директно, а трябва да си свършат работата на машината с интернет връзката и след това да прехвърлят резултата на собствените си машини. Още по-лошо става, когато машината с връзката е с различна операционна система. Потребителят може да не е запознат с дадената операционна система и така да бъде доста ограничен в действията си.

12

Page 13: FireWall

Proxy системите решават тези проблеми. При тях взаимодействието на потребителя с машината, която се свързва с интернет, е автоматизирано и протича „зад кулисите”. За потребителят се създава илюзията, че си комуникира директно с интернет сървъра без никакво междинно взаимодействие (фиг.1). Как точно работят proxy системите? На Фиг.2 е показан процеса в подробности. Proxy сървърът слуша за заявки (reqest page) от клиентите от вътрешната мрежа и след това препраща тези заявки към интернет сървъра, сякаш самият той е клиент. Когато получи отговор (return page), го препраща към вътрешния клиент, все едно той (proxy сървърът) е сървърът, до когото е пратена заявката. Междувременно при получаване на заявката се проверява дали има право да достави заявеният URL и при връщане на отговора, той се филтрира от нежелано съдържание преди да се достави на клиента.

Фиг. 2

Системата с proxy сървъри, по отношение на сигурността има доста преимущества:

Криене на клиентите от външно излагане. Това е основното действие, свързано със сигурността. Както и NAT, proxy сървърите могат да направят. така че цялата локална мрежа да бъде виждана отвън като една машина, защото само една машина праща заявки. Предотвратява се достъпът отвън до вътрешни потребители, защото не съществува връзка на транспортно ниво между двете мрежи и защото адресите на външната и вътрешната мрежа са несъвместими. Това се случва, защото proxy сървърът изцяло подменя заявките, а не променя само адресите на header-а. Само HTTP заявки минават през proxy сървъра. TCP/IP (и други протоколи от ниско ниво) не се предават освен, ако сървърът не е лошо конфигуриран.

Блокиране на URL. Позволява на администратора да забранява достъпа до дадени

страници според техния URL. На теория това ще попречи на потребителите да посещават

13

Page 14: FireWall

сайтове, до които администраторът им е забранил достъп. Тази функционалност е лесна за осъществяване. Просто proxy сървърът проверява дали заявената страница не е с URL, който е забранен, и ако това е така, не изпраща заявката. Блокирането обаче може лесно да бъде заобиколено, защото сайтовете могат да бъдат адресирани чрез техните IP адреси и дори чрез целочислени адреси. Така например въвеждането, на който и да е от следните 3 URL-a в браузъра, ще доведе до един и същ резултат:

http://www.gamehound.com/default.html http://192.168.13.12/default.html http://3232238860/default.html

Но блокировката (най-вероятно) ще спре само първия URL. Третият, целочислен

адрес е десетично представяне на двоичния 32-битов адрес. Може да се получи лесно от втория, като се умножи всеки от октетите по 2 на степен съответно 24,16,8 и 0 и получените се съберат. Някои сайтове, които се намират зад proxy сървъри, не могат да бъдат достигнати с целочислен адрес, защото е възможно тези адреси да не бъдат разпознати.

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

Филтриране на съдържанието. Понеже препредават данните, Proxy сървърите могат

да бъдат използвани за претърсването им за подозрително съдържание. Това значи, че може да се конфигурира HTTP proxy услуга, която да не допуска ActiveX controls, Java аплети или дори прекалено големи изображения, ако администраторът смята, че това ще е проблем за сигурността. Може да се използва SMTP proxy услуга, която да не допуска прикрепени изпълними файлове и архивирани zip файлове. Всичко това предпазва локалната мрежа от заразяване с троянски коне. Филтрирането на съдържанието може да бъде използвано за проверяване на страниците за присъствие на определени думи или фрази, които биха представлявали проблем.

Проверка на консистентността. Става въпрос за проверявне дали съдържанието на

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

Блокиране на маршрутизацията. Тъй като заявката напълно се подменя, не е нужно

пакетите от транспортния слой да бъдат пренасочвани. Това премахва атаките върху транспортния слой, като source пренасочване, фрагментация и множество denial−of−service

14

Page 15: FireWall

атаки. Чрез премахване на маршрутизацията се осигурява протоколи, за които няма proxy услуга, да не могат да преминават във външната мрежа. Това е може би най-важното преимущество на proxy сървърите. Понеже няма предаване на TCP/IP пакети между външната и вътрешната мрежа, голямо количество denial−of−service атаки и атаки върху слабости в системата са предотвратени.

Регисриране и алармиране. Proxy сървърите осигуряват преминаването на

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

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

Съществуват, обаче няколко недостатъка на proxy сървърите:

Единствена точка на слабост. Всяка система с единствена точка на контрол е с

единствена точка на слабост. Ако хакер може да деактивира proxy сървъра на една мрежа, то цялата мрежа остава без интернет. Proxy сървърите, маршрутизаторите и firewall-ите страдат от този проблем в известна степен. С маршрутизаторите проблемът се решава лесно, като просто се правят няколко маршрута за достъп до интернет. Firewall-ите са много по-устойчиви на тези атаки от обикновените proxy сървъри, защото те филтрират пакетите от ниско ниво. Понеже proxy сървърите не съдържат функционалност да се пазят по този начин, те са уязвими от denial−of−service атаки.

Клиентите трябва да са съвместими с proxy сървърите. Ако клиентският софтуер не

може да бъде конфигуриран да работи с proxy, то proxy сървърът не може да бъде използван от този клиент освен чрез истински NAT. Това може да бъде голям проблем за услуги, като FTP например, при които клиентският софтуер не подържа работа с proxy.

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

услуги, за които не може да се филтрира съдържанието. Поточно-ориентираните услуги, като RealAudio или RealVideo например, са много трудни за филтриране, защото съдържанието трябва да тече в реално време. Ако се прекъсне компресираният поток, остатъкът от него не може да бъде възстановен.

Небрежни default конфигурации. Много proxy сървъри страдат от този проблем,

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

Proxy сървърите създават „гърло на бутилка”. Както при firewall-ите и

маршрутизаторите, единствеността на интернет връзката при proxy сървърите може да създаде „гърло на бутилка”(bottleneck). С нарастването на броя на потребителите над

15

Page 16: FireWall

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

След като обяснихме основните техники, които се използват при изграждането на

един firewall, ще разгледаме няколко firewall-и, които за удобство са разделени в зависимост от ОС, на която работят. В допълнение ще представим няколко хардуерни решения.

Windows като firewall

Нека разгледаме операционната система Windows в качеството й на firewall. От Windows NT 4 нататък, Windows системите поддържат филтриране на пакети за

блокиране на портове и за подпомагане на сървърите срещу атаки. Windows 2000 значително подобрява филтрирането и започва да подържа Network Address Translation (NAT). Windows Server версиите също така подържат маршрутизация и PPTP VPN тунелиране. Но въпреки множеството от чертите на firewall, поддържани в Windows, TCP/IP стека не е достатъчно надежден да издържи сериозна интернет атака. Въпреки че срещу повечето основни denial−of−service атаки са направени кръпки, която и да е flood атака ще доведе до грешки, които ще направят сървъра негоден за употреба за определен период от време. Ще разгледаме последователно операционните системи Windows NT 4 и Windows 2000. Понеже от гледна точка на сигурността няма съществена разлика между Windows 2000 Professional и Windows XP Professional, то ще разгледаме само първата операционна система.

Windows NT 4 Най-напред трябва да се каже, че тази операционна система не е firewall. Наистина се поддържа обикновено филтриране на пакети и PPTP филтриране, но няма NAT , както и proxy услуги без инсталиране на допълнителен софтуер. Още повече, че TCP/IP стека не е напълно устойчив срещу злонамерени пакети, въпреки че след последните кръпки не се дава лесно на най-опасните атаки. Windows NT 4 не е направен да действа като стена, а по-скоро е направен за по-висока производителност в мрежа. Затова няма да го разглеждаме в подробности, а ще направим преглед на слабостите му от гледна точка на сигурността. Ето няколко причини, заради които не е полезно да се използва Windows NT 4 като самостоятелна firewall:

− Опростено филтриране на пакети. Филтърът на пакети взема решения на основата само на информацията, съдържаща се в пакетите. Не се взема предвид информация за връзката или за други конструкции от по-високо ниво. Филтърът е способен да блокира TCP, UDP или IP протоколи индивидуално за всеки интерфейс. Той може да бъде конфигуриран да пропуска всички протоколи или да пропуска дадени протоколи. Не може обаче да бъде конфигуриран да не пропуска дадени протоколи. Филтърът може да блокира само входящи пакети, всички изходящи пакети се изпращат.

16

Page 17: FireWall

− Няма NAT. Windows NT няма възможността да поддържа Network Address Translation, въпреки че тази възможност я има в Windows 2000. Това значи, че ако не могат да се изпълнят изискванията на връзката, като се използва proxy, трябва да се позволи маршрутизация от интернет към частната мрежа, като се използват публични адреси.

− Няма proxy. Windows NT не поддържа proxy услуги, въпреки че Microsoft Proxy Server – добавка проектирана за Windows NT, е прилично proxy сървър приложение. Обаче това все още не е firewall, защото не прави нищо да предпази операционната система от denial−of−service атаки и неправомерен достъп.

− Ограничено регистриране и наблюдение. Тези функции са непълни, защото са направени да действат на по-високо ниво. Регистрирането (logging) и наблюдението (monitoring) се извършват само върху обекти от високо ниво, като файлове и потребителски акаунти. Индикатори на хакерска дейност, като злонамерени пакети или source−routed пакети, са невъзможни за проследяване в Windows NT.

− Тунелиращият протокол разчита на поделени тайни пароли, които лесно могат да бъдат открити и използвани за други цели.

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

Windows 2000 Операционната система Windows 2000 е изградена на основата на Windows NT

ядрото с интерфейса на Windows 98. Тя съдържа функционалност, липсваща при Windows NT, но присъстваща в Windows 98.

Ето някои характеристики, които в допълнение към тези, които са наследени от Windows NT, много наподобяват функционалността на firewall:

− CryptoAPI/Public Key Infrastructure − Kerberos аутентикация − Network Address Translation − Подобрено филтриране на пакети − Layer−2 Tunneling Protocol (L2TP) − IPSec

Единственото, което липсва е network proxying, което е осигурено с добавянето на Microsoft Internet Security and Acceleration Server.

CryptoAPI CryptoAPI е множество от шаблони, които правят всеки криптиращ алгоритъм да

изглежда еднакъв за операционната система и другите програми. Това означава, че може да се инсталира всеки криптографски модул (наречен Cryptographic Security Provider, или CSP), като DES, RSA или Blowfish, в Windows, за да бъде широко използван. Това още значи, че ако даден алгоритъм е застрашен от нарастващата компютърна мощ или е установено, че не работи добре, той лесно може да бъде сменен изцяло.

17

Page 18: FireWall

CryptoAPI дава заявки от приложенията до различните CSP-та да осъществят следните дейности:

− Генериране на публичен ключ − Криптиране/декриптиране − Цифрово подписвне − Хеширане

Не е нужно дадено CSP да изпълнява всяка от тези функции, защото няколко CSP-та могат да са инсталирани и да се използват за различни цели. Windows 2000 е в комплект с CSP, имплемрентиращо RSA за генериране на публични ключове, RC2 и RC4 съответно за bulk block и bulk stream криптиране и MD4 и MD5 за цифрово подписване и хеширане.

Kerberos аутентикация Kerberos аутентикацията е интернет стандарт за потребителска аутентикация. Тя е

надеждна аутентикационна система. Не разчита на сигурна мрежа, или на сигурност на клиетнтите от мрежата. Kerberos е проектирана от самото начало с идеята, че трафикът през мрежата може да бъде прихванат, четен и променян. Kerberos не разчита на ‘сигурност от незнание’ (security through obscurity).

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

Kerberos има 3 нива на криптогрфска сигурност:

− Аутентикация. Гарантира на всеки от клиентите, че другият е този, за който се представя.

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

− Криптиране. Прави съдържанието на всеки пакет недекриптируемо за трети страни, различни от двата клиента. Наричат се частни съобщения.

Сесиините ключове имат кратък срок на валидност. Така, ако някой се добере до сесиен ключ, той ще може да се възползва от него само, докато ключът е валиден.

Network Address Translation Поддръжката на NAT при Windows 2000 Server версиите е добра и много лесна за

конфигуриране. Понеже NAT е вграден в пренасочващия софтуер, не е нужно да се занимаваме с някои специфични проблеми с настройките, които възникват, когато се използва такъв, който не е вграден. При Windows 2000 Server просто се дефинира обхвата на вътрешните адреси, които се преобразуват, и ! готово.

NAT софтуерът позволява да се определи публичен IP адрес на host от вътрешната мрежа. Това позволява да се извършват услуги на този host, които да бъдат видими от външната мрежа. Все пак, определено е по-сигурно да се превежда услугите като се използва IP адреса на firewall-а.

18

Page 19: FireWall

Подобрено филтриране на пакети Филтрирането на пакети при Windows 2000 е доста усъвършенствано в сравнение с

Windows NT 4. Вече е възможно филтриране, както на входящи, така и на изходящи пакети. Също така е възможно блокиране на дадени протоколи, както и позволяване на достъп на дадени протоколи. Конфигурирането на IP филтърът е улеснено. Все още обаче не може да се каже, че е достигнато нивото на филтриране на истинска firewall.

Филтърът позволява блокиране на някои типове ICMP съобщения и така предпазва от denial−of−service атаки, докато запазва полезната функционалност на ICMP протокола.

Layer−2 Tunneling Protocol (L2TP) Layer−2 (Data Link layer) Tunneling Protocol е наследник на PPTP, усъвършенстван от

Cisco Systems, които са създали протокол, независим от IP. PPTP може да бъде пренасян само чрез IP пакети, докато това не е задължително за L2TP. Едно преимущество на прекъсването на връзката между тунелирането и транспортния слой е, че L2TP може да поддържа няколко тунела между една и съща двойка точки, докато PPTP може само по един. Тази функционалност може да се употреби, например, като се направят няколко тунела с различно качество на услугата.

IPSec IPSec е криптираща технология върху слой 3 (мрежовия слой). Тя осигурява

кодиращи транспортни услуги, наподобяващи тези при PPTP и L2TP, с тази разлика че в имплементацията на Windows 2000 я няма концепцията за свързваща сесия или тунел. Така че тази технология не е подходяща за създаване на VPN, докато PPTP и L2TP са. При IPSec индивидуални кодирани пакети могат да се предават между двете страни, като се предполага, че има някаква първоначална аутентикация, която ще даде възможност на host-овете да декриптирт пакетите, когато те пристигнат. Това е изцяло различно от концепцията с тунелите, при която, когато тунелът се затвори, информацията, необходима за декриптирането на съдържанието му, се губи. IPSec е само IP с криптирано съдържание - няма инкапсулация с други протоколи. Понеже няма допълнителни изисквания за създаване и поддържане на тунел, IPSec е по-подходяща за комуникация чрез съобщения от PPTP или L2TP. Все пак, нека си зададем въпроса „Може ли Windows да се използва като firewall, без инсталацията на допълнителен сигурен софтуер?”. Отговорът е „не”. Поне не и докато Microsoft не промени подхода си към този проблем. Вече говорихме за проблемите на Windows NT 4. Windows 2000 се държи доста по-добре, но все още разчита на постоянен поток от ъпдейти, за да остане сигурен, докато се откриват нови и нови заплахи. Има няколко проблема, когато се разчита на ъпдейти, за да се запази една firewall сигурна:

− Ъпдейтите винаги следват пробивите с няколко дни или няколко седмици, в зависимост от сложността си. Това значи, че винаги съществува прозорец на уязвимост между откриването на уязвимостта и появяването на кръпката за нея.

− Може да се случи след поредица от ъпдейти, някой от тях да доведе до конфликтни ситуации, които да причинят срив в системата.

− Машините трябва да са свързани с интернет, за да свалят последните кръпки. Така те могат да бъдат пробити в същия момент, докато се опитват да оправят слабостите си.

19

Page 20: FireWall

Какво не е наред с Windows? Главният им проблем е, че след като задоволят множеството от потребителски изисквания, веднага пускат софтуера, защото са притиснати от крайни срокове. Този софтуер е голям и сложен и не е отделено достатъчно време за тестване от гледна точка на сигурността. Това води впоследствие до пускане на нови и нови ъпдейти, чиито недостатъци са ясни. За разлика от Microsoft, производителите на сигурни операционни системи и защитини стени подсигуряват срещу атаки своите продукти предварително. Това е така, защото техният основен приоритет е сигурността. Тези операционни системи са опростени и не се опитват да вкарат всичката си функционалност в ядрата си. Единствената характеристика, от която се нуждаят, е сигурността, затова са базирани на по-малко код, което ги прави по-лесни за подсигуряване срещу злонамерени атаки.

Firewalls за Windows: Съществуват толкова много firewall продукти, че е трудно човек да избере какво

точно да използва. Ще разгледаме следните преложения за стени, работещи под Windows (повечето имат версии, работещи и под други операционни системи):

− Checkpoint Firewall−1 − Symantec Enterprise Firewall − Microsoft Internet Security and Acceleration (ISA) Server

Ще разгледаме накратко само основните характеристики на тези продукти, както и

ще ги оценяваме от гледна точка на сигурността.

Checkpoint Firewall−1 Checkpoint развиват концепцията за statefull инспекцията, подобряваща сигурността при филтрирането на пакети без допълнителното утежняване с proxy съвъри. Когато пакетът премине през серията тестове на инспектиращия модул, оригиналният пакет се предава към мрежата. Това значи, че всякакви изкривявания, неотчетени от инспектиращия модул, се предават без изменение от firewall модула. Statefull инспекцията е нещо средно между обикновенното филтриране на пакети и application proxies. Понеже има информация за всяка връзка, може да се направи по-точна преценка дали пакетът може да мине или трябва да бъде спрян. Но понеже обикновено няма възможност да се следи вътрешното съдържание на множество протоколи, statefull инспекцията се счита за по-близка до филтрирането на пакети, отколкото до proxy сървърите. Firewall-1 решава този проблем до известна степен, като разрешава вградени протокол-филтри, които наподобяват истински proxy-та. Тези филтри разпознават по-известните протоколи, като HTTP, SMTP и FTP, и могат да правят минава/пропада решения върху тези протоколи.

Главни характеристики: − Stateful филтър на пакети − Прозрачни proxy сървъри за специфични протоколи(HTTP, SMTP ,FTP) − Reverse proxies (HTTP, SMTP, FTP) − Network Address Translation

20

Page 21: FireWall

− Port пренасочване − Поддръжка на DMZ − VPN Client Software (Windows 98/NT/2000/XP, Macintosh, Unix, Linux) − Регистрация (Logging) и e-mail уведомяване.

Второстепенни характеристики:

− Филтриране на съдържанието (Java, ActiveX, сканиране за вируси, URL блокиране)

− Детектиране на сканиране, детектиране на spoofing, блокиране на URL − SYN flood защита − Сигурен сървър (proxy аутентикация) − Наблюдение в реално време − Централизирана администрация − Възможност за конфигуриране на алармите − Изпълнение на произволни програми под event detection − Диагностични инструменти − DHCP, SNMP − Split DNS − SQL proxying − Online Help

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

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

Symantec Enterprise Firewall: Firewall-а Symantec Enterprise Firewall е proxy сървър, отговарящ за сигурността. Тя не съдържа адаптивната proxy филтър технология, която увеличава скоростта до тази на statefull инспектор, но въпреки това е една от най-бързите proxy firewalls.

Главни характеристики:

− Packet Security Filter − Network Address Translation − Security proxy − Отдалечена аутентикация − VPN поддръжка е предвидена в добавката Symantec Enterprise Firewall VPN

Второстепенни характеристики: − MIMEsweeper virus scanning – използва се за пазкриване на вируси при

downloads и attachments.

21

Page 22: FireWall

− URL blocking − Прозрачност – не е нужно да се конфигурират клиентските приложения или

да се разчита, че клиентите са proxy съвместими, за да се използва Symantec Enterprise Firewall

− Illegal NAT − Dual DNS – позволява различни DNS имена да се предоставят както на

публичната, така и на частната стрaна на proxy-то.

Сигурност Архитектурата на стената Symantec Enterprise Firewall е изключително силна от

гледна точка на сигурността. Малко вероятно е атаки през стената да успеят, що се отнася до самата proxy архитектура. Aplication−layer поддръжката на NAT е много силна, а също така и е прозрачна. Не се поддържа Network−level routing и следователно не е включен филтър на пакети. Всичката информация, дори тази от ниско ниво, като ICMP и TCP, преминава през Application−layer proxy услугата и се въстановява от стената. Това е най-сигурният начин за предаване на информация между различни интерфейси, защото гарантира, че злонамерени пакети не могат да преминават.

Слабото място на Symantec Enterprise Firewall е, че разчита на устойчива операционна система и устойчив TCP/IP стек. Всичко, което прави стената, е на ниво по-високо от транспортния слой. Няма MAC−layer защита (като филтриране на пакети например) за самата операционна система, следователно няма поддръжка на неща като anti−spoofing. Това е често срещан проблем за чистите proxy-та. В крайна сметка това означава, че хакери могат да се опитат да счупят firewall-а и да причинят denial of service, но не могат да се промъкнат зад стената и да влязат в подсигурената мрежа.

Microsoft Internet Security and Acceleration Server Microsoft ISA Server замества Microsoft Proxy Server 2.0 като firewall продукт на

Microsoft и за разлика от него е истинска firewall. Все пак ISA Server има някои недостатъци. Той разчита основно (макар и не изцяло) на вградените в Windows 2000 защитни механизми и следователно тези проблеми от ниско ниво (слой 4 и по-надолу), които се отнасят до Windows 2000, е много вероятно да се отнасят и до ISA Server. Обикновено в ISA Server има повече от един начин да се постигне даден резултат, което прави трудно определянето на какво точно трябва да се промени, за да се реконфигурира политиката на сигурност.

Главни характеристики: − Stateful инспекция на пакети − Circuit layer (SOCKS) proxy − Application-слой филтриране − IPSec, PPTP и L2TP VPN − Множество методи за аутентикация

Второстепенни характеристики:

− Силна детекция на нарушители. − Подсигуряване на операционната система

22

Page 23: FireWall

− Възможност за изпращане на e-mail или стартиране на програми в отговор на сигнал за тревога

− Прозрачни proxy услуги − Кеширане на съдържанието − SSL bridging − Качествен Service bandwidth allocation − Enterprise management

Сигурност ISA Server включва прост wizard, който конфигурира вградените в Windows 2000 security характеристики, за да предостави нивото на сигурност, което се изисква от една firewall. Също така автоматично настройва NAT и VPN особеностите на операционната система, за да ги съвмести със политиката, която е установена в ISA Server интерфейса. Слабото място на ISA Server е фактът, че е основан на операционна система, която е пригодена за много цели. За разлика от други firewalls, Windows 2000 е подложен на огромно количество атаки и е твърде вероятно грешки, свързани с TCP/ IP стека, да въздействат и върху ISA Server. Все пак е постигнато много при интегрирането на Application−layer security. ISA Server успява да се защити от вируса Code Red в деня на появяването му ( при положение, че политиката на достъп е била стриктна). ISA Server поддържа third−party content modules и има вградена SDK за развиване на сигурността от страна на потребителите. Това дава възможност на потребителите, сериозно интересуващи се от сигурност, да вземат нещата в свои ръце, по начин който само open−source firewalls са позволявали до сега.

За пълнота можем да споменем и едни от най-разпространените personal firewall-и − McAfee Firewall 3.0 − ZoneAlarm − Norton Personal Firewall − Sygate Personal Firewall

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

Комерсиални firewall-и за Unix базирани ОС: Computer Associates eTrust Firewall: Когато става въпрос за големи мрежи, състоящи се от стотици компютри,

администрирането се превръща в непреодолима задача. За да улеснят администраторите на подобни мрежи, Computer Associates създават пакета Unicenter TNG. Частта, която представлява firewall, е eTrust firewall. Този firewall работи на голям брой версии на Unix,

23

Page 24: FireWall

както и на Windows NT. eTrust firewall предлага stateful packet filtering, NAT, проверка на пакети и добавки за поддържаните протоколи, generic proxying за пренасочващите протоколи и централизирана аутентикация. Усъвършенстваният security event monitoring, logging и response позволява автоматична реконфигурация на политиката за сигурност при засичането на подозрителна или застрашителна дейност. Системата са заключва сама, за да даде време на администратора за реагира на проблема.

Предимства

− Работи както на Unix, така и на NT машини − Интегрирана е в Unicenter − Централизирано управление − Стабилно отдалечено управление

Недостатъци − Requires Unicenter TNG − Long Learning Curve

Изисквания към платформата: − Intel Pentium Microprocessor or Unix workstation с еквивалентни възможности − 64MB RAM (128MB са препоръчителни) − Най-малко 500MB hard disk − Unix or NT − Поне два мрежови interfaces

Главни характеристики:

− Филтър на пакети (stateful) − Network Address Translator (dynamic, static) − DMZ support − Port redirection − Proxies (HTTP, FTP, RealAudio, etc.) − Transparent proxies − Reverse proxies (HTTP, SMTP, FTP, etc.) − Сигурна аутентикация (NT Server, RADIUS Server) − Достъп до бази данни и известяване по e−mail

Предоставеният stateful филтър е много надежден и може да се сравнява с този, предоставян от Checkpoint Firewall−1. Услугата Network Address Translation е вградена в stateful инспектора. Proxy функционалността предлагана от eTrust не се намира точно на Application layer; съдържанието на протоколите се пренаписва от stateful inspector вместо да се предостави на отделна Application layer услуга. Тези части на протокола, за които firewall не разполага с информация, не могат да бъдат пренаписани

Второстепенни характеристики: − Филтриране на съдържанието (Java, Virus Scanning, URL blocking) чрез

допълнения в пакетите eTrust Content Inspection и eTrust AntiVirus − Засичане на опити за сканиране и spoofing; автоматично блокиране − Графично администиране − Отдалечено администриране

24

Page 25: FireWall

− Централизирано администриране − Работа с overall enterprise management tools − Transparent ARP support − Защита от SYN flood − Anti−spoofing контрол − Real−time monitoring и reporting − Policy−based конфигуриране и управление· − Calendar support

Сигурност: eTrust firewall използва stateful packet filter, който да следи информацията за

големия брой преминаващи пакети. Това включва и UDP пакети, които не поддържат сесийна информация. Филтърът на пакети проверява стандартните IP полета като source и destination адрес, номерата на портовете, допълнителните полета, SYN bit, ICMP съобщенията и т.н. В допълнение могат да се добавят правила за идентифициране на потребителите, позволено време за достъп и ограничения за мрежовите ресурси.

Firewall проверява всеки пакет преди да го предаде на IP стека и по този начин блокира атаки срещу себе си като Ping of Death, teardrop атаки и други, при които се използват модифицирани IP пакети.

Едно от предимствата на firewall е, че преодставя еквивалент на protocol proxying за някои протоколи като директно работи с IP пакетите вместо да ги предава на отделно proxy server прилижение. Това намалява латентостта на връзката между мрежата и Интернет.

SecurIT Firewall SecurIT firewall не осигурява фитриране на пакети. Вместо това предоставя

Application−level proxies за всеки протокол, който преминава от ликалната мрежа до Интернет. SecurIT firewall използва аутентикация при предоставянето на потребителски или IP базиран контрол. Предимствата на SecurIT firewall се състоят в широката гама от протоколи, за които предоставя proxy redirection. В добавка SecurIT предлага надежден VPN компонент, който дава възможност за създаването на криптирани IP тунели между локалната мрежа и Интернет.

Предимства

− Работи върху Unix и WindowsПоддържа широка гама протоколи − VPN − Централизирана аутентикация − Високо скоросно application proxying

Недостатъци − Не предлага филтриране на пакети − Трудно се намира − Версията за NT не стабилизира ОС

Изисквания към платформата: − SunSparc 5 или Ultra−SPARC, Intel Pentium − 2GB hard disk drive

25

Page 26: FireWall

− 32MB RAM − PCI Quad adapter − Два или повече мрежови интерфейса − CD−ROM drive

Главни характеристики:

− Bidirectional transparent proxy services за широка гама от протоколи − VPN между мрежи, защитени със SecurIT − DMZ Support − Сигурна аутентикация (Unix passwords, S/Key software, SecureID, Safeword

Enigma Logic) − Достъп до бази данни и известяване по e−mail

SecurIT предлага няколко security proxies за стандартните Интернет протоколи. Firewall използва generic TCP proxy за скриване на клиентите си. Тази функция е представена в документацията като Network Address Translation, макар че не е еквивалентна на истиския Network−layer NAT. Аутентикацията се извършва посредстом Bellcore's (сега Telcordia's) S/Key one−time−password алгоритъм. Липсващи в major feature set са packet filtering с Network Address Translatio, което може да представлява проблем, ако ОС, която се използва, не е достатъчно надеждна.

Второстепенни характеристики:

− SQL proxying − Отдалечено администриране − Content filtering (Java, Virus scanning, URL blocking и други)

Сигурност SecurIT не филтрира пакетите преди да ги предаде на IP стека; firewall разчита ОС

да е устойчива на атаки на ниво IP. Вместо това SecurIT е proxy сървър, който изследва данните от IP пакетите, за да се увери, че трафикът през даден порт отговаря на протокола, който работи на порта. SecurIT е силно оптимизиран proxy сървър, който използва threads и shared memory, за да намали времето, необходимо да се филтрират proxied протоколи. С това се увеличава трафика, преминаващ през firewall, като въпреки това се проверяват всички данни за съвместимост със спецификациите на конкретния протокол.

В добавка към content filtering за отделен протокол, всеки протокол може да се конфигурира да блокира определени IP адреси и Интернет domains.

SecurIT предлага proxing за следните протоколи: − FTP - стандартно FTP service proxy. − Generic SOCKS – позволява на администратира лесно да пренасочва proxied

протоколи като просто специфицира адреса и порта, на който да се изпращат TCP и UDP пакетите.

− Gopher – Proxing за text−based hypertext protocol, който предхожда World Wide Web.

− HTTP++ - разрешава основен web трафик, но позволява на администратора да блокира аплети и URLs.

− HTTP – за порт 80 proxying или за web трафик на други портове, но използвайки HTTP.

26

Page 27: FireWall

− LDAP – позволява достъп на клиенти от мрежата до directory servers exterior на firewall.

− Mail—Stores и forwards e−mail, получавани на firewall, за доставка в мрежата. − NNTP - препраща Usenet новини през firewall. − POP – осигурява канал за връзка с външни e−mail сървъри. − RPC – осигурява сигурен Remote Procedure Call през firewall. − SSL - препраща secure socket комуникации през firewall. − Telnet - Proxies command−line контрол на отдалечени компютри.

NetWall NetWall е firewall, създаден от организацията Bull и работи еднакво добре както

върху Solaris на Sun и версиите на Unix на IBM’s AIX., така и върху Windows. NetWall осигурява пълен набор от инструменти, като се започне от филтриране на пакети и се стигне до Application−level proxies за голямо разнообразие от протоколи, NAT, VPN, аутентикация, load balancing, отдалечен контрол и т.н.

Педимства − Надежност − Центализирана аутетикация − Versatile proxying

Инсталирането и конфигурирането на NetWall не е много лесно в сравнение с много други предлагани firewalls.

Главни характеристики: − Филтър на пакети (Stateful) − Network Address Translator (dynamic, static) − DMZ support − Port redirection − Transparent и reverse proxies (SOCKS (IP, IPX), HTTP, Telnet, Gopher, SMTP,

FTP, POP, IMAP, RealAudio/Video, H.323) − Сигурна аутентикация (Plain, Proprietary, Security Dynamics, Crypto Card,

S/Key, RACAL, RADIUS Server, MD/5 Challenge/Response) − VPN и VPN client software (Windows 98/NT/2000/XP) − Firewall high availability − Достъп до бази данни и известяване по e−mail

Второстепенни характеристики: − Филтриране на съдържанието(Java, Virus scanning, URL blocking) чрез

MimeSweeper и VirusWall − Графичен интерфейс − Отдалечена и централизирана администрация − Подобрения в ОС − SQL proxying

Няколко NetWall firewalls могат да се използват за балансиране на връзката помежду си и да я поддържат дори, ако някой от тях откаже. Това дава голям достъп до Интернет услугите и предпазва от denial−of−service атаки.

27

Page 28: FireWall

Управлението на firewall може да се извършва и отдалечено, като комуникацията между firewall и машината, от която се извършва управлението, е криптирана.

Сигурност IP филтърът на NetWall осигурява stateful филтриране на пакети, като следи

състоянието на потоците от данни както при TCP, така и при UDP връзките, макар че UDP не пази информация за сесията в пакетите. Филтъра може също директно да проверява част от данните в IP пакетите, което подобрява proxying на някои протоколи като HTTP, SMTP, FTP, Telnet, RPC, SQL* Net и SAP. Докато IP филтърът защитава firewall на ниво IP, application proxies осигуряват преминаването само на сигурен трафик през firewall. NetWall разполага с внушителна гама от proxies, включително:

− FTP − Generic − Gopher - − HTTP − SHTTP/SSL − LDAP − SMTP – пази и препраща e−mail, получен от firewall за доставяне в локалната

мрежа − IMAP4 – служи за връзка между mail delivery и mailbox checking през

firewall. − NNTP − POP3 − Real Audio/Video − H.323 – дава възможност за осъществяванена на видео връзка през firewall − Telnet − TN3270— TCP/IP достъп до mainframe и minicomputers.

Network Associates Gauntlet on the WebShield e−ppliance

Gauntlet работи върху машини, използващи както Windows, така и Unix; както и върху многопроцесрни машини.

Предимства − Висока скорост − Надежност − VPN − Аутентикация − Cross−platform и device packaged

Главни характеристики:

− Филтър на пакети (stateful) − Network Address Translator (динамичен, статичен) − Поддръжка на DMZ − Пренасочване на портове − Transparent и reverse Proxies

28

Page 29: FireWall

− Аутентикация (SecureID, RADIUS S/KEY, CryptoCard, ActiveCard) − VPN (IPSec/IKE accelerated) − VPN софтуер (Windows 98/NT/2000/XP, Macintosh, Unix, Linux) − Firewall high availability − Достъп до бази данни и известяване по e−mail

Филтърирането на пакети при Gauntlet - Gauntlet е комбинация от security proxy и

stateful inspection filter. При започването на нова връзка началните пакети, които служат за установяване на тази връзка, се предават през application proxy. В зависимост от security settings, зададени от администратора, останалата част от комуникацията също може да преминава през proxy.

Proxy Services Gauntlet поддържа стандарнтните интернет услуги:

− FTP − HTTP − LDAP − NNTP − POP3 − PPTP − SMTP − SNMP − SSL − Telnet

H.323 Multimedia: − NetMeeting − NetShow − RealAudio − RealVideo − VDOLive

SQL услуги: − Microsoft − Oracle − Sybase

Второстепенни характеристики:

− Филтриране на съсържанието (Java, virus scanning, URL blocking) − Откриване на сканиране и опити за spoofing, както и автоматичното им

блокиране − Графичен интерфейс − Отдалечено администриране − Централизирана администрация − Transparent ARP support − Защита от SYN flood − Anti−spoofing контрол

29

Page 30: FireWall

− Real−time protection − Content Vectoring Protocol − Конфигурация и управление, базирани на определени правила − High performance − Стабилизиране на ОС − SQL proxying

Сигурност

Gauntlet осигурява сигурност за firewall чрез набор от правила, към които могат да бъдат добавяни нови. При инсталирането на продукта по подразбиране се създават два основни набора от правила:

1. Trusted policies се разпределят на мрежовите адаптери, определени като вътрешни по време на инсталацията, и включват следните proxy services:

− FTP − H.323 − HTTP − LDAP − NetShow − NNTP − PPTP − RAP − SMTP − StreamWorks − Telnet − VDOLive

По подразбиране са забранени: − MS−SQL − POP3 − SNMP − SQL−GW − Sybase−SQL

2. Untrusted policies се разпределят на тези интерфейси, определени като външни по време на инсталирането, и поддържат следните услуги

− FTP − NNTP − POP3 − SMTP − Telnet

И забранява всички останали. SunScreen Secure Net 3.1

Всички големи информационни компании са създали свой собствен firewall софтуер и Sun не прави изключение. SunScreen работи върху Sun SPARC workstations и Intel компютри под Solaris и е проектирана да осигурява high−throughput защита за големи мрежи.

30

Page 31: FireWall

Предимства − Висока скорост − Голяма надеждност − Поддържа VPN − Аутентикация − Java базирана администрация

Недостатъци − Висока цена − Не осигурява филтриране на съдържанието

Главни характеристики:

− Филтър на пакети (stateful) − Network Address Translator (динамичен, статичен) − Подръжка на DMZ − Port redirection − Proxies (HTTP, SMTP, FTP, Telnet) − Сигурна аутентикация (Plain, SecureID, RADIUS, SKIP) − VPN (IPSec/IKE, SKIP) − VPN софтуер (Windows 98/NT/2000/XP, Macintosh, Unix, Linux) − Многифункционален firewall − Bandwidth контрол и качествени услуги − Logging и e−mail съобщения

Второстепенни характеристики:

− Откриване на сканиране и опити за spoofing, както и автоматичното им блокиране

− Графичен интрфейс − Отдалечено администриране − Централизирана администрация − Поддържане на transparent ARP − Защита срещу SYN flood − Anti−spoofing контрол − Конфигурация и управление, базирани на определени правила − High performance − Стабилизиране на ОС − Stealth

Интересна особеност на SunScreen е, че поддържа т.нар. "stealth" или "drop in". При него firewall се поставя между машини от мрежата и такива извън нея. Когато се намира в stealth mode, firewall не показва IP адресите нито на LAN, нито на WAN връзките. Вместо това насочва целия мрежов трафик на своите интерфейси и предава пакети само, ако прецени, че са подхоящи.

Един недостатък на SunScreen е, че не поддържа content filtering. SunScreen proxies проверяват дали се използва HTTP на съответния порт, но не предпазват потребителя от изтеглянето на някой вирус.

31

Page 32: FireWall

Сигурност

SunScreen стабилизира Sun SPARC или Intel workstation, работеща със Solaris, така че да може да работи като packet filter и Network Address Translator. Всички пакети се обработват от филтъра преди да бъдат предадени за ротиране или транслиране. SunScreen предлага различни опции за филтриране, включително по SYN bit, source и destination IP адресите, source и destination ports, вида на пакета и други. SunScreen не проверява данните, които се съдържат в пакетите и блокира ОС, така че един наивен администратор да не е в състояние да пусне несигурни услуги на сървъра. Поради тази причина е необходимо използването на proxy сървър, работещ на друга машина, който да проверява дали трафика, преминаващ през даден порт, отговаря на протокола, съответстващ на този порт. SunScreen оценява всеки пакет, преминаващ през мрежовите адаптори на firewall, въз основа на предварително зададени правила от Java administration console. Те се проверяват едно по едно, докато SunScreen не открие правилото, отговарящо на дадения пакет. Тъй като самите правила се проверяват в определен ред, е изключително важно да се знае точната последователност на въвеждане на всяко едно от тях.

Firewall-и за свободно използване при Unix базирани ОС:

Open source firewalls имат няколко проблема: − Слабо застъпен или липсващ logging, промяна на настройките − Няма възможност за real−time firewall управление − Слабо застъпен или липсващ графичен интерфейс − Command prompt базирана конфигурация

Тези проблеми се дължат на факта, че често тези firewalls са създадени от един човек или от малък екип от хора, а не от големи корпорации. Малките екипи често не разполагат с достатъчно време или с финансви средства, за да се спират на такива незначителни неща като улесняване на използването и усъвършенстване на механизмите за промяна на настройките и logging. Тези елементи най-често се осигуряват от допълнително създадени пакети, дело на друг разработчик. Свободният софтуер се създава за хора, които са наясно с проблемите, които трябва да се решават, и с ОС, на която работи съответния софтуер.

Linux and IPChains or IPTables

Linux е създаден като образователен проект от Linus Torvalds. Използвайки механизмите на свободния софтуер, той създава проста ОС за своя компютър и публикува своя код в Интернет. Този код заинтересувал други хора, които предложили промени и изпратили свой код, за да разширят малката ОС. Постепено Linux се превръща в сложна и стабилна ОС, конкурираща Windows и традиционните Unix ОС, като кода остава достъпен за теглене, промяна и фиксиране на проблеми в сигурността. Според защитниците на Linux, едно от големите предимства на ОС се състои в това, че веднъж открит, проблемът бързо се оправя и новият код се публикува и Интернет. Това отнема не повече от ден, което е значително по-бързо от откриването и оправянето на подобни проблеми при комерсиалните ОС. Важна добавка към ядрото на Linux осигурява филтриране на пакети и Network Address Translation в самата ОС. Първоначално, заради осигуряването на NAT, тази

32

Page 33: FireWall

система се наричала IP Masquerade. Сега тя се нарича IPChains или IPTables (в зависимост от версията, която се използва), тъй като позволява на администратора да зададе chains или таблици от правила, които трябва да се удовлетворяват от преминаващите през машината пакети. IPChains и IPTables осигурява NAT и packet filtering. Проверката на протоколите трябва да се осигури от higher−level proxies.

Главни характеристики:

− Правила за филтриране се прикачват към всеки пакет, който пристига, преминава през Linux routing stack и излиза. IPChains е stateless; IPTables е stateful. Това е и основната функционална разлика между тях.

− Proxies се осигуряват от услуги ан по- високо ниво като TIS FWTK, Apache или Squid.

− Network Address Translation (динамична или статична) се извършва за пакетите, преминаващи през routing стека, с цел да се скрият вътрешните мрежи.

− DMZs може да се осъществи както чрез филтриран достъп до защитени видими външни подмрежи, така и чрез пренасочване на виртуални публични адреси към транслирани адреси на защитени машини в мрежата.

− VPN firewall−to−firewall и firewall−to−remote client опции се осигуряват допълнително.

− Компонентите на Linux могат да се изтеглят безплатно от интернет − Пренасочване на портове − Умелото използване на IPChains или IPTables със Squid или FWTK може да

осигури transparent proxies. − Linux с FWTK осигурява reverse proxies (HTTP, SMTP, FTP и други) − Linux с пакети като PoPToP или FreeS/WAN осигурява VPN опции с широко

приложение (PPTP, IPSec и други) − Допълнителни пакети превръщат стандартната Linux syslog reporting system

за пазене на logging information в база от данни. Второстепенни характеристики:

− Работата с филтъра на пакети на Linux е сравнително бърза. Тъй като е интегриран Linux IP stack, фитърът избягва претоварването, характерно за други firewalls, работещи на потребителско ниво. Това е особено полезно при натоварени връзки локални мрежи и интернет, използващи дори Network Address Translation

− Конфигурацията от командния ред изисква по-богати познания от страна на администратора, но позволява пазенето на policies в текстови файлове и използването на scripting tools за динамично управления на policies. Някои от разпространенията на Linux осигуряват графичен интерфейс, който улеснява инсталирането и конфигурирането на софтуера.

− Отдалечено администриране, използвайки SSH или софтуер, подобен на VNC

− Определени правила при филтрирането на пакетите позволяват използването на NAT и forwarding за sockets за пренасочване на трафика за определени

33

Page 34: FireWall

услуги като HTTP, SMTP и POP, което защитава допълнително вътрешните потребители

Сигурност

Самата ОС филтрира пакетите преди да ги предаде на IP стека за обработка, което предпазва компютъра от деформирани пакети и подобни атаки на ниво IP. Linux предлага богат набор от опции за филтриране на пакети като филтриране по SYN bit, source и destination IP адреси, source и destination портове, тип на пакета, както и по повечето елементи от TCP/IP header. Network Address Translation е вградена във филтъра на пакети, което позволява използването на същите правила за определяне кои пакети да бъдат транслирани и кои не. Тъй като ОС не проврява съдържанието на пакетите, е необходимо използването на proxy сървър, който да проверява дали дадено приложение работи на определени за него порт (например HTTP заявките използват порт 80). Някои web сървъри също могат да работят като HTTP proxies и да се използват без да се налага модифицирането им при работа със store−and−forward протоколи (като SMTP и NNTP). Повечето protocol proxies изискват подобно модифициране, за да осигуряват такива услуги. В идеалния случай тези услуги могат да бъдат обработвани на машина, различна от тази, на коята се намира firewall, и да се използва траслиране на адреси, за да се пренасочва подходящия трафик през тези сървъри. Филтиращият софтуер на Linux проверява всеки пакет, преминаващ през мрежовите адаптори, съобразявайки се с набор от правила, зададени при инсталирането му. Тези правила се прилагат в определен ред, едно по едно, докато филтърът открие това, което отговаря на дадения пакет, и така се определя дали пакетът да бъде приет или не. Тъй като правилата се прилагат в определен ред, те трябва да бъдат въведени точно в този ред. При IPChains тези правила се подреждат във верига. IPChains започва с веригите INPUT, FORWARD и OUTPUT, като към тях могат де се добавят допълнителни вериги. Тази особеност улеснява разбирането на логиката на работа на firewall и спомага за усилването на сигурността. IPTables работи по подобен начин, но осигурява stateful inspection.

The Trusted Information Systems Firewall Toolkit (TIS FWTK) TIS FWTK може да бъде определен като прадядото на всички open-source firewalls.

Версии могат да бъдат изтеглени за Linux, NetBSD, Solaris, както и за повечето Unix базирани ОС. FWTK е създаден от TIS за Defense Advanced Research Projects Agency (DARPA). След изпълняването на всичките си задъжения към DARPA (включително обявявайки кода на FWTK за публичен), TIS доразвиват firewall и създават комерсиална версия под името Gauntlet Firewall. В момента FWTK се поддържа от Internet consortium.

Главни характеристики:

− Допълнителни proxy елементи осигуряват фитриране на съдържанието за отделните протоколи

− Централизиран мрежов login − Контролиран достъп до мрежовите ресурси за машини, ползващи Unix

Второстепенни характеристики:

− Конфигурацията, базирана на команди, зададени от командния ред, изисква повече знания от страна на администратора, но дава възможност за пазене на

34

Page 35: FireWall

policies в текстови файлове и използването на инструменти за динамично им управление.

− Отдалечено администриране, използвайки secure shell (SSH) или web interface, който позволява управление на firewall от друг компютър в локалната мрежа.

− Транслирането на адреси се осъществява чрез използването на FWTK generic TCP plug−board.

Сигурност FWTK не филтрира пакетите преди да ги предаде на IP стека за обработка, затова е

необходимо използването на някакъв друг пакет, който да проверява за променени пакети и други атаки на ниво IP. FWTK е proxy сървър. Той проверява съдържанието на IP пакетите и следи дали даден порт се използва само по предназначение (например, че на порт 80 се обработват само HTTP заявки). FWTK проверява данните, получени от мрежовите адаптери, използвайки набор от правила, зададени в net−perm rule таблица. Правилата се определят в зависимост от порта, на който са изпратени данните. Достъпът се разрешава в зависимост от source и destination адреса на пакета..

FreeBSD and Drawbridge Освен Linux, друга широко използвана open-source ОС е FreeBSD. Drawbridge е филтър на пакети, създаден върху FreeBSD от Texas A&M University (TAMU). За разлика от IPChains, Drawbridge не е част от ОС, а потребителска програма, която има директен контрол върху мрежовите адаптери на компютъра. Подобно на останалите филтри и Drawbridge използва списък от правила, определящи преминаването на пакетите. Тъй като е създаден в университет, където се предполага, че всички компютри, като едно цяло, са част от Интернет, Drawbridge не предлага NAT. Различното в този софтуер е, че може да докладва и да реагира на подозрително действие, използвайки компоненти на наречени tcplogger, udplogger, netwatch и netstat. Тъй като целта на университетите е да осигуряват достъп до мрежови ресурси, а не да го ограничават, тази опция се превръща в значително предимство. Администраторите просто трябва да наблюдават състоянието на мрежата и да са готови да реагират в случай на опасност.

Главни характеристики: − Правила за филтриране се прилагат на всеки пакет преди да бъде предаден

на FreeBSD network stack − Content filters се осигуряват от услуги на по-високо ниво като Apache и

Jigsaw. − VPN firewall−to−firewall и firewall−to−remote клиент се предлагат като

допълнителни − Всички компоненти на FreeBSD могат да се изтеглят напълно безплатно от

Интернет − Засичането и отговарянето на заплахи става чрез tcplogger, udplogger,

netwatch и Netstat.

Второстепенни характеристики: − Работата FreeBSD с Drawbridge е сравнително бърза

35

Page 36: FireWall

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

повече знания от страна на администратора, но дава възможност за пазене на policies в текстови файлове и използването на инструменти за динамично им управление.

− Отдалечено администриране, използвайки secure shell (SSH) или web interface, който позволява управление на firewall от друг компютър в локалната мрежа.

Сигурност Drawbridge филтрира пакетите преди да ги предаде на IP стека за обработка, което

предпазва компютъра от деформирани пакети и подобни атаки на ниво IP. Drawbridge предлага богат набор от опции за филтриране на пакети като филтриране по SYN bit, source и destination IP адреси, source и destination портове, тип на пакета, както и много други. Drawbridge не инспектира данните в получените пакети, което поражда необходимостта от proxy сървър, който да проверява дали даден протокол (като HTTP например) работи на определения за него порт. Някои web сървъри също могат да работят като HTTP proxies и да се използват без да се налага модифицирането им при работа със store−and−forward протколи (като SMTP и NNTP). Повечето protocol proxies изискват подобно модифициране, за да осигуряват подобни услуги. В идеалния случай тези услуги могат да бъдат обработвани на машина, различна от тази, на коята се намира firewall, и да се използва траслиране на адреси, за да се пренасочва подходящия трафик през тези сървъри.

Drawbridge преценява валидността на всеки пакет, преминаващ през мрежовите адаптери, в зависимост от набор от правила, които пази в собсвени бази от данни в RAM паметта. Както и при предишните firewalls, редът на въвеждането на правилата е от голямо значение, тъй като се прилагат в определен ред.

Тcplogger, udplogger, netwatch и netstat сканират всички пакети, преминаващи през машината, на която работят. Използвайки сложни алгоритми, те откриват подозрителни дейности като: опити за root logon от потребители извън мрежата; прекомерен FTP трафик, идващ от машина, която не би трябвало да поддържа FTP сървър; и други.

OpenBSD and Ipf OpenBSD е друга версия на BSD, ориентирана до голяма степен към сигурността.

Ipf for OpenBSD осигурява същите функции като по-горе споменатите IPChains или IPTables DrawBridge. За да се осигури application proxy, е необходимо инсталирането на други услуги като Squid или TIS FWTK.

Главни характеристики:

− Stateless packet filter − Proxies се осигуряват от услуги на по-високо ниво като TIS FWTK, Apache,

или Squid. − Network Address Translation (динамичен или статичен)

36

Page 37: FireWall

− DMZs може да се осигури или чрез филтриран достъп до видими отвън частни мрежи, или чрез пренасочване на виртуални публични адреси до машини с транслирани адреси

− VPN firewall−to−firewall и firewall−to−remote client се осигурява чрез вградена IPSec функционалност

− Port redirection − Умелото използване на ipf със Squid или FWTK може да осигури transparent

proxies. − OpenBSD с FWTK осигурява reverse proxies (HTTP, SMTP, FTP) − Допълнителни пакети превръщат стандартната OpenBSD syslog reporting

system за пазене на logging information в база от данни Второстепенни характеристики:

− Работата с филтъра на пакети на OpenBSD е сравнително бърза. Тъй като е интегриран OpenBSD IP stack, филтърът избягва претоварването, характерно за други firewalls, работещи на потребителско ниво. Това е особено полезно при натоварени връзки локални мрежи и интернет, използващи дори Network Address Translation

− Конфигурацията от командния ред изисква по-богати познания от страна на администратора, но позволява пазенето на policies в текстови файлове и използването на scripting tools за динамично управления на policies

− Отдалечено администриране, използвайки SSH или софтуер, подобен на VNC

− Определени правила при фитрирането на пакетите позволяват използването на NAT и forwarding за sockets за пренасочване на трафика за определени услуги като HTTP, SMTP и POP, което защитава допълнително вътрешните потребители

Сигурност

OpenBSD има един от най-добрите IP−level packet filters, които могат да бъдат намерени. Наред със защитата от типичните атаки като source routing, променени пакети и т.н., той пази и от по-трудни за откриване атаки, като connection hijacking, чрез познаването на TCP sequence number. Ipf също предлага богат набор от опции за филтриране на пакети като филтриране по SYN bit, source и destination IP адреси, source и destination портове, тип на пакета, както и по повечето елементи от TCP/IP header. Network Address Translation е вградена във филтъра на пакети, което позволява използването на същите правила за определяне кои пакети да бъдат транслирани и кои не.

OpenBSD не инспектира данните в получените пакети, което поражда необходимостта от proxy сървър, който да проверява дали даден протокол (като HTTP например) работи на определения за него порт. Някои web сървъри също могат да работят като HTTP proxies и да се използват, без да се налага модифицирането им при работа със store−and−forward протоколи (като SMTP и NNTP). Повечето protocol proxies изискват подобно модифициране, за да осигуряват подобни услуги. В идеалния случай тези услуги могат да бъдат обработвани на машина, различна от тази, на коята се намира firewall, и да

37

Page 38: FireWall

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

OpenBSD filtering software преценява валидността на всеки пакет, преминаващ през мрежовите адаптери, в зависимост от набор от правила, които пази в собсвени бази от данни в RAM паметта. Както и при предишните firewalls, редът на въвеждането на правилата е от голямо значение, тъй като се прилагат в определен ред.

Хардуерни Firewall-и: За разлика от дотук разгледаните софтуерни firewalls, хардуерните firewalls са по-лесни за инсталиране и конфигуриране. Те разполагат със собсвен софтуер и единственото, което се очаква от потребителя, е да зададе валиден IP адрес. За конфигурирането може да се използва или подходяща Windows апликация, или web interface. Хардуерните firewalls работят на всички видове компютри, но често не се използват за ОС стандартните разпространения на Unix или Windows NT, което в повечето случаи само увеличава нивото на сигурност. Разбира се, те имат и своите недостатъци. Повечето устройства изискват специални adapter drivers и работят със специфични модели. „Кръпки” за хардуерните firewalls излизат рядко и, ако се появи някакъв дефект, обикновено такива се появяват едва в следващата версия. Често тези устройства работят на непознати за голяма част от потребителите ОС. Към недостатъците може да се прибави и липсата на пълен набор от характеристики. Устройствата са базирани или на generic SOCKS proxies, или на stateful inspection, като не се поддържат и двете. Нека се спрем на някои от по-добрите устройства от този тип.

SonicWALL SonicWALL е един от най-лесните за използване firewalls. Единственото, което се изисква, е да се сложи устройството и да се окаже на web browser за конфигурация. Тя също не е много сложна – просто трябва да се окаже адреса на интерфейса и кои портове са разрешени. Ако се изисква поддържане на VPN, трябва да се споделят secret IKE keys и да се определят разрешените потребители.

Предимства

− Няма специални изисквания към хардуера или софтуера − Стабилна stateful инспекция − Проста конфигурация − Много надеждна − Съвместима с VPN

Недостатъци − Не осигурява истинско Application−level proxying

Главни характеристики:

− Филтър на пакети(stateful) − Network Address Translator (dynamic, static) − DMZ support − Port redirection

38

Page 39: FireWall

− Сигурна аутентикация (IPSec/IKE, certificates, RADIUS Server) − VPN (IPSec/IKE) − VPN Client Software (Windows 98/NT/2000/XP) − Firewall high availability − Logging включва syslog и известяване по e−mail

Второстепенни характеристики:

− Scan detection, spoofing detection и автоматично блокиране − Ограничен HTTP content filtering − DHCP − Графичен интерфейс − Отдалечена администрация − Защита от SYN−flood − Anti−spoofing контрол − High performance

Тъй като SonicWALL има web interface, не е необходимо инсталирането на специален софтуер, за да бъде конфигуриран. Едиственото, което се изискава, е web browser, който поддържа Java.

Сигурност SonicWALL е изцяло network layer firewall. То не осигурява никакво application layer proxying или content filtering. SonicWALL има прост HTTP филтър, който включва филтриране на Java, ActiveX и cookies, но само толкова. SonicWALL осигурява първокласен филтър на пакети, блокиране и пренасочване на портове и VPN, които са лесни за конфигуриране.

WatchGuard Firebox 1000 WatchGuard Firebox 1000 може да се сравнява със SonicWALL по цена,

възможности и лесна употреба. Същевременно той може да се определи като едно от най-стабилните устройства от този тип

Предимства − Няма изисквания към хардуера или софтуера − Strong Application−layer inspection − Strongest device−based firewall − Изключително надеждна

Недостатъци

− Може да се използва само от клиенти на Windows WatchGuard Firebox практически няма големи известни дефекти.

Главни характеристики:

− Филтър на пакети (stateful) − Network Address Translator (dynamic, static)

39

Page 40: FireWall

− DMZ support − Port redirection − Proxies (DCE−RPC, FTP, H323, HTTP, RealNetworks, RTSP, SMTP,

Stream−Works, VDOLive) − Secure authentication (Proprietary, Windows NT, RADIUS, SecurID и

CRYPTOCard) − VPN (proprietary, DES, 3DES, IPSec/IKE, PPTP) − VPN client software (Windows 98/NT/2000/XP, Unix, Linux) − Bandwidth control и quality of service − Logging и e−mail notification Най-впечатляващият аспект на Firebox 1000 е вградената поддръжка на proxy -

детайл, който не се поддържа от повечето device−based firewalls. WatchGuard Firebox предлага първокласнен VPN support, network address translation, packet filtering и DMZ.

Второстепенни характеристики:

− Прозрачна мрежова drop−in конфигурация − Content filtering (Java, virus scanning, URL blocking) − Scan detection, spoofing detection и автоматичното им блокиране − DHCP − Графичен интерфейс − Отдалечено администриране − Централизирана администрация − Защита от SYN−flood − Anti−spoofing контрол − Real−time контрол и известяване − Policy−based конфигурация и управление − Изключително изпълнение

Сигурност

Firebox 1000 осигурява най-високото ниво на сигурност на тази цена, нищо че OpenBSD предоставя по-добро замаскиране на TCP sequence numbers или че Gauntlet осигурява по-стабилно proxy. Тъй като Firebox все пак е базиран на Linux, той притежава доста по-случаен TCP sequence number generator от повечето устройства. Приложението за Windows има преимуществото, че чрез него може да се извършва real−time monitoring на състоянието на firewall.

GNAT Box

GNAT Box stateful packet filter и Network Address Translator работят на своя собствена ОС, която се зарежда от дискета. Firewall включва още SMTP proxy и DNS server и осигурява защита от IP spoofing и най-разпространените denial−of−service атаки. GNAT Box е firewall, предназначен конкретно за BSD. Предимства

− Работи върху слаб хардуер − Няма стандартните дупки в сигурността, характерни за повечето ОС − Бърз

40

Page 41: FireWall

− Не много скъп Недостатъци

− Няма аутентикация за потребителите − Няма content scanning или допълнителни proxies

Изисквания към системата:

− 386 или higher Intel−compatible microprocessor − 8MB RAM, 16MB препоръчителни за e−mail proxy, повече от 32MB не са

необходими − Floppy disk drive − Два мрежови адаптери − Display adapter − Printer port

Главни характеристики:

− Stateful филтър − Network Address Translator − DMZ support − Port redirection − VPN (AES, DES, 3DES, IPSec/IKE) − VPN client software (PPTP, IPSec, SSH) − Firewall high availability (1000GB) − Logging и e−mail notification − E−mail и HTTP Proxy

Stateful филтърът на GNAT Box е малко по-усъвършенстван. Той може да създаде тъй наречените virtual cracks - термин, използван от GNAT Box за описание на тунели, създадени за return channels за протоколи като FTP и real−time multimedia протоколи.

Второстепенни характеристики:

− Изисква dialing на PPP connections Ако е конфигуриран да използва PPP връзка като външен интефейс, GNAT Box

автоматично се свързва с интерфейса при поискване на данни от Интернет от вътрешни потребители. PPP интерфейсът може да се настрои да работи в dedicated (dial on boot) или manual−enable (при установяване на връзка от администратора) режим.

Сигурност

GNAT Box е единственият софтуъер, работещ на firewall platform. Той може да се счита за по-стабилен от всеки друг софтуер, работещ на стандартна ОС, тъй като не може да бъде директно използван от хакери. За съжаление същата машина не може да се използва и за поддържане на mail, web или други подобни услуги. GNAT Box превръща машината, която е сложена във firewall, в приспособление и по този начин постига високо равнище на наследена сигурност.

IBM Firewall за AS/400

41

Page 42: FireWall

Този firewall е част от семейството firewalls на IBM, разработвани в продължение на вече 15 години. IBM са разработили firewalls за AIX/6000 върху RS/6000 microcomputers, Windows NT върху Intel microcomputers, OS/400 върху AS/400 minicomputers и други.

Предимства

− Работи върху платформите на IBM − Стабилизира ОС − Stateless packet filter

Недостатъци − Скъп − Не добре интегриран − Работи върху допълнително сложен процесор − Няма content filters или strong security proxies − Не поддържа DMZ

AS/400 firewall работи на интегриран PC server, поставен на AS/400 компютъра. Това разделяне на системата позволява да се забрани достъпът до приложения, работещи на машината, в случай, че firewall е компрометиран. Софтуерът се стартира от read−only hard disk drive, т.е. не може да се модифицира след като веднъж е инсталиран.

IBM Firewall за AS/400 изисква: − OS/400 version 4 release 1 − Устройства, осигуряващи TCP/IP връзка за AS/400 − Integration services за FSIOP − RISC AS/400 с интегриран PC server

PC трябва да разполага с: − 32MB RAM (64 препоръчителни) − 486 или higher microprocessor

Главни характеристики:

− Филтър на пакети − Network Address Translator − Proxies за HTTP, SMTP − SOCKS proxy

Филтърът на пакети, с който разполага AS/400 firewall, е прост и stateless, подобен на филтъра на IPChains. По подразбиране firewall не е настроен да предава IP пакети. Вместо това връзките се осъщетвяват чрез circuit level gateway (SOCKS proxy), работещ на Application layer. Това означава, че, ако клиентският софтуер не е съвместим с това proxy, той не може да бъде използван. Security proxy services се осигуряват за HTTP и SMTP. Всички останали TCP services трябва да са съвместими със SOCKS.

Второстепенни характеристики: − IBM Firewall за AS/400 се инсталира като стандартно AS/400 приложение

Сигурност

IBM Firewall разчита предимно на своето SOCKS proxy за осигуряване на допълнителна сигурност. Филтърът на пакети е stateless и подходящ предимно за защита

42

Page 43: FireWall

от denial−of−service атаки. Network Address Translation се извършва чрез механизмите на SOCKS. Истинско proxing се осъществява само за HTTP и SMTP. В заключение, този firewall e малко остарял и изисква специален(и доста скъп) хардуер и винаги може да се постигне по-добра сигурност на по-ниска цена.

След като се запознaхме с голям набор от firewall-и, нека да дадем малко информация с практическа насоченост. Тъй като повечето firewall-и за Windows имат лесен за работа и често приятен интерфейс, а и самата ОС е доста разпространена, ще се спрем на конфигуринарето на firewall-и под не толкова познати ОС.!!!!!!!!!!!!!!

Конфигуриране на IPtables за Linux Като начало трябва да се добави поддръжката на firewall-а в ядрото на ОС. Това

става от (menuconfig) → Networking Support→ [Network firewalls, TCP/IPNetworking, IP: firewalling, IP: firewall packet logging] → Network packetfiltering → IP: Netfilter configuration.

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

-A верига Добавя едно или повече правилa към края на указаната верига. Ако е подадено име

на source или destination host, което съответства на повече от един IP адрес, правилото ще бъде добавено за всеки адрес.

-I верига номер_на_правило Вмъква едно или повече правила в началото на указаната верига. Ако е подадено

име на source или destination host, което съответства на повече от един IP адрес, правилото ще бъде добавено за всеки адрес.

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

спецификацията на правилото. -D верига номер_на_правило Изтрива правилото намиращо се на позиция номер-на-правило в указаната верига.

Позицията на правилото започва от 1 за първото правило на веригата. -R верига номер_на_правило Замества правилото, намиращо се на позиция номер-на-правило в дадената верига, с

дефинираната спецификация на правило. -C верига Проверява дали пакетът, описан от зададеното правило, съответства на

определената верига. Тази команда ще върне съобщение, описващо как веригата обработва пакета. Много е полезно при тестването на защитната стена.

-L [верига]

43

Page 44: FireWall

Генерира списък на правилата в посочената верига (или във всички вериги, ако не е посочена верига).

-F [верига] Изчиства правилата в посочената верига (или във всички вериги, ако не е посочена

такава). -Z [верига] Нулира броячите на дейтаграми и байтове за всички правила в посочената верига

(или във всички вериги, ако не е посочена такава). -N [верига] Създава нова верига с посоченото име. Верига със същото име не трябва да

съществува. Така се създават потребителско-дефинирани вериги. -X [верига] Изтрива посочената потребителска верига (или всички потребителски вериги, ако

не е посочена такава). За да бъде успешна тази команда, не трябва да има препратки към посочените вериги, в която и да е друга верига от правилата.

-P верига линия-на-поведение Задава подразбираща се линия-на-поведение за посочената верика. Валидните

линии на поведение за един firewall са ACCEPT, DROP, QUEUE и RETURN. ACCEPT позволява на пакета да премине, при DROP той се игнорира, при QUEUE се изпраща в потребителското пространство за по - нататъшна обработка, а при RETURN кодът се връща към веригата от firewall-a, който е извикал веригата, съдържаща това правило. Обработката продължава от правилото, следващо извикващото правило.

Параметри за задаване на правила Има множество параметри на IPtables, които съставят спецификацията на правило.

Където е необходима спецификация на правило, трябва да се подаде всеки един от тези параметри. В противен случай се възприемат техните стойности по подразбиране.

-p [!]протокол Определя протокола на пакета, който ще съответства на това правило. Валидните

имена за протоколи са TCP, UDP, ICMP или число, ако се знае номерът на протокола (cat /etc/protocols). Ако се използва знак !, правилото се обръща и пакета ще съответства на всеки протокол, различен от посочения. Ако този параметър не е подаден, по подразбиране се възприемат всички протоколи.

-s [!]адрес[/маска] Определя изходния адрес на пакета, който съответства на това правило. Адресът

може да бъде подаден като име на host, име на мрежа или IP адрес. Маската не е задължителна и може да се подаде по 2 начина - 255.255.255.0 или с /24 вариант-а.

-d [!]адрес[/маска] Задава адрес и порт на получателя на пакета, който съответства на това правило.

Кодирането на този параметър е същото както при -s. -j цел Задава какво действие трябва да се предприеме при откриване на съответствие с

това правило. Валидни цели са ACCEPT, DROP, QUEUE и RETURN. Можете да посочите името на потребителски дефинирана верига, където да продължи обработката. Можете да зададете името на целта чрез разширение. Ако този параметър е пропуснат, при съответствие на пакета не се предприемат никакви действия, освен да се актуализират броячите на пакетите и байтове за това правило.

44

Page 45: FireWall

-i [!]име-на-интерфейс Задава интерфейса, на който е получен пакетът. Ако името на интерфейса завършва

с + , тогава всеки интерфейс с подадения низ ще действа (пример: -i ! eth+ -- всички интерфейси освен мрежовите устройства)

-o [!]име-на-интерфейс Задава интерфейса, на който ще бъде предаден пакетът. Този аргумент се кодира по

същия начин както -i.

Опции -v Оказва на IPables да генерира по подробен изход. -n Оказва на IPtables да показва IP адреса и портовете като номера, без да се опитва

да ги свърже с техните съответстващи имена. -x Оказва всички числа в изхода на IPtables да бъдат разширени до тяхната пълна

стойност без закръгляване. -line-numbers При изброяване на правилата оказва да бъдат показвани номерата на

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

възможностите, предлагани от 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.

-tcp-flags SYN,RST,ACK SYN Оказва че правилото съответства само на пакети с вдигнат SYN бит и свалени

битове ACK и FIN. Пакетите с тези опции се използват за отваряне на TCP връзки, затова тази възможност може да бъде използвана за управление на заявките за връзки.

UDP разширения: използвани с -m udp -p udp: -sport [!] [порт[:порт]] Аналогично на разширението при TCP -dport [!] [порт[:порт]] Аналогично на разширението при TCP

45

Page 46: FireWall

ICMP разширения: използвани с -m icmp -p icmp: -icmp-type [!] име-на-тип Определя типа на ICMP съобщението, на което трябва да съотетства това правило.

Типът може да бъде зададен чрез номер или чрез име. Някои валидни имена са: echo-request, echo-reply, sourcequench, time-exceeded, destination-unreachable, network-unreachable, host-unreachable, protocolunreachable.

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"

46

Page 47: FireWall

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 в зависимост от конкретните нужди.. Този скрипт може да се промени по желание

47

Page 48: FireWall

Пример за изграждане на защитна стена под OpenBSD В този пример филтърът на пакети работи на OpenBSD система като firewall и NAT

gateway за малка мрежа вкъщи или в малък офис. Необходимо е също да се предостави ограничен достъп до този 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}" Първите два реда задават мрежовите интерфейси, на които ще се реализира

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

Параметри Следните два параметъра дефинират отговора по подразбиране на block правилата

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

set block-policy return set loginterface $ext_if Филтриране Няма причина да не използваме препоръчителното пречистване на целия входящ

трафик, затова ето едно редово правило за това: scrub in all NAT За да реализираме NAT за цялата вътрешна мрежа, се използва nat правило: nat on $ext_if from $int_if:network to any -> ($ext_if) Поради това, че IP адресът на външния интерфейс се получава динамично, около

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

вътрешната мрежа да се свързват безпроблемно с FTP сървърите в Интернет. rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021 Това правило обхваща само връзки към порт 21. Ако потребителите редовно се

48

Page 49: FireWall

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

Правила за филтриране Нека първо да започнем със забраната по подразбиране: − block all На този етап нищо не преминава през firewall-а, дори от вътрешната мрежа.

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

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

− pass quick on lo0 all Адресите ще бъдат блокирани от навлизане или напускане на външния интерфейс -

пакети от/за тези адреси не би трябвало никога да се появяват в Интернет. Филтрирането им ще гарантира, че router-ът няма да "изтърве" такива адреси от вътрешната мрежа, а също и няма да пропусне такива пакети отвън, насочени за някои от вътрешните адреси.

− block drop in quick on $ext_if from $priv_nets to any − block drop out quick on $ext_if from any to $priv_nets lock drop се използва, за да окаже на филтъра да не отговаря с TCP RST или ICMP

Unreachable пакети. Понеже такива адреси по принцип не съществуват извън вътрешната мрежа ( в Интернет) няма смисъл да се връща отговор към тях. Параметърът quick се използва да окаже на филтъра да прекрати обхождането на оставащите правила за филтриране, ако даден пакет отговаря на зададените по-горе правила за 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-ът е също и

49

Page 50: 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 редът, то 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

50

Page 51: FireWall

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 pass out on $ext_if proto tcp all modulate state flags S/SA pass out on $ext_if proto { udp, icmp } all keep state□

Различни атаки и начини за защита Ще се запознаем с някои от по-известните начини, по които хакерите откриват,

идентифицират и атакуват дадена система. Ако се знаят начините, по които атаките работят, firewall-а може да се конфигурира, така че да може да се предпази системата. Ще разделим атаките на следните типове:

Denial−of−service атаки Експлоатационни атаки Атаки, крадящи информация Дезинформационни атаки

Denial−of−service

Тези атаки имат за цел да забият компютъра на „жертвата” като така не му позволяват да използва дадена услуга. Те са едни от най-лесно осъществимите и затова са широко разпространени.

Ping of Death Създава се злонамерен ICMP echo request пакет, в който указаният размер на пакета

надвишава възможния максимум. Понеже индикаторът за размера е 16 бита, то максималният размер може да бъде указан до 65535 байта. Всъщност истинският лимит е около 65500 байта, като се има предвид хедъра на пакета. И така пакет, който твърди, че е по-голям от възможния максимум, прави проблеми. В обичайната TCP/IP имплементация, когато се прочете heather-а, се разчита на указания размер, за да се създае буфер за съдържанието. Когато указаният от heather-а размер надхвърля максимумът от 64KB, указан в TCP/IP спецификацията, системата може да се срине заради грешки с разпределението на паметта.

Всички стандартни TCP/IP имплементации са подсилени срещу тази атака в този й вид и затова тя се счита за остаряла и без бъдеще.

Teardrop Тази атака използва някои потенциални слабости в TCP/IP имплементациите, които

вярват на информацията в хедърите на IP фрагментите. IP фрагментите съдържат полета, които показват каква част от оригиналните пакети се съдържа в тях. Някои имплементации ще се „счупят”, когато са указани застъпващи се фрагменти.

Защитата е инсталиране на последните patches, service packs и hotfixes за дадената операционна система и конфигуриране на firewall-ите, така че да съединяват фрагментите, вместо да ги пропускат на части.

51

Page 52: FireWall

UDP Floods Като създава UDP връзка между Chargen услугата на един host, имаща обратен

адрес на host с включена Echo услуга, хакерът може да създаде безсмислен поток от информация между двамата. Създаването на достатъчно такива потоци може да доведе до Denial−of−service.

Защитата е да се деактивират TCP/IP услугите, които не са необходими, и да се конфигурират рутърите да не пропускат UDP заявки от интернет към тези услуги.

SYN Floods При осъществяване на TCP връзка клиентът, който иска някаква услуга от сървъра,

му изпраща SYN съобщение. Сървърът му отговаря с SYN−ACK съобщение и след това клиентът изпраща ACK съобщение. Това е така нареченият 3-way-handshake и след него започва преносът на данни между двамата. Когато сървърът получи началното SYN съобщение, обикновенно създава нова нишка, която да обработва връзката с този клиент. Създаването на тази нишка изисква процесорно време и заделя определено количество памет. Когато TCP сесията приключи, заделената памет се освобождава. Следователно количеството памет и капацитетът на процесора са определящи за броя на сесиите, които даден сървър може да поддържа. SYN Floods е атака, която изпраща множество SYN съобщения към атакувания сървър, но след това не изпраща ACK съобщения. Така се създават фалшиви връзки, които заемат ресурсите на сървъра. При някои имплементации на TCP/IP стека е възможно изчакването на ACK съобщения само за ограничен брой връзки, защото има ограничен буфер памет за осъществяване на връзки. Когато буферът се запълни, сървърът спира да отговаря на бъдещи опити за връзка към него. При имплементации без това ограничение ефектът на SYN Floods е подобен. Тъй като сървърът не може да различава фалшивите опити за връзка от истинските, той заделя процесорни ресурси и памет за всички. Чрез наводняване (flooding) на сървъра с голям брой заявки, неговият капацитет може да бъде запълнен и така да се направи невъзможно осъществяването на повече връзки.

Защитата срещу тази атака е добра firewall, която разпознава характеристиките на атаката – множество идентични опити за връзка, идващи от един и същ IP адрес. Firewall-ът трябва да филтрира следващите опити за връзка от същия host и така да предотврати SYN Floods атаката. Все пак източникът на атаката не очаква отговор, затова нищо не му пречи да използва произволно генерирани IP адреси в полето на изпращача. Така атаката не може да бъде различена от обикновен засилен трафик и е възможно да премине през филтрирането.

Land Attack Тази атака е разновидност на предишната. Изпраща се SYN пакет на сървъра като в

source и destination адресите на пакета стои IP адреса на самият сървър. След като сървърът изпрати SYN−ACK и съответно ACK съобщенията, се създава празна връзка, която продължава, докато операционната система не я прекрати заради неактивност. Различните ОС реагират различно на тази атака - Windows NT става изключително бавен за около 5 мин., множество UNIX имплемаентации се сриват.

Защитата е да се инсталират patches, hotfixes срещу атаката или последните service packs. firewall-ите трябва да се конфигурират да не допускат пакети с вътрешен source

52

Page 53: FireWall

адрес, които идват от външен интерфейс. Следните адреси са невалидни в интернет и трябва да бъдат филтрирани:

− 10 domain − 127 domain − 192.168 domain − 172.16 through 172.31 domain

В допълнение трябва да се филтрира и собственият IP адрес.

Smurf Attack Обикновената Smurf атака наводнява жертвата с ICMP echo request (ping) пакети,

които имат за reply адрес broadcast адреса на мрежата на атакувания. Това кара всики в мрежата да отговарят на тази заявка и да генерират огромен трафик.

По-усложнена Smurf атака е подобна на горната, но с разликата, че source адресът на echo заявката е на жертвата – трета страна, която ще получи всичките отговори на заявката от всичките host-ове на мрежата. Тази атака е полезна за хакерите, защото могат да използват относително бавна връзка (например модем), за да предизвикат лавина от ping трафик, изпратен до произволно място в интернет. Така хакер с по-слаба връзка от жертвата си, може да я наводни като за целта използва високоскоростна чужда мрежа.

За да не се допуска хакери да използват дадена мрежа, за да атакуват трети лица, трябва да се изключи broadcast addressing feature на външния рутър или firewall. За да не се става жертва на Smurf атака, трябва да се конфигурира firewall-а да не допуска ICMP ping съобщения. Fraggle Attack

Това е проста модификация на Smurf атаката, която използва UDP вместо ICMP. Това позволява да се преминава през стени, които филтрират само ICMP. Защитата е да се конфигурира стената да филтрира и UDP.

Malformed Message Attacks Много услуги при различните операционни системи ще се „счупят”, ако получат

„лоши” съобщения, защото не проверяват за грешки в съобщенията преди да ги изпълнят. Всички операционни системи са податливи на множество проблеми, свързани със злонамерени съобщения. Например:

− E−mail буферът се препълва при получаване на „лоши” E−mail съобщения − Web услугите могат да бъдат „пробити” при използване на извънредно дълги

URL. − RPC услугите могат да бъдат „пробити” при предаване на произволна

информация към тях. Единствената защита срещу такъв тип атаки е да се следи за последните открити уязвимости и да се инсталират patches и hotfixes за тях.

53

Page 54: FireWall

Експлоатационни атаки Това са тези атаки, които се опитват да вземат директен контрол върху атакуваната машина.

TCP/IP Connection Hijacking Атаката се основава на неслучайното генериране на sequence номера при TCP

протокола и възможността да се познае този номер. TCP потоците използват генерирани псевдо-случайни sequence номера при доставяне на TCP пакети, което гарантира, че тези пакети ще пристигнат в правилен ред. Ако хакер може да уцели следващия валиден sequence номер, той може да вмъкне свои пакети, които ще бъдат получени като че ли са редовни. А пък пакетите от оригиналния изпращач ще бъдат помислени за фалшиви и няма да бъдат допуснати. Проблемът за атакуващия е в познаването на следващия валиден номер. Трудността зависи изцяло от качеството на алгоритъма, генериращ псевдо-случайни числа, използван от компютъра, за да получава sequence номерата за TCP стека. Този алгоритъм трябва да разчита на някакъв външен (за машината) източник на „случайност”. С течение на времето са използвани различни източници като всеки е имал своите слабости. Проблемът е, че за генерирането се използва алгоритъм. Независимо колко случайни изглеждат числата, все пак може да се открие някакво „пристрастие” към определени последователности. Така предвиждането на точния следващ sequence номер е изключително трудно, но предвиждането на голямо множество от числа, от които едно е търсеното, е относително лесно. И ако единственото, което прави атакуваният е просто да не допуска пакетите с грешните sequence номера, то атакуващият може да изпрати голямо количество проби и е нужно само една да е вярната, за да се открадне потока.

Защитата срещу тази атака е използването на socket redirector и операционна система, която е неуязвима срещу познаване на sequence номерата (например OpenBSD 2.9 или Linux). Socket redirector-ите получават TCP потока и го възстановяват. Те са generic proxies и работят с всички протоколи, които могат да бъдат NAT-вани.

Познаване на пароли Повечето услуги са защитени с комбинация от потребителско име и парола. Когато

хакер иска да се възползва от дадена услуга на атакуваната машина, той трябва да даде валидно потребителско име и парола, за да получи достъп. Също така правилната парола може да осигури контрол върху атакуваната машина. Съществуват програми за автоматично познаване на пароли, които използват списъци с често срещани пароли, имена и думи от речника, за да познаят важни имена като например паролата на root user при Unix системите или Administrator account при NT системите. Този софтуер обикновено взема списъка с имената и списъка с паролите и пробва всяко от имената с всяка от паролите. Някои хакери използват обновяващи се "common password" списъци, за да направят атаките си по-бързи. Тези списъци произлизат от статистически анализ над открадната информация за акаунти. С комбинация от списъка на откраднатите пароли и анализ върху честотата им на срещане, хакерите създават тези списъци. Това означава, че ако някой използва акаунт с една от тези често срещани пароли, то той може много бързо да бъде „хакнат”.

Естествено защитата срещу тази атака е използването на труднопознаваеми пароли. Не трябва да се използват думи, присъстващи в речника – може да се използва например

54

Page 55: FireWall

комбинация от думи и пунктуационни знаци. Също така трябва да се подсигурят уязвими услуги ( NFS ,Telnet, NetBIOS) от публично излагане.

Троянски коне Троянските коне са програми,които са инсталирани тайно на атакуваната машина,

директно от хакер, от компютърен вирус или червей, или от нищо не подозиращ потребител. Веднъж инсталирани те или изпращат информация на хакера, или дори му дават директен достъп до компютъра на жертвата. Най-полезните видове троянски коне са наречени „backdoors”. Тези програми осигуряват механизъм, по който хакерът получава директен контрол върху машината. Такива са например програмите NetBus, BackOrifice, и BO2K. Идеалните backdoors са малки, бързо инсталиращи се и работят прозрачно. Терминът „троянски кон” не се отнася за специален тип софтуер, а се отнася за начина, по който този софтуер се използва – не защо е създаден, а как се използва. Саморазпространяващите се троянски коне се наричат „червеи”.

За защита от троянски коне: не трябва да се отварят изпълними файлове, прикрепени към e-mail; не трябва да се download-ва несигурен софтуер; трябва да се използват софтуер, сканиращ мрежата за такива; трябва да се използват proxy филтри, които блокират непознати протоколи.

Buffer Overruns Buffer Overruns използва факта, че повечето програми заделят блокове памет с

фиксиран размер, за да създадат област, наречена буфер. В този буфер се записва входящата информация от мрежата. Препълване на буфера се получава, когато дадено съобщение лъже за своята големина, или пък когато умишлено е направено по-дълго от разрешения максимум. Например, ако съобщение твърди, че е голямо 240 байта, а всъщност е 256, програмата, която обработва постъпващите даннни, ще задели буфер с големина 240 байта и останалите 16 байта ще се презапишат върху мястото след края на буфера. Хакерите използват тези проблеми, като включват машинен код в частта от съобщението, която се записва след края на буфера. Така те могат да изпълняват код на атакуваната машина и по този начин могат да предизвикат други нередности в системата – да направят пробиви в сигурността и в крайна сметка да вземат контрол над машината.

Buffer Overruns атаките са широко разпространени и се появяват постоянно. Защитата от тях е следенето на последните бюлетини за сигурността на операционната система или използването на сигурни proxies, които могат да спрат подозрителни или злонамерени връзки, преди да са достигнали до сървъра.

Атаки крадящи информация

Тези атаки не са като Denial−of−service или като експлоатационните атаки – те, сами по себе си, не правят нищо вредно на жертвата. Те се използват за доставяне на информация за по-нататъшно проникване в системата.

Address Scanning Чрез автоматизиран софтуер хакерите изпращат ICMP echo съобщения до голяма

област от IP адреси (обикновено цели подмрежи). Компютрите, които отговорят, стават жертви на по-нататъшни опити за кражба на информация.

55

Page 56: FireWall

Защитата е да се конфигурира firewall-а, така че да филтрира ICMP echo съобщения.

Port Scanning С автоматизирани инсрументи хакерите се свързват с поредица от TCP портове сред

голяма област от host-ове. Тези инструменти показват с кои портове успешно е установена връзка. Сканирането на портове е широко използвано от хакери, търсещи си жертви, и е обикновено първата стъпка от атаката.

За да се засече сканирането, може да се използва софтуер, който отчита множество опити за връзка от един и същ host. Много firewalls засичат сканирането и могат да бъдат конфигурирани да блокират опитите за сканиране.

Inverse Mapping Inverse mapping атаката работи с информацията от ICMP отговорите на рутърите.

Хакерите могат да разберат, че даден host съществува от липсата на отговор "host unreachable" при изпращане на фалшиви response съобщения до този host. След като тези съобщения не получават отговор от host-а, но не получават и съобщение за грешка, то този host очевидно съществува. Тъй като обикновената сканираща дейност се засича лесно от firewalls, хакерите използват често срещани съобщения, за които стените не могат да бъдат конфигурирани да филтрират. Такива например са RESET съобщенията, SYN-ACK съобщенията и DNS response пакетите.

Stateful инспекцията и Network Address Translators автоматично защитават срещу тази атака, тъй като не допускат routing. За по-голяма сигурност може да се филтрират ICPM "host unreachable" отговорите или може да се конфигурира firewall-а да използва Stealth mode, който спира отговорите на ICMP и TCP SYN съобщенията.

Slow Scanning Атаките от този тип разчитат на факта, че firewall-ите и детекторите на сканиране

очакват да намерят голям брой връзки от един адрес, за да решат дали има сканиране или не. Детекторите пазят информация за броя на опитите за връзка определен период от време (10 сек. например). Чрез сканиране на по-големи периоди откриването на сканирането става невъзможно. За съжаление на хакерите тези атаки отнемат доста дълго време.

Architecture Probes Хакерите проучват отговорите на „лоши” пакети, изпратени до атакувания host,

използвайки инструменти, които имат бази данни с различните типове отговори. Понеже не съществува точно определен начин за отговаряне, всяка операционна система отговаря по свой уникален начин. След проверяването на отговорите в базата данни, хакерите могат да установят каква е операционната система на атакуваната машина. След прост статистически анализ на TCP sequence номерата на произволен поток от данни, идващ от жертвата, може да се разберат някои характеристики на TCP/IP стека. По този начин може да се разбере дори кой service pack се използва на дадена машина.

Имайки предвид, че хакери могат да разберат каква е операционната система, не трябва да се разчита на security through obscurity. Това значи, че трябва да се вземат всички мерки за сигурност дори при предположение, че атакуващите не знаят каква е използваната операционна система.

56

Page 57: FireWall

DNS Zone Transfers DNS протоколът не поддържа аутентикация за трансфери и informative updates,

което го прави податлив на атаки. Хакери могат да осъществят zone transfer, за да вемат имената и вътрешните IP адреси на всички host-ове, ако е поддържан публичен DNS сървър.

Има няколко неща, които могат да се направят, за да се предотврати атаката. Малките организации не трябва да пускат свои собствени DNS сървъри; трябва да се използват DNS сървъри, които поддържат разделен DNS, което гарантира, че вътрешните имена и адреси остават тайни; трябва да се филтрират zone transfer заявките чрез firewall-а; трябва да се използват вътрешни DNS сървъри, недостъпни от интернет, за вътрешните имена и отделни публични DNS сървъри за публичните имена.

Finger Finger протоколът може да осигури достатъчно информация за потребителите, така

че да позволи на хакери да познават потребителски имена или пароли. Този протокол е използван в ранните дни на интернет като начин да се прави справка за e-mail адреси. Тъй като вече никой не очаква да получи някаква полезна информация от този протокол, то най-добрата защита срещу атаката е той просто да бъде изключен. Firewall-ът трябва да се конфигурира да не допуска опити за връзка чрез finger протокола.

SNMP Leakage Simple Network Management Protocol е бил създаден за да се грижи автоматияно за

конфигурационни подробности на мрежови устройства. Почти всяко мрежово устройство (hubs, switches, routers, servers) може да бъде конфигурирано да осигурява SNMP инофрмация. Интерфейси, като DSL adapters и кабелни модеми, както и множество firewalls, също често са SNMP конфигируеми. Поради голямата си разпространеност, SNMP често, от недоглеждане е оставян на устройства извън публичната firewall, което осигурява информация за мрежата и дава възможност на хакери да управляват дадено устройство. Пример за тоеа е VPN контролер, които трбва да бъде разположен паралелно с firewall и който разкрива своята SNMP информация на публичен интерфейс, за да моче тя да бъде комтролирана от service provider-ът. Така се излага огромно количество информация за структурата на вътрешната мрежа, включително вътрешни IP адреси и MAC адреси. Тази информация показва на хакера как точно да атакува мрежата, като например source−route през NAT.

Защитата от тази атака е да се деактивира SNMP на всяко устройство, което е извън firewall-а, дори когато service provider-ът казва че се нуждае от него – все пак мрежата не е негова, а сигурността трябва да е на първо място.

Дезинформационни атаки

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

DNS Cache Pollution Хакери могат да се опитат да направят фалшиви ъпдейти на DNS сървъри с

неправилни IP адреси. Понеже DNS сървърите не поддържат аутентикация при

57

Page 58: FireWall

разменянето на информация с други name сървъри, хакерите могат да вкарат невярна информация и да пренасочат потребителите към собствения си host.

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

Registrar Usurpation Някои Internet name registrars разчитат на e−mail съобщения за ъпдейти. Те

сравняват адреса на регистрирания притежател с адреса на идващия e-mail, който съдържа информация за ъпдейта и ако те съвпадат, то този ъпдейт се осъществява. Понеже e-mail-ът може да се фалшифицира, то е възможно тези ъпдейти да не са легитимни. Така някой хакер може да пренасочи потебителите към собствения си host.

За крайните потребители не е въможно да се защитят от тази атака. Повечето registrars използват по-сигурни механизми за ъпдейт, като например отговор на e−mail или телефонно потвърждение.

Forged E−mail Използвайки прости техники, като конфигурирне на e-mail клиент с некоректна

информация, хакерите могат да фалшифицират e-mail съобщения до вътрешни за локалнатa мрежа клиенти. Като твърдят, че са от някой, когото клиентът познава и на когото вярва, тези съобщения могат да го накарат да върне полезна информация, или да инсталира троянски кон, или да посети злонамерена уеб страница. SMTP протоколът не поддържа аутентикация на изпращача на e-mail и множество версии на e-mail програми не записват достатъчно информация, за да може успешно да се проследи източник на e-mail съобщения. E-mail сървърите включват последователност от transmission headers в техните e-mail съобщения, но съществуват сървъри, за които се знае, че пропускат тези !хедъри!. След като хакери знаят, че даден сървър прави този пропуск, то те могат да го използват за да направят своите атаки анонимни. „Изпирането” на IP адрас чрез лошо конфигуриран proxy сървър също може да направи даден e-mail непроследим.

Единствената защита от тази атака е потребителското осъзнаване на нещата. Трябва да се накарат потребителите да разберат, че фалшифицирането на e-mail е възможна и вероятна атака, дори и в добре защитени мрежи. Съществува възможност да се използва PGP или сертификати за аутентикация на e-mail, но аутентикираните e-mail-и не са широко разпространени и ако дадена организация реши да направи това, то не може да се очаква да получава аутентикирани e-mail съобщения от другаде освен вътре в себе си.

Няколко препоръки при изграждане на firewall: 1. Firewall-те се променят непрекъснато, затова е добре да се следят тестовете в

специализираните списания като Network computing и InfoWorld,или Security ориентирани wab сайтове и най-вече да се тестват продуктите, когато това е възможно.

2. Трябва да се формулират добре изискванията, които firewall-ът да покрива.Преди

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

58

Page 59: FireWall

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

3. ОС, на която ще работи firewall-ът също е от значение. Ако администраторът не е

добре запознат с Unix базираните ОС, то използването на firewall, работещ бърху такива, не е препоръчително. Факт е, че голяма част от пробивите на firewall-ите са причинени от грешка при конфигурирането им - т.е. провалил се е не firewall-ът, а администраторът.

4. Интерфейсът също не е без значение. Въпреки това не е разумно да се избере

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

5. Добре е да се избере продукт, който има поне сертификат ICSA и за предпочитане

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

В заключение не трябва да забравяме, че firewall-ите не са непробиваеми. При всеки

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

59

Page 60: FireWall

Библиография: Internet Firewalls u Network Security (второ издание). Chris Hare u Karanjit Siyan. New Riders. ISBN: 1-56205-632-8. 1996. Building Internet Firewalls. D. Brent Chapman и Elizabeth D. Zwicky. O'Reilly & Associates. ISBN: 1-56592-124-0. 1995. Internet Security Resource Library: Internet Firewalls and Network Security. Firewalls 24Seven (второ издание).Matthew Strebe и Charles Perkins. SYBEX Inc. ISBN: 0−7821−4054−8. 2002

60