Изпечатай

[Radev]

Аз имам един въпрос: Кога и как се ползва REJECT?
Искам да огранича всичко (е, почти всичко ) и в двете посоки, но не искам да изглежда, че ме няма, а просто, че не искам да приема обаждането.

[emagi]

VladSun,gat3way погледнете този скрип тук:
http://store2.data.bg/pwizard/rc.firewall.2
Особено искам да обърнете внимание на FORWARD policy
Правя го стъпка по стъпка,но нещо не става.
Това е дадено от моят учител - системен администратор,и забелязвам че както каза VladSun защитата е повече локална мрежа -->Интернет,отколкото Internet -->local net

[Hapkoc]

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

iptables -A INPUT -j REJECT

По този начин реално никога не се изпълнява политиката на веригата (която си я оставям на DROP), а всички пакети, за които няма изрично правило се обработват от последното REJECT правило.


Ако някой, който има повече опит с iptables забележи някакъв проблем с тази схема ще се радвам да ме осветли. :)

[gat3way]

REJECT трябва да се използва в повечето случаи, DROP не е особено културен вариант, защото не се връща някаква грешка. Аргументите за използването на DROP по принцип са че било забавяло разни port scanner-и, което е пълна глупост, първо защото ги пишат multithreaded, второ, защото това от гледна точка на скенера със сигурност означава че този порт е "филтриран". Aко филтрираш една услуга по начин, по който да връща ICMP PORT UNREACHABLE грешка вместо да дроп-ва пакети, то за злия хахор ще е най-малкото интересен въпроса дали наистина няма такава услуга или има и е филтрирана, нещо което се установява с малко по-сложни методи от "nmap victim_host"  все пак '>

DROP е по-удобен вариант единствено за натоварени рутери, където няма особен смисъл да затормозяваш машината да ти генерира ICMP грешки, особено ако някой малоумник се опитва да те DoS-ва. Връщайки грешките единствено ще постигнеш amplification ефект, а при положение че малоумника те flood-и със пакети с подправен източник, става верно глупаво.

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

Не използвай DROP по възможност. Особено за употреби различни от домашните ви (защото признавам си на домашния си рутер имам 2-3 такива правила). Просто няма смисъл. В повечето случаи спестяваш някакъв  малък процент от bandwidth-a, както и от CPU usage, за неща които не си заслужават усилието. Също така не се престаравай със state match правилата, за които онези лекции толкова адвокатстват - файдата е главно в някои частни случаи, за които ако не знаеш,  няма смисъл въобще от цялото упражнение. Също така ще ми е интересно да си поговоря с автора на тези лекции, ще споделите ли кой е той и как мога да се свържа с него '>)

[VladSun]

@emagi Аз лично не ползвам политиката по подразбиране да е DROP/REJECT. Вместо това, предпочитам стената да ми е със следната структура за всяка верига:

