Софтуерни методи за анализ и контрол на IP трафика

Адрес на източника

Приложение или протокол

Порт на източника

Порт на получателя

Всички рутери(дори тези, които не са конфигурирани да филтрират пакети) обикновено проверяват изцяло пакета за да определят къде да го препратят. Но защитните стени с филтрация на пакети стигат по-далеч. Преди да пренасочат пакета, защитната стена проверява данните в пакета дали съответстват на правилата заложени в таблицата с правилата, които определят дали пакета трябва да премине или да бъде отказан достъп. Защитната стена проверява дали информацията в хийдъра на пакета съответства на правило, ако не намери съответствие пакета се третира по правилата по подразбиране. Правилото по подразбиране трябва да бъде заложено в таблицата с правилата и за сигурност, защитната стена трябва да откаже достъп на пакета. Можем да определим правила, които определят кои пакети да се приемат и на кои да бъде отказан достъп. Например можем да определим правила, които казват на защитната стена да откаже пакетите от определени сървъри от които идва информация която не е безопасна, като сървърите се указват чрез тяхните IP адреси.

Можем да забраним също и пакетите базирани на номерата на портовете на TCP или UDP пакетите. Конфигурирайки защитната стена по този начин, ще можете да ползвате услугите TELNET или FTP връзки само ако се използват от определени сървъри или хостове. Но успеха на тази конфигурация зависи много от TCP/IP дефинициите, сървърите и клиентите често използват портове на услугите, които използват стандартни портове за различните услуги, но не всички сървъри ги използват.

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

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

Всички защитни стени се придържат към информацията получена и генерирана от протоколите в различни нива на OSI модела.

OSI модел	Интернет протоколи	Защитни стени
Приложен слой	Telnet, FTP, DNS, NFS, PING, SMTP, HTTP	Гейтуей на ниво приложение. Защитна стена с проверка на състоянието.
Представителен слой
Сесиен слой	TCP	Цикличен гейтуей.
Транспортен	TCP
Мрежов слой	IP	Защитна стена с филтриране на пакети
Канален слой
Физически слой

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

За да определи дали изискваната сесия е позволена, цикличният гейтуей, използва следната последователност от действия :

- Сигурен клиент изисква създаването на сесия за ползването на дадена услуга и гейтуея приема заявката, на базата на това , че клиента покрива минималните филтриращи изисквания ( DNS може да намери IP адреса и хостанейма на клиента).

- В последствие в зависимост от поведението на клиента, гейтуея създава сесия между клиента и непровереният хост и след това от близо следи TCP съединенията между двата хоста. Създаването на съединения между двата хоста предизвиква обмяна на TCP пакети с флагове SYN (синхронизиране) или ACK (разпознаване). Тези пакети са за легитимиране на точните точки на предаване за тази сесия. След това цикличния гейтуей дали сигурният клиент и непровереният хост са оторизирани да участват в TCP сесията. Ако са се създава виртуалното съединение. След това гейтуея просто получава и препраща пакетите между двата хоста. Цикличният гейтуей притежава таблица с съществуващи връзки позволяващи връзката между хостовете или сървърите. Когато една от сесиите приключи тя се изключва от таблицата.

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

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

Цикличният гейтуей има един основен недостатък : веднъж създадена виртуалната връзка, всяко приложение може да я ползва защото цикличният гейтуей оперира само на сесийният слой на OSI модела. С други думи цикличният гейтуей не може да проверява съдържанието на пакета, което се отнася до приложният слой. Поради това, че цикличният гейтуей не филтрира индивидуално всеки пакет има възможност по виртуалната връзка да се пуснат пакети, които да увредят сървъра или хоста за който са предназначени, т.е. докато има виртуално съединение сървъра ще обменя пакетите независимо от тяхното съдържание. За да филтрирате пакетите на ниво приложение е нужно да използвате гейтуей на приложно ниво.

2.2.2.3 Гейтуей на приложно ниво.

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

-прокситата са специфични за всяко приложение

-прокситата могат да филтрират пакети на приложно ниво от OSI модела.

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

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

Гейтуеите на приложно ниво могат да ограничат специфични действия да бъдат изпълнявани. Например, гейтуея на приложно ниво може да бъде конфигуриран да не изпълнява PUT командата на FTP сървъра. Забранявайки тази команда можем да предотвратим сериозна повреда на информацията съдържана на сървъра.

Гейтуея на приложно ниво е една от най-сигурните защитни стени. Но той има и недостатъци. Някой от потребителите се оплакват от чувствително забавяне на услугите или множествено свързване преди да са се свързали с Internet, или Intranet през гейтуея на приложно ниво.

