|
|
|
СЪВЕТИ
|
Адаптивна защитна стена
|
|
|
|
|
|
от Vladsun(5-06-2007)
рейтинг (31)
[ добре ]
[ зле ]
Вариант за отпечатване 1. Въведение
Адаптивност наричаме онова свойство на обектите, което позволява техните реакции да се променят с течение на времето при едни и същи входни условия. Адаптивността е тясно свързана с понятието "памет". Без да имаме памет не можем да имаме адаптивност.
В областта на ИТ и по специално при изграждането на защитни стени (firewall) понятието памет се свързва с други два английски термина - stateful и stateless. В тази тясна област тези термини са по-скоро свързани със следенето на пакетите за всяка връзка и съответстващия й протокол (connection tracking).
В тази статия ще опиша няколко приложения на "адаптивните" защитни стени - това са тези стени, които освен следенето на отделните връзки и свързаните с тях действия в краткосрочен план, могат да променят своите действия в зависимост от получените пакети в по-дългосрочен план. Адаптивността при тези стени обикновено се проявява в отказ на достъп до една, няколко или всички услуги на защитаваната машина при установяване на атака. Отказът на достъп е само към атакуващия, докато всички останали легитимни потребители могат безпроблемно да ползват тези услуги.
Реализираната в тази статия адаптивна защитна стена има три нива на защита - първото ниво е обработката на всеки пакет сам за себе си (stateless), второто ниво е адаптивна защита на всяка една отделна услуга на машината или от конкретна атака и третото ниво е адаптивна защита чрез отказ на достъп до абсолютно всички портове на машината.
2. Реализация
Всеки пакет с източник определен хост в реализираната от мен защитна стена може да се определи като:
"бял" - пакетът достига крайното си предназначение;
"сив" - пакетът не достига крайното си предназначение, ако то се счита за атакувано, но достига до останалите, ако те не са атакувани;
"черен" - пакетът се отхвърля автоматично независимо от предназначението си.
"Сивите" пакети са онези пакети, които са изпратени от идентифициран като "атакуващ" хост и са предназначени за определена услуга (порт) - те биват отхвърляни. В същото време обаче пакетите от "атакуващия" хост, които са предназначени към други услуги (портове) биват пропускани от ЗС.
"Черните" пакети, са онези пакети, които са изпратени от идентифициран като "атакуващ" хост, като такава идентификация е станала повече от един път в рамките на определен (прим. 3 мин.) период от време.
По-долу е показан сорс кода (bash) на такава защитна стена. Ще разделя сорса на части и ще обясня предназначението на всеки един от тях. Избраната схема на действия за тази стена са RETURN-DROP, което означава, че може да се избере всякаква политика по подразбиране.
Използвани са следните iptables модули и изискваните от тях:
set, recent, hashlimit, connlimit, limit, LOG
2.1. Инициaлизация
Примерен код |
/sbin/modprobe ipt_recent ip_list_tot=1000
ipt="/usr/local/sbin/iptables"
ips="/usr/local/sbin/ipset"
for TABLE in filter nat mangle; do
$ipt -F -t $TABLE
$ipt -X -t $TABLE
$ipt -Z -t $TABLE
done
$ips -F
$ips -X
if [ "$1" == "stop" ]
then
echo
echo "Stopping firewall..."
echo
exit
fi
$ips -N WL iphash
$ips -A WL 127.0.0.1
$ips -A WL 192.168.0.1
$ips -N WLN nethash
$ips -A WLN 192.168.0.0/24 |
Дотук "изчистихме" таблиците на iptables и ipset. Също така съставихме списъци с доверени хостове и мрежи.
2.2. Адаптивен тотален филтър
Примерен код |
$ipt -A INPUT -m recent --name banned-hosts --update --seconds 36000 -j DROP
$ipt -N BANNED
$ipt -A BANNED -m limit --limit 1/s --limit-burst 1 -j LOG
$ipt -A BANNED -m recent --name banned-hosts --set -j RETURN
$ipt -N ADAPT
$ipt -A ADAPT -m limit --limit 1/s --limit-burst 1 -j LOG
$ipt -A ADAPT -m recent --hitcount 2 --name watch-hosts --update --seconds 180 -j BANNED
$ipt -A ADAPT -m recent --name watch-hosts --set -j RETURN |
Вижда се, че всички пакети минават през:
Примерен код |
$ipt -A INPUT -m recent --name banned-hosts --update --seconds 36000 -j DROP |
Т.е. ако хостът се намира в recent таблицата "banned-hosts", то всички негови пакети ще бъдат отхвърляни, като всеки един негов пакет ще започва нови 3600 секунди (1 час) на отхвърляне. Как попада даден хост в този списък - нужно е да е постъпил негов пакет във веригата BANNED, което от своя страна изисква да са постъпили поне 2 пакета (т.е. "сиви") на атакуващия във веригата ADAPT и то за не повече от 180 сек. (3 мин.). Както ще се види по-долу пакетите, които постъпват във веригата ADAPT са такива, които са идентифицирани като започващи атака към дадена услуга. С други думи казано, ако злонамереният хост атакува една услуга повече от два пъти или атакува повече от една услуга за за време по-малко от 3 мин., то той ще бъде включен в списъка "banned-hosts" и всички негови пакети (т.е. "черни") ще бъдат отхвърляни за поне един час.
2.3. Пакетен филтър
Примерен код |
$ipt -A INPUT -p icmp -d 0.0.0.255/0.0.0.255 -j DROP
$ipt -A INPUT -p tcp --tcp-option 128 -j DROP
$ipt -A INPUT -p tcp --tcp-option 64 -j DROP
$ipt -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
$ipt -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
$ipt -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$ipt -A INPUT -m state --state INVALID -j DROP
$ipt -t mangle -A PREROUTING -i eth+ -s 172.16.0.0/16 -j DROP
$ipt -t mangle -A PREROUTING -i eth+ -d 172.16.0.0/16 -j DROP
$ipt -t mangle -A PREROUTING -i eth+ -d 192.168.0.0/16 -j DROP
$ipt -t mangle -A PREROUTING -i eth+ -s 192.168.0.0/16 -j DROP
$ipt -t mangle -A PREROUTING -i eth+ -s 10.0.0.0/8 -j DROP
$ipt -t mangle -A PREROUTING -i eth+ -d 10.0.0.0/8 -j DROP
$ipt -t mangle -A PREROUTING -i ! lo -s 127.0.0.0/8 -j DROP
$ipt -A INPUT -p icmp --icmp-type timestamp-request -j DROP
$ipt -A OUTPUT -p icmp --icmp-type timestamp-reply -j DROP
$ipt -A INPUT -i ppp+ -j ACCEPT
$ipt -A OUTPUT -o ppp+ -j ACCEPT
$ipt -A INPUT -i lo -j ACCEPT |
Тази част от защитната стена е класическа и няма нужда от коментар.
2.4. Обща защита
Защитата в следващите части е реализирана приблизително по един и същ начин:
създаване на верига, в която да влизат пакетите с определен признак;
ако пакетът е от хост идентифициран като атакуващ в определен времеви интервал (60 сек.) се отхвърля (и се излиза от веригата);
ако пакетът не се счита за атакуващ се излиза от веригата (т.е. НЕ се отхвърля);
ако пакетът се счита за атакуващ се запомня хоста от който е изпратен, като в същото време се сигнализира за проведена атака от този хост в ADAPT веригата;
пакетът се отхвърля;
Примерен код |
$ipt -N PSD
$ipt -A INPUT -m recent --name PSD --update --seconds 60 -j DROP
$ipt -A INPUT -m psd --psd-weight-threshold 10 --psd-delay-threshold 200 -j PSD
$ipt -A PSD -m set --set WL src -j RETURN
$ipt -A PSD -m recent --name PSD --set -j ADAPT
$ipt -A PSD -j DROP |
Използва се допълнението към iptables - модулът psd. Особеното тук е, че блокът не следва съвсем точно гореописаната последователност. Причината е, че psd match-a директно определя пакетът като атакуващ, а не да го разграничава по признак. Показаните по-долу части следват тази последователност.
Ето го и подробното обяснение:
ред #1. Създаване на веригата PSD
ред #2. Всеки пакет се проверя за това дали източникът му е в списъка със забранен достъп към тази услуга и ако е, се отхвърля, като започват нови 60 сек. време на отхвърляне;
ред #3. Проверява се дали пакетът принадлежи към сканираща поредица - ако да, то пакетът се изпраща към веригата PSD. Ако не, то пакетът продължава нататък без последствия.
ред #4. Проверява се дали пакетът идентифициран като сканиращ принадлежи на хост от списъка на доверените хостове.
Ако да - излиза се от веригата и пакетът продължава нататък без последствия. Ако не, то пакетът продължава към следващото правило във веригат PSD.
ред #5. Източникът на пакета и времето, в което той е пристигнал се записват в recent таблицата PSD. След това пакетът се изпраща към ADAPT веригата, с което се реализира описаната по-горе адаптивна защита на машината.
ред #6. Пакетът се отхвърля, тъй като е идентифициран като атакуващ.
Показаните по-долу части следват подобна логика.
Примерен код |
$ipt -N syn-flood
$ipt -A INPUT -p tcp --syn -j syn-flood
$ipt -A syn-flood -m set --set WL src -j RETURN
$ipt -A syn-flood -m recent --name syn-flood --update --seconds 60 -j DROP
$ipt -A syn-flood -m hashlimit --hashlimit 1/s --hashlimit-burst 50 --hashlimit-mode srcip --hashlimit-name syn-flood -j RETURN
$ipt -A syn-flood -m recent --name syn-flood --set -j ADAPT
$ipt -A syn-flood -j DROP
$ipt -N port-scan
$ipt -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j port-scan
$ipt -A port-scan -m recent --name port-scan --update --seconds 60 -j DROP
$ipt -A port-scan -m hashlimit --hashlimit 1/s --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name port-scan -j RETURN
$ipt -A port-scan -m recent --name port-scan --set -j ADAPT
$ipt -A port-scan -j DROP
$ipt -N PoD
$ipt -A INPUT -p icmp --icmp-type echo-request -j PoD
$ipt -A PoD -m set --set WL src -j RETURN
$ipt -A PoD -m set --set WLN src -m limit --limit 50/s --limit-burst 60 -j RETURN
$ipt -A PoD -m recent --name PoD --update --seconds 60 -j DROP
$ipt -A PoD -m length --length 128: -m hashlimit --hashlimit 1/s --hashlimit-burst 1 --hashlimit-mode srcip --hashlimit-name PoD -j RETURN
$ipt -A PoD -m hashlimit --hashlimit 5/s --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name PoD -j RETURN
$ipt -A PoD -m recent --name PoD --set -j ADAPT
$ipt -A PoD -j DROP |
2.5. Защита по услуги
Логиката на изпълнение е същата като в горните защити, но с тази разлика, че пакетът в края не се отхвърля, тъй като принадлежи към не атакуваща поредица.
Примерен код |
$ipt -N MAIL
$ipt -A INPUT -p tcp --dport 25 --syn -j MAIL
$ipt -A INPUT -p tcp --dport 143 --syn -j MAIL
$ipt -A MAIL -m set --set WL src -j RETURN
$ipt -A MAIL -p tcp -m connlimit --connlimit-above 2 --connlimit-mask 32 -j REJECT
$ipt -A MAIL -m recent --hitcount 2 --name mail --update --seconds 60 -j DROP
$ipt -A MAIL -m recent --name mail --update --seconds 60 -j RETURN
$ipt -A MAIL -m recent --name mail --set -j ADAPT
$ipt -N SSH
$ipt -A INPUT -p tcp --dport 22 --syn -j SSH
$ipt -A SSH -m set --set WL src -j RETURN
$ipt -A SSH -p tcp -m recent --hitcount 2 --name SSH --update --seconds 60 -j DROP
$ipt -A SSH -p tcp -m recent --name SSH --update --seconds 60 -j RETURN
$ipt -A SSH -m recent --name SSH --set -j ADAPT
$ipt -N FTP
$ipt -A INPUT -p tcp --dport 21 --syn -j FTP
$ipt -A FTP -m set --set WL src -j RETURN
$ipt -A FTP -m set --set WLN src -j RETURN
$ipt -A FTP -p tcp -m recent --hitcount 2 --name FTP --update --seconds 60 -j DROP
$ipt -A FTP -p tcp -m recent --name FTP --update --seconds 60 -j RETURN
$ipt -A FTP -m recent --name FTP --set -j ADAPT |
3. Заключение
Показана беше реализацията на адаптивна защитна стена, която е способна да изолира атакуващия хост за относително дълъг период от време - от няколко минути до няколко часа (или дни !!!). Защитата е доста агресивна и поради това трябва да се изберат подходящи за вашите случаи параметри - времена на отказ, брой попадения за отказ и т.н.
В заключение ще кажа, че вместо DROP може да се използват други, по-интересни действия - TARPIT, MIRROR ;). Тези действия предизвикват обратна атака към атакуващия, вместо да го игнорират.
EDIT: При мен съм направил и set nethash от мрежовите префикси в българското пространство и отказвам достъп до SSH и FTP услугите в случай, че хостът не е сред тях.
За "пълнене" на списъка използвам:
Примерен код |
$ips -N BG_NETS nethash
for i in `cat /usr/local/router/data/bgnets`; do
$ips -A BG_NETS $i
done |
Тогава блоковете за управление на достъпа до SSH и FTP изглеждат по следния начин:
Примерен код |
$ipt -N SSH
$ipt -A INPUT -p tcp --dport 22 --syn -j SSH
$ipt -A SSH -m set --set WL src -j RETURN
$ipt -A SSH -m set ! --set BG_NETS src -j REJECT
$ipt -A SSH -p tcp -m recent --name SSH --update --seconds 60 -j DROP
$ipt -A SSH -m recent --name SSH --set -j ADAPT
$ipt -N FTP
$ipt -A INPUT -p tcp --dport 21 --syn -j FTP
$ipt -A FTP -m set --set WL src -j RETURN
$ipt -A FTP -m set --set WLN src -j RETURN
$ipt -A FTP -m set ! --set BG_NETS src -j REJECT
$ipt -A FTP -p tcp -m recent --name FTP --update --seconds 60 -j DROP
$ipt -A FTP -m recent --name FTP --set -j ADAPT |
<< Инсталиране на Beryl под Mandriva Linux 2007 | Процеси в ГНУ/Линукс >>
|
|
|
|
|
Въпрос От: run_time На: 31-05-2007@5:50 GMT+2 Оценка: 1/НеутраленИзвинявам се, че не е по темата, но как ги правите тези текстове на жълт фон :-)
Иначе статията е 6+
[Отговори на този коментар]
Към: Въпрос От: Vladsun <vsmin< at >mail __точка__ bg> На: 31-05-2007@11:53 GMT+2 Оценка: 1/НеутраленНад полето за въвеждане на текст имаш едно падащо меню - "G+" ;)
[Отговори на този коментар]
typo От: byte На: 31-05-2007@7:19 GMT+2 Оценка: 1/Неутрален"тях му отказвам достъп до SHH и FTP"
[Отговори на този коментар]
Към: typo От: Vladsun <vsmin (a) mail[ точка ]bg> На: 31-05-2007@11:47 GMT+2 Оценка: 1/Неутрален...
Редактиран на: 31-05-2007@13:35
[Отговори на този коментар]
поздравления От: Rumen_Yotov <rumen (a) qrypto__dot__org> На: 1-06-2007@4:02 GMT+2 Оценка: 1/НеутраленПрекрасна статия, от всякаква гледна точка.
Румен
[Отговори на този коментар]
Към: поздравления От: Тошко На: 1-06-2007@15:14 GMT+2 Оценка: 1/НеутраленПоздравления и от мен! Чудесна работа!
[Отговори на този коментар]
А за това сетихте ли се бе? От: bat'Serjo На: 2-06-2007@15:08 GMT+2 Оценка: 1/НеутраленЯкоо, желязнооо. Сега всеки ламер който си сложи подобна "защитна стена" си отваря следната БЪГО-ДУПКА. Аз като един зъл факер не мога да не забележа лекотата с която се решава що е добро и що е зло в случая. Говорвя за следното (сега да не копи-пастевам безмислено погледнете кода на баш скрипта) # Syn-flood protectioн и # Ping of death . От тези редчета веднага в болния ми мозък се заражда подлата идейка да почна да бълвам пакетчета със спуфнат източник попадащи точно в тези редчета на файЪр ВоЛа. Сештате ли се какво ще стане тогава. Елементарно Вотсън! Грешника чието ип съм използвал за източник автоматично губи достъп до сървъра с тази невероятно велика стена. Сега я да напрайм една бабешка сметка.
Ако Пешо злия хакер бълва по 60 (аре че по лени сметките да са) пакетчета в секунда, и на тази стеничка и трябват 2 пакета да реши че някой е много зъл хакер и да му резне достъпа, това ша рече че за секунда бай Пешо ще изреже достъпа на 30 хоста до въпросното сървърче. Сега за да държи бай Пешо нещастниците който той си е набелязал далеч от сървърчето, след 1 час той пак тряба да прати 2 пакетчета. Така това демек ша рече че периода е 1 час. (1*60*60)*30 = 108000 хоста. Демек бай ви Пешо спокойно може да резне 108000 хоста към даден сайт ако той има подобна базикня за защитна стена. И при това на бай ви Пешо ша му е през оная работа за 60-те пакета на секунда, сещате се нали.
П.С. за тези дето сега ша ми кажат че спуфа е от едно време и вече не съществува, само да им наблегна на следното. За да ви изреже стената ви трябва syn или icmp пакет а не усъществена връзка. Демек проблема е никакъв.
[Отговори на този коментар] Към: А за това сетихте ли се бе? От: Vladsun <vsmin __@__ mail[ точка ]bg> На: 4-06-2007@8:36 GMT+2 Оценка: 1/Неутрален... вече почвам да се плаша колко хора имат възможността да spoof-ват IP адреси... БЕ!
ПП: Ако си беше направил труда да прочетеш всичките коментари ...
ППП: До всички с DoS параноята:
Вместо DROP в
$ipt -A INPUT -m recent --name banned-hosts --update --seconds 36000 -j DROP
сложете правило за random или n-th match + DROP
Редактиран на: 4-06-2007@8:59
[Отговори на този коментар] Към: А за това сетихте ли се бе? От: nigger На: 4-06-2007@14:17 GMT+2 Оценка: 1/НеутраленМи предложи как да стане бе!
п.п. Аз никъде не можах да намеря един пълен скрипт с всичко необходимо за коректно работещ файъруол. Този ми се струва доста завършен. Не разбирам защо всеки сам трябва да открива топлата вода! Нали идеята е да се споделя с другите?!
[Отговори на този коментар] Към: А за това сетихте ли се бе? От: mitio На: 1-02-2010@11:11 GMT+2 Оценка: 1/НеутраленДо:bat'Serjo
Да.
Някои хора са се сетили, г-н bat'Serjo,
recent има възможност за следене на TTL (--rttl опция)
"This may be useful if you have problems with people faking their source address in order to DoS you via this module by disallowing others access to your site by sending bogus packets to you."
(за повече информация: Netfilter Extensions HOWTO, # 3.16 recent patch )
Вярно, че би могъл да си смениш TTL на source-а, но това значи да имаш много повече знания за входящия трафик на машината. А ако наистина имаш тези знания/възможности, то Syn-flood, "Ping of death" е най-малкото което можеш да направиш.
До: Vladsun, Благодаря за статията. Добър източних на knowhow е :).
[Отговори на този коментар]
Промени От: Vladsun <vsmin (a) mail[ точка ]bg> На: 5-06-2007@14:02 GMT+2 Оценка: 1/НеутраленНаправени са малко промени по скрипта за да се отстрани по-ранното (фалшиво) детектиране на атака към сърверните услуги (FTP, SSH, MAIL).
Редактиран на: 5-06-2007@14:05
[Отговори на този коментар] Към: Промени От: Боби На: 20-07-2007@8:37 GMT+2 Оценка: 1/НеутраленЗдравейте,
На мен ми връща следната грешка:
FATAL: Module ip_set not found.
ipset v2.2.9a: Error from kernel: Protocol not available
FATAL: Module ip_set not found.
ipset v2.2.9a: Error from kernel: Protocol not available
FATAL: Module ip_set not found.
ipset v2.2.9a: Error from kernel: Protocol not available
FATAL: Module ip_set not found.
ipset v2.2.9a: Error from kernel: Protocol not available
FATAL: Module ip_set not found.
ipset v2.2.9a: Error from kernel: Protocol not available
FATAL: Module ip_set not found.
ipset v2.2.9a: Error from kernel: Protocol not available
FATAL: Module ip_set not found.
ipset v2.2.9a: Error from kernel: Protocol not available
iptables v1.3.6: Couldn't load match `psd':/lib/iptables/libipt_psd.so: cannot open shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.3.6: Problem when communicating with ipset, errno=92.
iptables v1.3.6: Problem when communicating with ipset, errno=92.
iptables v1.3.6: Problem when communicating with ipset, errno=92.
iptables v1.3.6: Problem when communicating with ipset, errno=92.
iptables v1.3.6: Problem when communicating with ipset, errno=92.
iptables: No chain/target/match by that name
iptables v1.3.6: Problem when communicating with ipset, errno=92.
iptables v1.3.6: Problem when communicating with ipset, errno=92.
iptables v1.3.6: Problem when communicating with ipset, errno=92.
Посъветвайте ме какво да правя!
Благодаря предварително!
Поздрави!
[Отговори на този коментар]
Към: Към: Промени От: Vladsun <vsmin (a) mail __точка__ bg> На: 22-07-2007@11:04 GMT+2 Оценка: 1/Неутраленmodpobre ipt_set
преди да пуснеш ЗС.
Явно не си пачнал кернела за PSD ...
[Отговори на този коментар]
Два въпроса и от мен От: Abadon <computer_service< at >abv__dot__bg> На: 29-08-2007@13:11 GMT+2 Оценка: 1/НеутраленЗдравейте.
Имам следните две питания. Първото е този файл /usr/local/router/data/bgnets какво го създава и подържа? Явно има някакъв друг скрипт, който описва бг мрежите в него...
И втория ми въпрос е мога ли и ако да как да си създам защита по услуги за определен порт на който работи ktorrent. Смисъл каква трябва да се проверява и т.н.
Предварително благодаря!
[Отговори на този коментар]
|
|
|
|
|
|
|
|