0. -P ACCEPT
1. Всякакъв вид защити (port-scann, syn-flood, etc.) завършват със DROP (!'> или излизат с RETURN
2. ACCEPT на нещата, които наистина искам да приемемам.
3. И най-накрая -j REJECT

Съветвам те да разгледаш няколко защитни стени и лека-полека, правило по правило да добавяш и да гледаш какво става заедно със всички  "странични" ефекти.

@Radev, Hapkoc, gat3way

Както писах по-горе, при сработване на каквато и да е от защитите правя DROP (рядко TARPIT, а още по-рядко (само за експерименти) и MIRROR '> ), а не REJECT - не обичам да съм "вежлив" с хахорите '>. И то най-вече именно заради причните изтъкнати от gat3way.
За "нормалните" пакети си отказвам в най-вежлива форма - с REJECT '>

Иначе, наистина има спор за DROP/REJECT, но пак е само за злонамерени пакети - въпросът е кое от двете забавя/спира/отказва атаката, но това май зависи само от мнението на хахора '>

ПП: Силно препоръчвам да НЕ се използва -I правила ... ще се "изгубиш" в собствената си защитна стена. Същото се отнася и за GOTO ...

[gat3way]

Hapkoc, иначе по принцип защо не можеш да слагаш policy различен от DROP/ACCEPT е въпрос за съжаление на организация на netfilter кода в ядрото. Сигурно изглежда въпрос на недоглеждане, може и така да е. Преди време ми беше интересно да разглеждам кода на netfilter и iptables, някои неща ми изглеждаха странни тогава, Vladsun по-скоро имаше вземане-даване с тези неща и сигурно е по-запознат от мен. За мен лично проблематиката беше покрай моите бъгливи модули свързани с  netfilter hooks (leds, nfstats), за Vladsun покрай неговия flattc модул.

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

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

[VladSun]

ПП:
Сега забелязах едни кофти правила в защитната стена от линка:

-j LOG --log-prefix "Spoofed source IP"

Няма -m limit match, и при flood с пакети syslogd ще напълни log-овете с мноооогоо съобщения ...

[Radev]

Момчета, много ви благодаря за културния тон на дискусията и разбираеми език, а също и за самите отговори! '>

Имам още един въпрос: Възможно ли е, при два външни интерфейса, с помощта на netfilter да се насочват изходящите пакети към интерфейса, през който първоначално започнати връзките?
Имам в предвид работа с nat и пренасочване на портове към вътрешната мрежа при два реални, външни IP адреса, които трябва да не използват default gw-я на рутера.

Надявам се да зададах ясно въпроса. '>

[laskov]

IPRoute2

[VladSun]

С netfilter:
виж ROUTE target-a

[teh]

REJECT policy на веригите? мне!
Ще счупите (или по скоро връщате грешни съобщения) icmp протокола. Защото ако имаш policy REJECT или -A INPUT -j REJECT на края на правилата си - по подразбиране ще върнете "port-unreachable" на всеки пакет стигнал до това правило или policy (а това едва ли ще отговаря на истината всеки път).

Не съм се интересувал дали това е официалния отговор на netfilter разработчиците но за мен е достатъчно условие.

По добре е "тихо"  да DROP-нете пакета или пък да ползвате ACCEPT policy по подразбиране и да оставите icmp протокола сам да си свърши работата (надяваме се, че не сте го филтрирали и него, както някои знайни и не знайни герои).

VladSun,
със този MIRROR target срещу "лошите" сещаш ли се как можеш да станеш на някой spoofer decoy-a?
Също така срещу т.нар. syn flood атаки отдавна съществува /proc/sys/net/ipv4/tcp_syncookies

[teh]

Този форум защо работи в друга часова зона? '>

[VladSun]

Не съм много съгласен с теб - ICMP връщаните отговори не е нужно да отговарят на истината '> Въпросът е как ще реагира клиента отсреща ... DROP политиката е още по-"чупеща", а вариантът за ACCEPT, предложен от теб, е неприемлив.

А по отношение на MIRROR - действа отлично срещу script-kiddies атаки '> В 99% от случаите атакуващият няма да може да spoof-не ИП адрес ... а и както казах го ползвам при експерименти '> т.е., когато изрично сложа това правило за някое атакуващо ИП по време на неговата атака и го гледам какво прави в реално време '>

За syn-flood отдавна използвам tcp_syncookies, но, както предполагам знаеш, темата е широко разисквана в ИТ средите доколко тази техника противоречи на съответните RFC-та '> Още повече, че предпазваш от syn-flood само твоята машина - а, ако машина е рутер и трябва да защитава машините зад нея от syn-flood?

А, и никъде не съм казал, че защитите ми са само срещу syn-flood - доста други защити съм понаписал в моята защитна стена. Примерът беше примерен '>))))

[Hapkoc]

teh, аз много не зацепих защо да се върне port-unreachable е "чупещо". Пък policy ACCEPT си мисля, че не е "добра практика ™" при защитните стени.

[Radev]

VladSun ROUTE - iptables ROUTE target ли имаш в предвид?
Няма ли някой по-stable вариант?