Въпреки ,че повечето производители твърдят, че гейтуеите на приложно ниво са прозрачни за потребителите, много от тях препоръчват да конфигурирате гейтуея да изисква потребителска верификация преди да се свържат към интернет. Има създадени такива решения за решаване на проблема с прозрачността. Например, едно обикновено приложение използва версията на SOCКS протокола за да маршрутизира TCP/IP услугите. SOCKS предлага Internet Engineering Task Force (IETF) стандарт, който осигурява прозрачни услуги за верификация на заявки от потребители на дадена система за защита. Но SOCKS не е прозрачна за мрежовите администратори, т.е. вие трябва да промените приложенията стартиращите от компютъра на всеки клиент, който се свързва през защитната стена. Също SOCKS включва други функции за сигурност (като частен и публичен ключ за кодиране), но не включва филтриране на индивидуални пакети.
2.2.2.4 Защитна стена с проверка на състоянието

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

Защитната стена с проверка на състоянието също функционира и като цикличният гейтуей определяйки дали заявената сесия е разрешена. Например защитната стена с проверка на състоянието проверява дали SYN и ACK флаговете и последователността от числа съвпада.

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

От друга страна защитната стена с проверка на състоянието не изисква две връзки, позволявайки директна връзка между локалният и отдалеченият клиент. За да осигури сигурна връзка, защитната стена с проверка на състоянието задържа и проверява всеки пакет преминаващ през приложният слой на OSI модела. Защитната стена с проверка на състоянието не залага на специфични проксита а на алгоритми за разпознаване и обработка на данните от и за приложният слой. Тези алгоритми сравняват пакетите с готово последователности от битове на вече обработени пакети и теоретично имат възможност да обработват пакетите по ефективно от специфичните за приложенията проксита. Поради факта, че защитната стена с проверка на състоянието осъществява директна връзка между локалният и отдалеченият клиент някой смятат, че този метод е по – малко сигурен от гейтуея на приложно ниво. Но защитната стена с проверка на състоянието е популярно средство за осигуряване на сигурна Internet и Intranet връзка поради факта, че е прозрачен за потребителите, обработва и филтрира данните в най-високото ниво на OSI модела и не изисква промяна в софтуера на клиентите, както и стартирането на различно прокси за всяка услуга.

2.3 Налични средства в операционна система Linux за управление и анализ на IP трафика

И така, какво е пакетен филтър?

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

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

Защо бих искал да имам пакетен филтър?

Контрол. Сигурност. Наблюдение.

Когато използвате компютър с Линукс за да свържете вашата вътрешна мрежа с някоя друга (например Интернет) вие имате възможност да разрешите само някои конкретни типове трафик, както и да забраните други. Например в заглавната част на пакета се съдържа адреса към който е насочен този пакет (destination), така че можете да спрете всички пакети насочени към определена част от външната мрежа. Ето и друг пример - аз използвам Netscape за да разглеждам архивите Dilbert. На страниците там има реклами от doubleclick.net и Netscape губи моето време и честотна лента като радостно ги зарежда. Казвайки на пакетния филтър да не приема пакети от или за адресите притежавани от doubleclick.net може да решим този проблем .

Когато вашият компютър с Линукс е единственото нещо между хаосът в Интернет и вашата хубава и подредена мрежа, то добре е да знаете как да ограничите какво може да почука на вашата врата. Например, може да искате да разрешите всичко което излиза навън от вашата мрежа, но се притеснявате от добре известния `Ping на смъртта' идващ от злонамерени външни хора. Или пък не искате някои отвън да

има телнет достъп до вашата Линукс машина, въпреки че всички потребители имат пароли. Може би (както повечето хора) вие искате да бъдете само наблюдател в Интернет, а не и сървър (със или без ваше знание). Просто не позволявайте на някой отвън да се свързва с мрежата ви, като накарате вашият пакетен филтър да отказва всички входящи пакети които се опитват да инициират връзка.

Наблюдение:

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

Как да направя пакетен филтър под Линукс?

Линукс ядрата имат възможности за филтриране на пакети още от версиите 1.1. Първото поколение, базирано на ipfw от BSD, беше пренесено от Алан Кокс в края на 1994 година. То беше подобрено от Йос Вос (Jos Vos) и други хора във версията на Линукс 2.0; потребителската програма `ipfwadm' контролираше правилата за филтриране в ядрото. В средата на 1998 година, за Линукс 2.2 Ръсти Ръсел преработи голяма част от кода в ядрото с помощта на Майкъл Нюлинг и създаде потребителската програма `ipchains'. И накрая, друго пренаписване на кода в ядрото и потребителската програма от четвърто пололение `iptables' станаха факт в средата на 1999 година за Линукс 2.4. Трябва ви ядро с netfilter инфраструктура в него; netfilter е общата основа в Линукс ядрото към която се включват останалите компоненти (като iptables модула например). Това означава, че ви трябва ядро версия 2.3.15 или по-нова. Отговорете с `Y' на CONFIG_NETFILTER при конфигурацията на ядрото.

Програмата iptables си говори с ядрото и му казва кои пакети да филтрира.

iptables заменя програмите ipfwadm и ipchains:

Запазване на правилата след рестарт

Текущата конфигурация на вашата защитна стена (firewall) се пази в ядрото, следователно тя ще се загуби при рестарт. Може да ползвате скриптовете iptables-save и iptables-restore за запазване на конфигурацията във файл и нейното възстановяване.Друг начин е да сложите необходимите команди за задаване на желаните правила в инициализиращите скриптове.

