Въведение в SNORT
	от Nick Angelow(4-02-2005) рейтинг (13)   [ добре ]  [ зле ]  Вариант за отпечатване SNORT Дмитрий Рожков UNIX администратор в ИД „Питер“ rojkov@piter.com 29 януари 2001 || Библиотека ЛинуксЦентър Колкото и добре да е защитен един web-server или шлюз към Internet, винаги съществува възможност за пробив в него. И за системният администратор ще е по-добре да разбере за тези опити още преди да е осъществен самият пробив. Затова средствата, позволяващи не само откриването на факта на проникване в системата, но и способни да предупреждават за подобни нахлувания, са от особена важност. Съществуват два вида системи за откриване на нарушители1 – към първите спадат програмите, откриващи аномалии във функционирането на системите, например необичайно голямо количество едновременно работещи процеси, увеличен трафик през интерфейсите на системата и други подобни. Към вторите се отнасят системите за откриване на нарушители, работата на които се състои в търсенето на предварително известни признаци на атаки. Що се отнася до програмата Snort, тя смело може да бъде причислена и към двата вида. Благодарение на своята отворена архитектура, Snort може лесно да бъде разширена и допълнена за решаване на различни задачи. Тази статия не претендира да е всеобхватно ръководство по Snort, а е един доста свободен превод на ръководството, написано от Martin Roesh2, смесен с моите собствени мисли. Изчерпателна информация за това, какво представлява Snort и как да го използвате, може да се намери на http://www.snort.org/. Какво представлява Snort? Snort е мрежова система за откриване на нарушители, способна да извършва в реално време анализ на трафика, предаван по контролирания интерфейс, с цел откриване на опити за пробиви или опити за търсене на уязвимости (такива като препълване на буфера, сканиране на портове, CGI-атаки, идентифициране на операционната система, идентифициране на версиите на използваните мрежови услуги и други такива). Гъвкавостта и удобството на Snort са основани на следните три фактора: наличие на език за създаване на правила, използван за описване на свойствата на подозрителен и потенциално опасен трафик; механизъм за известяване при откриване на атака; модулна архитектура на кода, анализиращ трафика, основан на концепцията за допълнително включвани модули. Трябва да отбележим, че процедурите, декодиращи мрежовия трафик, работят в каналния през мрежовия и транспортния до приложния слой3. В момента Snort поддържа декодиране за протоколите Ethernet, SLIP и PPP4. Нека разгледаме най-важният от гледна точка на потребителя компонент – езика за създаване на правилата. Правилата се задават в конфигурационния файл на Snort, като техният синтаксис е достатъчно прост: ACTION PROTO IP_ADDR1 PORT1 DIRECTION IP_ADDR2 PORT2 [ (OPTIONS) ACTION Има три основни директиви, определящи последващите действия при откриване на мрежов пакет, отговарящ на някое от правилата – pass, log и alert. Директивата pass означава пакета просто да бъде игнориран. Директивата log определя пакетът да бъде подложен на процедурата за запис, избрана от потребителя за последващ запис в дневника. И последната директива – alert генерира съобщение за открит пакет, който удовлетворява правилото – пак по определен от потребителя начин и след това предава пакета на процедурата за записване в дневника за по-късен анализ. Могат да се използват още две директиви – activate и dynamic. Те позволяват за някакво множество пакети, удовлетворяващи някакво правило да бъде повикано друго правило. Например, може да се наложи при откриване на пакет с явни признаци за атака с препълване на буфера, да се генерира съобщение за атаката и да се запишат в дневника няколко от следващите пакети за последващ техен анализ. Тази функционалност се постига със съвместното използване на директивите activate и dynamic. Освен това, има възможност за създаване на собствени директиви, асоциирайки ги с една или няколко процедури на запис в дневника. Например, определението ruletype redalert { type alert output alert_syslog: LOG_AUTH LOG_ALERT output database: log, mysql, user=snort dbname= snort host= localhost } създава нова директива redalert, генерираща съобщение, което се предава на syslog и записваща след това информацията за открития пакет в база данни MySQL. PROTO В момента, за анализ са достъпни три протокола и съответно, са допустими три значения на този параметър – tcp, udp и icmp. Възможно е в бъдеще да се появи поддръжка и на arp, ipx, igrp, gre, rip, ospf и други. IP_ADDR В Snort няма механизъм за разпознаване на имена (и надали ще се появи някога – от съображения за производителност), затова е необходимо за задаване на хостовете да се използват техните IP адреси. Ключовата дума any позволява задаването на всички възможни адреси, а за задаване на подмрежи се използва CIDR запис. Символът ! обръща обратно условието – !192.168.3.0/24 означава всеки непринадлежащ на подмрежата 192.168.3.0/24 IP адрес. Освен това може да се задават и списъци от адреси, разделяйки ги със запетайка и затваряйки ги в квадратни скоби – например [192.168.2.0/24, 192.169.3.54/32]. PORT Посочването на портовете се извършва по същия начин, както и при ipchains. Освен един единствен порт, може да задаваме и диапазон от портове, като ги разделим с двоеточие, например 6000:6010 – портове от 6000 до 6010 включително, :1024 – всички портове от 1 до 1024, 1024: – всички портове от 1024 до 65535. Както при задаването на IP адресите, символът ! обръща обратно условието, а ключовата дума any означава всички портове. DIRECTION Този оператор позволява да определим посоката на движение на пакета: -> (едностранно) – правилото ще се прилага само върху пакети, идващи от IP_ADDR1 към IP_ADDR2; (двустранно) – направлението на движение на пакета е без значение. OPTIONS Затворените в кръгли скоби параметри са незадължителни части от правилото и в същото време са най-важната част от системата за откриване на нахлуване. Параметрите могат да определят текста на съобщението за заплаха от нахлуване, д задават допълнителни действия при задействане на правилото, както и допълнителни условия за съответствие на анализираните пакети на дадено правило. Параметрите се отделят един от друг с точка и запетая, а ключовата дума на параметъра се отделя от неговия аргумент с двоеточие. До момента съществуват 24 параметъра, като тяхното количество се увеличава с всяка нова версия на програмата. Параметрите, задаващи допълнителни условия на съответствие на правилото са: ttl – задава стойността на полето TTL в заглавието на IP пакета5; tos – задава стойността на полето TOS в заглавието на IP пакета; id – задава стойността на полето за фрагментиране в заглавната част на IP пакета; ipopts – задава стойността на полето на параметрите на IP пакета; fragbits – задава битовете на фрагментация на IP пакета; dsize – задава размера на IP пакета; flags – задава условието за наличие или отсъствие на определени TCP флагове; seq – задава номера на сегмента на TCP пакета в последователността [от TCP пакети]; ack – задава стойността на полето за потвърждение в TCP пакета; itype – задава стойността на полето за тип на ICMP пакета; icode – задава стойността на полето за код на ICMP пакета; icmp_id – задава стойността на полето ICMP ECHO ID в ICMP пакета; icmp_seq – задава [поредният] номер на ICMP ECHO пакета в последователността от пакети; content – задава шаблон за търсене в съдържанието на пакета, а не в неговото заглавие (шаблона може да се задава както в текстов, така и в шестнадесетичен вид); content-list – този параметър е аналогичен на параметъра content, с изключение на това, че списъка с търсените шаблони се взема от файл; offset – използва се съвместно с параметъра content за определяне на изместването в пакета, от където ще се провежда анализ на неговото съдържание; depth – аналогичен е на параметъра offset и определя положението в пакета, до където ще се провежда анализ на съдържанието му; nocase – изключва чувствителността към регистъра на буквите при анализа на съдържанието на пакета; rpc – позволява по-точно задаване на характеристиките на програмните или процедурни извиквания на RPC услугите. Както може да се забележи, изброените параметри позволяват създаването на правила за прехващане практически на всякакви пакети, които могат по някакъв начин да застрашат сигурността на системата. А ако отчетем, че Snort може да прехваща пакети и от каналния слой, то неговото използване е особено интересно на хостове, защитени със защитни стени, тъй като отхвърлените от защитната стена пакети все едно ще попадат в неговото полезрение. Параметрите, стойностите на които имат смисъл при търсене на съответствие на анализирания пакет на всички условия са: msg – съдържа текста на съобщението; logto – задава алтернативен файл за запис в него на съдържанието на пакета; session – този параметър позволява включването на една много интересна възможност на Snort – извличането на потребителските данни от TCP сесия, например за следващ анализ на това, какви команди е въвеждал потребителя по време на telnet сесия; resp – ако пакета отговаря на правилото, тогава Snort ще изпълни едно от посочените действия – например ще затвори връзката, изпращайки TCP-RST пакет към единия от хостовете; react – ще блокира посочените в правилото web сайтове, затваряйки връзките с тях и/или отправяйки предварително написано съобщение към браузъра, от който е предприет опита за достигане на някой от посочените сайтове. По-долу са показани някои примери за създаване на правила. log tcp any any -> 192.168.1.0/24 6000:6010 Съгласно това правило, всички пакети, адресирани до обикновено използваните от системата X Windows портове на хостове от някаква подмрежа ще бъдат записвани в дневника. alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 any (msg:"IDS004 - SCAN-NULL Scan";flags:0; seq:0; ack:0;) Това правило открива опитите за така нареченото NULL-сканиране на портове. alert tcp !192.168.1.45/32 any -> 192.168.1.45/32 80 (msg:"IIS-_vti_inf"; flags:PA; content:"_vti_inf.html"; nocase;) Адресираните към web сървър пакети, съдържащи в себе си обръщение към файла _vti_inf.html се разглеждат като опит за използване на една от уязвимостите на Internet Information Server и ще предизвикат при откриване на такива пакети генериране на съобщение за това събитие, като самият пакет ще бъде записан в дневника. alert tcp any any any 6688 (msg:"Napster Client Data"; flags:PA; content:".mp3"; nocase; resp: rst_all) В случай на откриване на обръщение към Napster сървър, връзката се затваря принудително. Както се вижда, с помощта на Snort може да се организира по-ефективна филтрация на нежелан трафик, отколкото ако се затворят съответните портове с помощта на защитна стена, тъй като имаме възможност да въведем допълнително условие за съдържанието на пакетите. alert tcp any 80 192.168.1.0/24 any (content-list: "adults.txt"; msg: "Not for children!"; react: block, msg;) С това правило се блокира достъпа до web сайтове, адресите на които са описани във файла adults.txt. При откриване на заявка към нежелан сървър, връзката с него се затваря и се генерира съобщение „Not for children!“, което освен към дневника, се насочва и към браузъра. По този начин, Snort може да изпълнява функциите на web филтър. activate tcp !192.168.1.0/24 any -> 192.168.1.0/24 143 (flags: PA; content: "|E8C0FFFFFF|\bin|"; activates: 1; msg: "IMAP buffer overflow!";) dynamic tcp !192.168.1.0/24 any -> 192.168.1.0/24 143 (activated_by: 1; count: 50;) Директивата activate не се отличава по нищо от alert с изключение на това, че в секцията за параметри на правилата на директивата activate винаги присъства правилото activates, предназначено за извикване на друго правило за изпълнение. По този начин могат да се извикват само dynamic правила. Директивата dynamic от своя страна не се отличава по нищо от директивата log. Тя също е предназначена за запис на пакетите в дневника, но има два допълнителни параметъра – activated_by, който асоциира правило dynamic с правило activate и count, който указва какво количество пакети трябва да обработи правилото, тоест колко пакета, следващи след прехванатия пакет трябва да бъдат записани в дневника. Показаното по-горе правило activate анализира пакетите за опити за атака с препълване на буфера и в случай, че открие такъв пакет, извиква правило dynamic, което да запише в дневника следващите 50 пакета. Ако атаката е била успешна, анализирайки след нея този файл, може да се установи какви точно загуби са нанесени. log tcp any any 192.168.1.0/24 23 (session: printable;) Подобно правило винаги е полезно, когато се налага да запазим в дневника в четлив вид всичко, което въвежда или вижда потребителя по време на telnet, ftp, rlogin или даже web сесия. На сайта http://www.snort.org/ има създаден набор от готови правила, който може да използваме за свои собствени цели, като правилата са разделени на няколко групи: BackDoor Activity; BackDoor Attempts; Backdoor Sig. Based; Exploits; Finger; FTP; ICMP; MISC; NetBios; RPC; Rservices; Scans; SMTP; Sysadmin; TELNET; Virus - SMTP Worms; Web-CGI; Web-ColdFusion; Web-FrontPage; Web-IIS; Web-Misc. Както се вижда от наименованията на групите, областта на приложение на Snort е много широка. За да не се изчаква обновяването на набора правила след публикуването на нов, много опасен експлойт, може много бързо самостоятелно да се състави ново правило. За това е нужно да намерим в Internet експлойта, да го използваме срещу хост – опитно зайче, като запишем целия трафик между атакуващият хост и хоста-жертва. След това, анализирайки дневника е необходимо да намерим уникална сигнатура на експлойта. Например, в следващия пакет 052499-22:27:58.403313 192.168.1.4:1034 -> 192.168.1.3:143 TCP TTL:64 TOS:0x0 DF ***PA* Seq: 0x5295B44E Ack: 0x1B4F8970 Win: 0x7D78 90 90 90 90 90 90 90 90 90 90 90 90 90 90 EB 3B ...............; 5E 89 76 08 31 ED 31 C9 31 C0 88 6E 07 89 6E 0C ^.v.1.1.1..n..n. B0 0B 89 F3 8D 6E 08 89 E9 8D 6E 0C 89 EA CD 80 .....n....n..... 31 DB 89 D8 40 CD 80 90 90 90 90 90 90 90 90 90 1...@ ........... 90 90 90 90 90 90 90 90 90 90 90 E8 C0 FF FF FF ................ 2F 62 69 6E 2F 73 68 90 90 90 90 90 90 90 90 90 /bin/sh......... редът /bin/sh/ явно изглежда подозрителен. По този начин, този ред и няколкото байта преди него ще представляват сигнатурата на експлойта и новото правило за Snort ще изглежда примерно по този начин: alert tcp any any -> 192.168.1.0/24 143 (content:"|E8C0 FFFF FF|/bin/sh"; msg:"New IMAP Buffer Overflow detected!";) ВЪЗМОЖНОСТИ ЗА РАЗШИРЕНИЕ НА SNORT В състава на пакета Snort влизат както спецификации, така и препоръки за разработването на допълнителни модули, предназначени за странични автори. В момента Snort подържа три вида допълнителни модули – детектори, препроцесори и модули за извеждане на информация. Детекторите са предназначени за откриване на някакъв уникален аспект на пакета, като по този начин разширяват набора от възможни параметри, определящи условията за съответствие на правилата. Например, параметъра flags, задаващ условията за наличие или отсъствие в пакета на конкретни TCP флагове, е реализиран с помощта на откриващ модул. Препроцесорът се извиква за изпълнение след декодирането на пакета и преди изпълнението на детектора. Чрез неговия механизъм е възможно да модифицираме пакетите, например за повторно събиране на TCP потока, за дефрагментация на пакетите, за нормализация на HTTP заявките, като е възможен и допълнителен анализ извън основния код, както е възможно и изпълнението на задачи за събиране на статистика. В частност, процедурата за определяне дали се осъществява сканиране на портовете е реализирана именно с помощта на препроцесор. Под „сканиране на портове“ този препроцесор разбира изпращането от един и същ IP адрес на SYN-, FIN-, NULL-, SYNFIN- или XMAS пакети към контролирания хост на повече от P порта, за време по-малко от T или към един порт едновременно на няколко хоста. Следващите версии на Snort ще могат да откриват и разпределено сканиране на портове, когато пакетите към сканираните хостове се изпращат от няколко атакуващи хоста. Ползата от този препроцесор е в това, че при откриване на атака няма нужда да се генерира съобщение за всеки пакет, а може да се генерира едно единствено съобщение за цялата атака. Много интересен модул е препроцесорът SPADE на фирмата Silicon Defence. SPADE е абревиатура на Statistical Packet Anomaly Detection Engine – Система за откриване на статистически аномални пакети. Този модул е част от проекта SPICE (Stealthy Portscan and Intrusion Correlation Engine)6. Spade следи трафика, открива пакетите, които съгласно някакви статистически критерии се приемат за аномални и предава информацията за тях на процедурата за запис в дневника. Отделянето на аномалните пакети може да става по следния примерен начин: на всеки пакет се дава оценка за неговата аномалност, основана на историята на прегледания трафик. За тази цел се създава таблица с оценките на вероятността за поява на различните видове пакети, основана на честотата им на поява за известен период от време и времето на поява (на по-свежите пакети се присвоява по-голямо тегло). Например, за web сървър P(dip=198.168.1.1, dport=80)= 0.3 и P(dip=198.168.1.1, dport=12543) =0.001. Оценката на аномалността се пресмята непосредствено от вероятността за поява на пакета: A(X)= -log2(P(X)) По този начин, аномалността на пакет, насочен към порт 80 на хост 198.168.1.1 ще бъде 1,737, а аномалността на пакет, насочен към порт 12543 на същия хост ще е 9,97. Колкото е по-висока оценката на аномалността на пакета, толкова повече внимание заслужава той, като при надхвърляне на някакъв праг се генерира съобщение за подозрителен пакет, а в перспектива информацията за него ще се подава и към така наречения portscan-корелатор за последващ анализ и откриване на добре маскирани атаки. От версия 1.7 е възможно едновременното използване за извеждане на информация на няколко допълнителни модула: alert_syslog – този модул, както се вижда от името му, извежда информация в дневника през демона syslog. Съществува възможност да се настрои нивото на записване и приоритета на съобщенията; alert_fast – извежда в посочен файл информация за възможна атака в кратък, едноредов формат; alert_full – същото, както при alert_fast, но в посочения файл се записва и прехванатия пакет. Добра идея е полученият по този начин файл да бъде преглеждан с помощта на perl скрипта SnortSnarf на вече споменатата фирма Silicone Defense. Резултатът от работата на скрипта е много подробен и удобен за използване отчет7; alert_unixsock – същото, както при alert_full, но цялата информация се предава в друг процес през Unix-сокет. С този модул може лесно да бъде организирана активна реакция на системата срещу провежданата атака, например блокиране на атакуващия хост в таблицата за маршрутизация или чрез промяна във веригите на ipchains; alert_smb – изпраща съобщение за атаката по протокол WinPopup на описаните NETBIOS-хостове; log_tcpdump – записва прехванатите пакети във файл с формата на програмата tcpdump; database – много интересен модул, позволяващ съхраняването на цялата информация за прехванатите пакети в база данни. В момента се поддържат базите данни PostgreSQL, MySQL, Oracle, а също така и ODBC-съвместими бази данни8. На основата на информацията, запазена в базата данни, е много удобно да се създадат различни отчети, например, за най-досадните атакуващи хостове, за типични атаки, за най-вероятното време за провеждане на атаките и други такива; XML – този модул беше разработен в координационния център CERT като част от проекта AIRCERT. Неговата основна цел е създаване на цяла инфраструктура за откриване на прониквания вътре в локална мрежа, където стартираните на няколко компютъра копия на Snort изпълняват ролята на сензори9. От всичко, казано по-горе, може да направим извода за изключително голямата полезност на програмата Snort. Във всеки случай, използването на тази програма ще направи живота на кракерите по-труден, което е една от целите на всеки системен администратор. Превод: Николай Ангелов 1 IDS – Intrusion Detection Systems. 2 Martin Roesh e автор на програмата. 3 Каналният, мрежовият, транспортният и приложният слой са части от модела OSI, който представлява общ комуникационен модел по отношение на различните нива на комуникация със седем слойна структура. 4 Нека не забравяме, че това е положението към 2001 г. В момента, към датата на превод на статията, актуална е версия 2.3.0RC2. За изминалите четири години, нещата, описани в статията може да са се променили, като точното място за повече информация е http://www.snort.org/. 5 Описание на заглавната част на един IP пакет може да се намери там – http://www.networksorcery.com/enp/protocol/ip.htm, както и на много други места в мрежата. 6 Пълна информация за който може да се намери на адрес http://www.silicondefense.com/pptntext/spice-ccs2000.pdf. 7 Пример на такъв отчет може да се намери на този адрес – http://www.silicondefense.com/snortsnarf/example 8 За повече информация може да погледнете на този адрес: http://www.snort.org/dl/binaries/linux/ 9 Пълна информация за този модул може да се намери на адрес http://www.cert.org/kb/snortxm << Нелегитимен достъп до ресурси (уеб-базирани пощенски услуги) | Promqna firmware-a na Linksys WRT54G s Linux >>

Коментари: (общо 0)	Оценени с -1 0 1 2 3 4 5 или повече
[Добави коментар]