Как пакетите преминават през филтрите

Първоначално в ядрото има три списъка от правила във `filter' таблицата; тези списъци се наричат вериги с правила за филтриране (firewall chains) или просто вериги (chains). Тези три вериги се наричат INPUT (вход), OUTPUT (изход) и FORWARD (препращане). Трите кръга представляват веригите за които се спомена по-долу. Когато един пакет достигне до някой от кръговете на диаграмата се проверяват правилата в тази верига и се решава съдбата на пакета. Ако веригата каже пакета да бъде отхвърлен

(DROP), то той бива заличен веднага, но ако решението е той да бъде приет (ACCEPT) пакета продължава пътя си по диаграмата

Веригата е списък от правила. Всяко правило гласи `ако заглавната част на пакета изглежда така, то направи с този пакет ето това'. Ако пакетът не отговаря на изискванията в това правило, то се преминава към следващото във веригата. И накрая, ако няма повече правила с които да се сравни пакета ядрото решава съдбата му съгласно политиката (policy) на веригата. Обикновено, ако в една система се държи на сигурността, то политиката казва на ядрото да откаже пакета.

1. 
   Когато се получи пакет (примерно от мрежовата карта) ядрото първо поглежда за къде е адресиран той: това се нарича `рутиране'.
   
2. 
   Ако е адресиран за тази машина, то пакетът преминава надолу по диаграмата към INPUT веригата. Ако премине през нея процеса чакащ този пакет ще го получи.
   
3. 
   В противен случай, ако в ядрото не е активирано прехвърлянето на пакети (forwarding), или пък то не знае в каква посока да го пренасочи, пакета ще бъде отказан. Ако пък
   

4. 
   прехвърлянето е включено и пакетът е насочен към друг мрежов интерфейс (ако имате такъв), тогава той отива надясно в диаграмата, към FORWARD веригата. Ако премине успешно през нея ще бъде изпратен по другия интерфейс.
   
5. 
   И накрая, програма работеща на машината може да изпраща пакети. Те минават директно към OUTPUT веригата: ако тя каже, че пакета може да премине той продължава към който интерфейс е бил насочен.
   

iptables има доста детайлна man страница (man iptables), в случай, че ви трябват повече конкретни детайли. Има няколко различни неща които можете да правите с iptables. Започвате с трире вградени вериги INPUT, OUTPUT и FORWARD които не можете да изтриете. Нека разгледаме действията чрез които можете да контролирате цели вериги:

1. 
   Създаване на нова верига (-N).
   
2. 
   Изтриване на празна верига (-X).
   
3. 
   Смяна на политиката на вградена верига (-P).
   
4. 
   Показване на правилата във верига (-L).
   
5. 
   Изтриване на правилата във верига (-F).
   
6. 
   Нулиране на байтовите и пакетни броячи на всички правила във верига (-Z).
   

1. 
   Добавяне на ново правило към верига (-A).
   
2. 
   Вмъкване на ново правило на дадена позиция (-I).
   
3. 
   Замяна на едно правило на дадена позиция с друго (-R).
   
4. 
   Изтриване на правило на дадена позиция, или първото съвпадащо (-D).
   

Какво ще видите, когато компютърът ви стартира

iptables може да бъде модул, с име (`iptable_filter.o'), който трябва да бъде зареден автоматично когато стартирате iptables за първи път. Може също така да бъде вграден в ядрото.

Преди да бъдат изпълнени съответните iptables команди (внимание: някои дистрибуции стартират iptables в своите стартиращи скриптове), няма да има никакви правила в която и да е от вградените вериги (`INPUT', `FORWARD' и `OUTPUT'), всички вериги ще имат политика ACCEPT. Можете да промените политиката по подразбиране за FORWARD веригата като укажете опцията `forward=0' на iptable_filter модула.

Действия върху едно правило

Това са най-често ползваните действия при филтрирането на пакети - манипулирането на правила. Вероятно най-популярните от тях са командите за добавяне (-A) и изтриване (-D). Другите две (-I за вмъкване и -R за замяна) са просто техни разширения .Всяко правило задава определени условия на които пакета трябва да отговаря, и какво действие да се извърши с него в такъв случай (`target'). Например, вие може да искате да забраните всички ICMP пакети идващи от 127.0.0.1. В такъв случай условията които искате да зададете са: протоколът да бъде ICMP; и адресът източник да е 127.0.0.1. Действието трябва което да се извърши е `DROP'.127.0.0.1 е адреса на `loopback' интерфейса, който ще имате дори и без връзка към истинска мрежа. Може да използвате програмата `ping' за да генерирате такива пакети (тя просто изпраща ICMP тип 8 (echo request) пакети, на които всички мрежови устройства (или поне тези които имат доброто желание) трябва задължително да

отговорят с ICMP тип 0 (echo reply) пакет). Това я прави много полезена за тестове.

Тогава ние добавяме (-A) към `INPUT' веригата правило, което указва всички пакети идващи от 127.0.0.1 (`-s 127.0.0.1') с протокол ICMP (`-p icmp') да бъдат отказани (`-j DROP').

След това пробваме нашето правило, като пускаме ping отново. Този път, след кратка пауза, програмата се отказва да чака отговор който никога няма да получи.Можем да изтрием правилото по един от двата начина. Знаем, че има само едно правило в input веригата, така че можем да го изтрием по номер:

Изтрива правило номер 1 от INPUT веригата. Вторият начин е да използваме същата команда, както при добавянето на правилото, но да заменим -A с -D. Той е полезен когато имата сложна верига от
правила и не искате да ги броите за да разберете кое е правило номер 37, което всъщност искате да премахнете. В такъв случай може да ползвате:

Синтаксисът на -D трябва да бъде същият както при -A (или -I и -R) командата. Ако има повече от едно съвпадащи правила в същата верига, то ще бъде изтрито само първото.
Дефиниране на филтри

Видяхме как се използва опцията `-p' за да се укаже определен протокол, или пък `-s' за адреса на изпращача. Освен тези две има много други опции, които можем да използваме за да зададем определени характеритики на пакетите. Следват кратки описания на всяка една от тях.

Задаване на IP адрес на изпащача и получателя

IP адресите на изпращача (`-s', `--source' или `--src') и получателя (`-d', `--destination' или `--dst') могат да бъдат зададени по четири различни начина. Най-често се използва пълното име, например `localhost' или `www.linuxhq.com'. Вторият начин е да се укаже IP адрес като `127.0.0.1'.

Третият и четвъртият начини позволяват задаването на група от IP адреси като `199.95.207.0/24' или `199.95.207.0/255.255.255.0'. И двата примера означават всички IP от 199.95.207.0 до 199.95.207.255 включително; числото след знака `/' определя кои части от IP се вземат под внимание. Стойността по подразбиране е `/32' или `/255.255.255.255' (сравнява целия IP адрес). За да зададете всеки IP адрес може да използвате `/0':
[ Забележка: `-s 0/0' е излишно в примера по долу. ]

Инверсия

Пред аргументите на много от флаговете, включително `-s' (или `--source') и `-d' (или `--destination') можете да поставите `!' (чете се като `НЕ') за да укажете всички адреси, които НЕ са равни на дадените. Например `-s ! localhost' ще съвпадне с всеки пакет, който не идва от localhost.

Задване на протокол

Протоколът се указва с опцията `-p' (или `--protocol'). Протоколът може да бъде число (ако знаете числените стойности отговарящи на съответните протоколи в IP) или име в случаите на `TCP', `UDP' или `ICMP'. Няма значение дали буквите са малки или главни, така че `tcp' е еквивалентно с `TCP'.Пред името на протокола може да се постави `!' за да се инвертира, например `-p ! TCP' за да зададете всички пакети с протокол различен от TCP.

Задаване на интерфейс

Опциите `-i' (или `--in-interface') и `-o' (or `--out-interface') указват името на входящия или изходящия интерфейс. Интерфейс се нарича физическото устройство по което пакетът е пристигнал (`-i') или пък предстои да бъде изпратен (`-o'). Можете да използвате командата ifconfig за да видите списък на всички интерфейси които са `вдигнати' (т.е., работещи в момента).Пакетите преминаващи през

INPUT веригата нямат изходящ интерфейс, следователно правила в които е указан такъв с опцията `-o' няма да съвпаднат с никой от преминаващите пакети.Аналогично, пакетите преминаващи през OUTPUT веригата нямат входящ интерфейс, следователно правилата използващи опцията `-i' в тази верига няма да съвпаднат с никой пакет.Само пакетите преминаващи през FORWARD веригата имат едновременно и входящ и изходящ инрерфейс.Напълно допустимо е да зададете интерфейс който в момента не съществува; правилото няма да съвпадне с никой от пакет, докато не се вдигне съответния интерфейс. Това е особенно полезно за dial-up PPP връзки ( обикновено интерфейс ppp0) и дурги подобни случаи.Като специален случай, интерфейси с име завършващо със знак `+' ще съвпаднат с всички интерфейси (независимо дали в момента съществуват или не) чието име започва с този символен низ. Например, за да зададете правило което съвпада с всички PPP интерфейси трябва да използвате опцията -i ppp+.Ако пред името на интерфейса се постави знака `!' с интервали около него, то правилото ще съвпада само с пакети които не от посоченият интерфейс(и),например -i ! ppp+.

Задаване на фрагменти

Понякога един пакет е прекалено голям за да може да бъде изпратен целият навендъж. Когато това се случи този пакет се разделя на фрагменти, които се изпращат като няколко по-малки отделни пакета. Получателят съединява тези фрагменти за да получи първоначалният пакет.Проблемът с фрагментите е, че първият от тях има пълен набор от заглавни полета (IP + TCP, UDP и ICMP), но следващите пакети имат само част от тях (IP без полета за другите протоколи). Следователно да се преглежда съдържанието на втория и следващи фрагменти за полетата на съответните протоколи (както това правят TCP, UDP и ICMP разширенията) е невъзможно.Ако

използвате функционалността за следене на връзките (connection tracking) или NAT, тогава всички фрагменти ще бъдат съединени преди да достигнат до кода за филтриране. В такъв случай няма нужда да се притеснявате за фрагментите.

Моля да забележите, че правилата в INPUT веригата от таблицата за филтриране (или всяка друга таблица закачаща се към NF_IP_LOCAL_IN hook) се преглеждат след като пакетите са дефрагментирани от IP стека на ядрото.

Във всички други случаи е важно да разбирате как фрагментите се третират от правилата за филтриране. Всяко правило, което изисква информация която не може да бъде предоставена няма да съвпадне с пакета. Това означава, че първия фрагмент се третира като всеки друг пакет. За вторият и следващи фрагменти, това не е така. Например правилото -p TCP --sport www (задаващо изходен порт на `www') няма никога да съвпадне с фрагмент (с изключение на първия). Същото важи и за инверсното правило -p TCP --sport ! www.Можете да зададете правило което се отнася специално за втория и следващи фрагменти като използвате флага `-f' (или `--fragment'). Също така е допустимо да укажете, че определено правило не се отнася за втория и следващи фрагменти като поставите ` ! ' пред `-f'.Обикновено се счита за безопасно да позволите на втория и следващите фрагменти да преминават, защото ако първия е бил филтриран, то това ще направи невъзможно сглобяването на пакета от получателя; въпреки това са известни грешки в някои софтуерни продукти които позволяват забиване на цялата машина чрез просто изпращане на фрагмент. Ваш избор.

Например, следното правило ще забрани всички фрагменти насочени към 192.168.1.1:

Разширения към iptables: Нови модули за сравнение

iptables е разширяем, което означава, че и ядрото, и програмата iptables могат да бъдат разширяване за да предоставят нови възможности.Някои от тези разширения са стандартни, а други по-екзотични. Разширенията могат да бъдат направени от други хора и да се разпространяват отделно за специфични потребители.Разширенията към ядрото обикновено се намират в поддиректорията за модули, примерно /lib/modules/2.4.0-test10/kernel/net/ipv4/netfilter. Те се рареждат автоматично при необходимост ако ядрото ви е компилирано с опцията CONFIG_KMOD, така че не трябва да ги вмъквате ръчно.Разширенията към програмата iptables библиотеки, които обикновено се намират в директорията /usr/local/lib/iptables/, но дистрибуциите ги слагат в /lib/iptables или /usr/lib/iptables.Разширенията биват два типа: нови действия, и нови модули за сравнение (ще говорим за новите действия малко по-късно). Някои протоколи автоматично предоставят нови проверки: в момента това са TCP, UDP и ICMP както се вижда по-долу.За тях ще можете да задаване новите проверки на командния ред, след опцията `-p', която зарежда съответното разширение. За изрично указване на нови проверки използвайте опцията `-m' за да заредите разширението, след което допълнителните опции ще бъдат налични.

За да получите помощна информация отностно дадено разширение, използвайте опцията с която го зареждате (`-p', `-j' или `-m') последвана от `-h' или `--help', примерно:

TCP разширения

TCP разширенията се зареждат автоматично ако е указана опцията `-p tcp'. Те предоставят следните опции (нито една от тях не съвпада с фрагменти).

след която можете да поставите `!' за инверсия и два символни низа от флагове. Те ви позволяват да филтрирате пакета в зависимост от състоянието на някои от тях в TCP заглавната част. Първият низ е маската: списък от флаговете които искате да бъдат проверени. Вторият указва кой/кои от тях трябва да бъдат вдигнати. Например:

пред него може да има `!', това е по-кратък вариант на `--tcp-flags SYN,RST,ACK SYN'.

може да се постави `!', след нея един или област от TCP портове. Това могат да бъдат имена на портове, както са указани в /etc/services, или числа. Областите могат да се зададат по няколко начина: два порта с поставени `:' между

тях; порт последван от `:' (за да укажете портове по-големи или равни на този); или `:' последвани от порт (за да укажете тези които са равни или по-малки на зададения),.

--sport

e синоним на `--source-port'.

и

–dport

последван по желание от `!' и число, ще съвпада с пакети чиито TCP опции са равни на това число. Ако пакета няма пълна TCP заглавна част, то той ще бъде отхвърлен автоматично при опит за проверка на TCP опциите.

Обяснение на TCP флаговете

Понякога е полезно да разрешите само TCP връзки в едната посока, а да забраните тези в другата. Например, може би искате да разрешите връзките към някой външен уеб сървър, но не и тези идващи от него.Първото нещо което идва на ум е да блокирате TCP пакетите идващи от сървъра. За съжаление, за да работят въобще, TCP връзките изискват пакети преминаващи и в двете посоки.Решението е да блокирате само тези пакети, които се използват за иницииране на връзка. Тези пакети се наричат SYN пакети (това са пакети с вдигнат SYN флат, и спуснати RST и ACK флагове, за по-кратко ги наричаме SYN пакети). Като забраните само тези пакети, можете да спрете опитите за осъществяване на

връзка отвън още в зародиш.Опцията `--syn' се използва точно за това: тя е валидна само в правила в които е указан TCP за протокол. Например за да зададете пакетите които опитват да направят TCP връзки идващи от 192.168.1.1:

-p TCP -s 192.168.1.1 --syn

Този флаг може да бъде инвертиран като пред него поставите `!', което означава всички пакети, освен тези за иницииране на връзка.

UDP разширения

Тези разширения се зареждат автоматично,ако е указана опцията `-p udp'. Те предоставят опциите `--source-port', `--sport', `--destination-port' и `--dport' които са аналогични на тези описани за TCP по-горе.

ICMP разширения

Тези разширения се зареждат автоматично ако е указан флагът `-p icmp'. Те осигуряват само една нова опция:

--icmp-type

евентуално последван от `!'за отрицание и име на icmp тип (примерно `host-unreachable'), или числена стойност (примерно `3'), или числа за тип и код разделени с `/' (пример: `3/3'). Списък от валидните имена на icmp типове можете да видите с `-p icmp --help'.

Други разширения за сравняване

Тези разширения в пакета netfilter са за демонстрация и (ако са инсталирани) могат да бъдат извикани с опцията `-m'.

За да използвате този модул трябва задължително да укажете `-m mac' или `--match mac'. Той се използва за сравняване на Ethernet (или MAC) адреса на изпращача на входящите пакети, и следователно е приложим само за пакети преминаващи през PREROUTING и INPUT веригите. Той предоставя само една опция:

може да бъде последвана от `!', и ethernet адреса в шестнайстичен вид разделен с ':', например `--mac-source 00:60:08:91:CC:B7'.

За да използвате този модул трябва задължително да зададете `-m limit' или `--match limit'. Той се използва за ограничаване на броя съвпадения за единица време, примерно за ограничаване на log съобщенията. Той ще съвпада само определен брой пъти в секунда (по подразбиране 3 съвпадения за час, с burst от 5). Модулът приема два незадължителни аргумента:

последван от число; задава средно колко най-много съвпадения за една секунда са разрешени. Можете да укажете изрично каква е мерната единица, използвайки `/second', `/minute', `/hour' или `/day', или части от тях (`5/second' е същото като `5/s').

послеван от число, указва максималния burst преди лимита да влезе в сила.Това разширение най-често се използва ограничаване на LOG съобщенията. За да разберете как работи, нека разгледаме следното правило, което логва пакети използвайки ограничението по подразбиране:

Забележка: в момента не можете да създадете правило с време за презареждане по-голямо от 59 часа, следователно ако зададере скорост от един пакет на ден, стойността указана на burst трябва да бъде по-малка от 3.

Друго приложение на този модул е за предпазване от различни атаки тип "Отказ на услуга" (DoS).

Защита от Syn-flood:

Да приемем, че сме задали лимит от 1 пакет за секунда, и burst от 5 пакета, но пакетите пристигат по 4 в секунда в продължение на 3 секунди, след което спират и след 3 сек отново идват по 4 пакета/секунда.

Виждате,че на първите пет пакета е позволено да надвишат указания лимит от един пакет за секунда, след което ограничението влиза в сила. Ако има пауза, то ще бъде позволен още един burst, но без да се надвишава максималната граница указана от правилото (1 пакет за секунда, след като се използва burst).

Този модул се опитва да свърже различните характеристики на създателя на пакета, за пакети които се генерират локално. Той е валиден само в OUTPUT веригата, и дори там някои пакети (примерно отговори на ICMP ping) може да нямат собственик, и следователно няма никога да съвпаднатh.

Съвпада ако пакетът е създаден от процес с указаното ефективно (числено) user id.

Съвпада ако пакетът е създаден от процес с указаното ефективно (числено) group id.

Съвпада ако пакетът е създаден от процес с указаното process id.

Съвпада ако пакетът е създаден от процес с указаното стойност на session група.

Този експериментален модул трябва да бъде указан изрично чрез `-m unclean'или `--match unclean'. Той прави разнообразни случайно подбрани проверки за коректност на пакетите. Този модул не е проверен и не трябва да се използва като мярка за сигурност (най-вероятно той може да направи нещата още по-лоши, защото е възможно в самия модул да има грешки). Модулът не предоставя допълнителни опции.

Модул за състоянията (The State Match)

Най-полезният критерий за сравнение се предоставя от модулът за `състоянията', който интерпретира информацията за следене на връзките предоставена от `ip_conntrack' модула. Използването му е силно препоръчително.Задавайки `-m state' можем да използваме

допълнителната опция `--state', която е списък от състояния, разделени със запетая, с някое от които пакета трябва да съпвада (флагът `!' указва, че пакета трябва да не съвпада с тези състояния). Състоянията могат да бъдат:

NEW

Пакет, който създава нова връзка.

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

Пакет, който e свързан с, но не е част от вече съществуваща връзка, примерно ICMP грешка, или (ако е зареден FTP модулът) пакет който инициира връзка за предаване на данни по ftp.

Пкает, който не може да бъде идентифициран поради някаква причина: това включва недостатъчно свободна памет и ICMP съобщения за грешки, които не са свързани с никоя от известните връзки. По принцип тези пакети трябва да бъдат спирани.

Ето един пример за употребата на това много полезно разширение:

Указване на действие

След като вече знаем какви проверки можем да извършваме върху един пакет, ни трябва начин по който да кажем какво да се случи с тези пакети който отговарят на тяхните изисквания. Това се нарича действие на правилото.Има две много прости вградени действия: DROP и ACCEPT. Вече се запознахме с тях. Ако пакетът съвпадне с някое правило и указаното действие е едно от тези две, то не се преглеждат други правила: съдбата на пакета е вече решена. Има два други вида действия, освен вградените: разширения и вериги дефинирани от потребителя.

Вериги дефинирани от потребителя

Една мощна възможност, която iptables наследи от ipchains е възможността потребителят да създава нови вериги, в допълнение на трите вградени такива (INPUT, FORWARD и OUTPUT). Има конвенция имената на веригите дефинирани от потребителя да се изписват с малки букви, за да се различават по-лесно. (как се създават нови вериги е описано по-долу в Действия върху цяла верига).Когато пакет съвпадне с правило чието действие е верига дефинирана от потребителя, то пакетът преминава през правилата в тази верига. Ако в нея не се реши съдбата на пакета, то след като пакетът е преминал през всички правила, той продължава в следващото правило от текущата верига.

Да вземем две (безмислени) вериги: INPUT (вградената верига) и Test (верига дефинирана от потребителя).

Нека един TCP пакет идва от 192.168.1.1 и отива към 1.2.3.4. Той попада в в INPUT веригата, и се тества спрямо правило 1 - не съвпада. Правило 2 съвпада и негово действие е Test, така че следващото правило което се проверява е в началото на Test. Правило 1 в Test съвпада, но не е указано действие, и се преглежда следващото правило - правило 2. То не съвпада, следователно вече сме достигнали до края на веригата. Връщаме се обратно в INPUT веригата, където последно проверихме правило 2, следователно сега преглеждаме правило 3, което също не съвпада.

В крайна сметка пътя на пакета е:


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

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

Разширения на iptables: Нови действия

Другият вид разширение е новото действието. То се състои от модул за ядрото и евентуално разширение за iptables което осигурява нови опции за командния ред. Има няколко такива разширения в стандартната netfilter дистрибуция:

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

Последвана от номер или име на ниво. Валидни имена са (нечуствителнни към малки/главни букви) `debug', `info', `notice', `warning', `err', `crit', `alert' и `emerg', отговарящи на номера от 7 до 0. Виж man страницата на syslog.conf за повече информация относно тези нива. По подразбиране се ползва `warning'.

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

Този модул е най-полезен след използване на limit, за да не препълните журналните файловете си.

REJECT

Този модул има същия ефект като `DROP', но на подателя на пакета се изпраща ICMP `port unreachable' съобщение за грешка. Забележете, че ICMP съобщение за грешка не се изпраща ако (виж RFC 1122):

• 
  Пакетът който бива отфилтриран е ICMP съобщение за грешка или някакъв неизвестен ICMP тип.
  
• 
  Пакетът който бива отфилтриран е фрагмент, различен от първия.
  

REJECT също така може да има аргумент `--reject-with' който променя вида на пакета изпращан като отговор: виж man страницата.

Специални вградени действия

Има две специални вградени действия: RETURN и QUEUE.

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

QUEUE е специално действие, което изпраща пакета в опашка за обработка от потребителя. За да има полза от това са необходими още два компонента:

• 
  "queue handler", който се занимава със същинската работа по прехвърлянето на пакетите между пространството на ядрото и на потребителя (kernel and userspace) и
  
• 
  потребителска програма,която да получи и евентуално да редактира пакетите, след което да реши тяхната съдба.
  

Следва кратък пример за това как може да се използват iptables за изпращане на пакети за обработка в побтребителското пространство:

С това правило локално генерираните изходящи ICMP пакети (като например тези от ping) се препращат към ip_queue module, който след това се опитва да ги предаде на потребителската програма. Ако няма програма която да приеме пакетите, то те се отхвърлят . За да напишете такава програма използвайте libipq API-то. То се разпространява с iptables. Примерен код може да бъде намерен в "testsuite tools" (примерно redirect.c) в CVS.

Статуса на ip_queue може да се провери чрез:

/proc/net/ip_queue

Максималната дължина на опашката (т.е. броят пакети препратени към потребителската програма, за които все още не е получен отговор със съответното действие) може да се контролира чрез:

/proc/sys/net/ipv4/ip_queue_maxlen

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

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

Действия върху цяла верига

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

Създаване на нова верига

Нека да създадем една нова верига. И понеже имам страхотно въображение, ще я наречем test. Можем да използваме опциите `-N' или `--new-chain':

Изтриване на верига

Изтриването на верига е също толкова просто, използвайки опциите `-X' или `--delete-chain'.

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

Изтриване на правилата от верига

Има един много лесен начин за изтриване на всички правила от някоя верига, просто използвайте командата `-F' (или `--flush').

Извеждане на правилата във верига

Можете да видите списъс със всички правила в дадена верига използвайки командата `-L' (или `--list').

Стойността `х references', която се изписва след името на всяка създадена от потребителя верига, е броят на правилата които имат указана тази верига за свое действие. Този брояч трябва да бъде нула (и във веригата да няма правила) преди тя да може да бъде изтрита.Ако не се укаже име на кокнтретна верига, то се извежда съдържанието на всички вериги, дори и празните.

Има три опции които може да се използват заедно с `-L'. Първата, `-n' (numeric) е много полезна, тъй като предотвратява опитите на

iptables да проверява имената съответстващи на IP адресите, които (ако използвате DNS, както повечето хора) биха причинили големи закъснения, в случай че DNS услугата не е настроена правилно, или сте отфилтрирали DNS заявките. Също така TCP и UDP портовете ще бъдат изведени като цифри, вместо с имена.

Опцията `-v' ще ви покаже в детайли цялата информация за правилата, като броячите за пакети и байтове, сравнения с TOS полето и интерфейсите. Без нея тези стойности няма да бъдат изведени.

Забележете, че броячите за пакети и байтове се извеждат със суфикси K', `M' или `G' съответно за 1000, 1,000,000 и 1,000,000,000. Ако използвате и опцията `-x' (expand numbers) ще бъдат отпечатани целите числа, независимо колко са големи.

Рестартиране (Нулиране) на броячите

Полезно е да имате възможността да нулирате броячите. Това може да бъде направено с опцията `-Z' (или `--zero').

Нека разгледаме следния пример:

Задаване на политика

Споменахме какво се случва когато един пакет достигне до края на някоя от вградените вериги, когато разглеждахме пътя по който преминават пакетите по-горе. В този случай, съдбата на пакета се определя от политиката на веригата. Само вградените вериги (INPUT, OUTPUT и FORWARD) имат политики, защото ако пакетът достигне до края на някоя верига дефинирана от потребителя, то той ще продължи пътя си през предходната верига.

Политиката може да бъде ACCEPT (приеми) или DROP (отхвърли), например:

Съвместяване на NAT и филтриране на пакети

Много често се изисква да правите едновременно NAT и филтриране на пакети. Добрата новина е, че те работят доста добре заедно.Изградете своя пакетен филтър, като напълно пренебрегване факта, че използвате NAT. Адресите на изпращача и получателя, които ще види пакетния филтър ще бъдат `истинските' адреси. Например, ако правите DNAT за да изпращате всички връзки за 1.2.3.4 на порт 80 към 10.1.1.1 на порт 8080, то пакетния филтър ще види пакети отиващи към 10.1.1.1 на порт 8080 (истинското направление), а не към 1.2.3.4 на порт 80. По подобен начин може да игнорирате и употребата на masquerading: ще изглежда, че пакетите 'идват' от техните истински вътрешни IP адреси (примерно 10.1.1.1), и отговорите ще се връщат пак там.Може да използвате `state' разширенията без да натоварване филтъра допълнително, защото използването на NAT изисква употребата на механизмите за преследяване състоянието на връзките. За да подобрим простият

пример за маскиране от NAT HOWTO, като забраним всички нови връзки идващи от интерфейса ppp0 interface, може да използваме това:

Съвети относно изграждането на пакетен филтър

Разпространена практика в областта на компютърната сигурност е да се забрани всичко по подразбиране, след което да се разреши само това което е необходимо. Това може да бъде изразено така `всичко, което не е изрично разрешено, е забранено'. Аз бих ви препоръчал точно този подход, ако сигурността е от най-голямо значение за вас.

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

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

Препоръчва се задълбочен подход към сигурността, комбинирайте tcp-wrappers (за връзките към самия пакетен филтър), проксита (за връзките преминаващи през него), проверка на маршрутизацията и пакетно филтриране. Проверка на маршрутизацията, означава пакетите които пристигат от неочакван интерфейс да бъдат блокирани. Например, ако вашата вътрешна мрежа има адрес 10.1.1.0/24, и пакет с такъв адрес на изпращача пристигне на външния ви интерфейс, то той ще бъде отхвърлен. Това може да бъде включена за даден интерфейс (ppp0) ето така:

4. 
   Изводи
   

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

Поради прекомерните непозволени достъпи (атаки) от страна на потребителите на съществуващите локални мрежи, както от желанието им за ползване на трафик се създават големи проблеми на администраторите на мрежите. Това изисква създаването на програмни продукти за защита и управление на трафика. Създадената защитна стена позволява бързо и качествено управление на трафика в локалната мрежа в училището. Анализирайки всички съществуващи методи за управление на IP трафика се достига до извода, че създадената защитна стена е напълно приложима в локална мрежа