Linux за българи: Форуми

Играя си с iptables,за да разбера същността му!
Та давам iptables -P FORWARD DROP
Искам да спомена,че рутирам нет чрез LINUX-а машина, и "давам" нет на Windows-а машина!Та към БТК съм:
192.168.1.1 (modem) -->etho:192.168.1.2 -->eth1:172.16.2.1 -->172.16.2.0/24 (ip на Windows-аката машина,направил съм DHCP сървър!
Та пиша :
iptables -P FORWARD DROP
НЯМА НЕТ!
После разрешавам:
#DNS
iptables -A FORWARD -p udp -s 172.16.2.0/24 -m state --state NEW,RELATED  --dport 53 -j ACCEPT
iptables -A FORWARD -p tcp -s 172.16.2.0/24 -m state --state NEW,RELATED --dport 21 -j ACCEPT
iptables -A FORWARD -p tcp -s 172.16.2.0/24 -m state --state NEW --dport 80 -j ACCEPT
iptables -A FORWARD -p tcp -s 172.16.2.0/24 -m state --state NEW --dport 443 -j ACCEPT
#NAT
iptables -t nat -A POSTROUTING -s 172.16.2.0/24 -o eth0 -j MASQUERADE

Или някъде греша,или съм забравил нещо!Помогайте    
Няма нет и няма!

Разрешаваш само пакети, които не са свързани с предишни такива ...
Т.е. прим. пускаш само SYN пакетите ...

... а и тези правила, ако ми обясниш какво искаш да правиш с тях, при условие, че са -s 172.16.2.0/24 ...

BTW много е странно как хората филтрират пакети според conntrack state и нямат грам  обяснение защо го правят. Сега примерно ако някой ми обясни какъв е смисъла на RELATED в това правило:

iptables -A FORWARD -p udp -s 172.16.2.0/24 -m state --state NEW,RELATED  --dport 53 -j ACCEPT

ще съм много благодарен

Правя го по едни тука лекции,а искам да схвана правилата и смисъла,затова питам!Казах,ще се радвам на всяко обяснение!

man iptables:

Цитат

state        This module, when combined with connection tracking, allows access to the connection tracking state for this packet.        --state state               Where  state  is a comma separated list of the connection states to match.  Possible states are INVALID meaning that the packet could not be identified for some reason which includes running out of memory and ICMP errors  which  don't  correspond  to  any known  connection,  ESTABLISHED  meaning  that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has  not  seen packets  in both directions, and RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

Прочети и ако имаш въпроси питай

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

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

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

NEW

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

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

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

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

Ако може,обясни ми с примери!Както съм в случая аз,давам iptables -P FORWARD DROP!Какво трябва да се напише,за да има пак нет?

Ти не искаш да ти пиша примери

След като знаеш какво е ESTABLISHED виж си твоята стена и ми кажи, примерно за порт 80, как очакваш да минават други пакети освен SYN ( или само първите пакети от връзката )...

@emagi: Помагащите тук във форума не обичат да смилат информацията за питащите (освен може би в статиите), а по-скоро те насочват към доста подробни статийки за четене и най-вече на английски, защото там са повече, по-актуални и по-подробни.
Друго мое наблюдение е, че се стараят да разсяват заблуди, но за целта трябва да ги провокираш да мислят по този начин, коеот не съм сигурен, че знам точно как става.

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

P.S.: 1. Мен например ме дразни, че не знаеш кога се оставя интервал или не ти пука!
2. На мен също ми е интересна темата, защото и аз като теб трябва да вникна в идеята за управление на IP пакетите - дай (ако няма) да направим една wiki страничка на тази тема, а съм сигурен, че за конкретни въпроси лесно ще намерим компетентни отговори.

Вероятно искаш илюстрация на TCP протокола, обяснение що е то connection tracking, NAT, всичкото това е много добре обяснено и описано и няма смисъл точно тук да търсиш отговора.

Що се отнася до твоят проблем, те са по-скоро два: пропускаш пакети само в едната посока (-s blabla), пропускаш пакети, които за conntrack са "инициращи връзка", т.е само SYN за TCP или само първия UDP пакет в една UDP комуникация, както Vladsun ти е обяснил два пъти. Всичко останало се дропи и затова нямаш "интернет" зад тази машина.

След като искаш илюстрация, ще обясня какво става като се опиташ да отвориш сайт в браузъра. Първо, браузърът се опитва да резолв-не адреса на сървъра (www.site.tld->IP, A record). Ако имаш работещ DNS сървър на рутера и клиентите от частната мрежа го ползват, резолвинга успява, защото пакетите не се match-ват от "FORWARD" веригата, а от INPUT/OUTPUT. Ако се ползва "външен" DNS сървър, то успяваш да пратиш заявка за A record-a, но "отговорът" се издроп-ва поради твоите правила (не пускаш ESTABLISHED).

Ако успееш да резолв-неш адреса на сървъра, браузърът праща HTTP GET заявка до него. За целта първо трябва да се установи TCP връзка, за целта пращаш SYN пакет, който трябва да се потвърди от сървъра с SYNACK пакет, ти да върнеш ACK и така сесията да се счита за установена. Твоите правила пропускат обаче единствено твоят SYN пакет, отговорът бива "издропен" и TCP връзка не се установява.

Най-голямата ти грешка е, че пускаш пакетите само в едната посока (колко и малко пакети да пускаш) - всички правила за ACCEPT са само за източник 172.16.2.0/24 (-s 172.16.2.0/24). А обратният канал няма ACCEPT, т.е. е DROP

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

Първа по-конкретна подсказка:
state NEW го имаш от страна на сърверите ...

ПП: gateway малко ме изпревари

gat3way мног благодаря за отговора!Донякъде ми се изясни,но все още не мога да разбера смисъла на тези три вълшебни думи:RELATED,ESTABLISHED,NEW!Кога се ползват те!

Приеми, че си "обикновен потребител" (т.е. не пускаш сървери) на един от компютрите от лок. мрежа - тогава няма да искаш пакети със state NEW да идват КЪМ твоята машина, но ще искаш ти да можеш да пращаш такива за да установяваш връзка с разни www сървери например. Освен това ще искаш да получаваш всички пакети към току що установената връзка (т.е. state ESTABLISHED), както от Интернет към теб, така и на обратно (тук е мястото да попрочетеш малко за TCP протокола). RELATED пакетите пък ще ти трябват за онези протоколи, които работят с повече от една TCP връзка (не само FTP, има и IRC сървери на които, ако не им отговориш с ident не те пускат).

С други думи ACCEPT правилата за пакетите идващи ОТ локалната мрежа обхващат и 3-те валидни състояние на пакетите.
За пакетите КЪМ локалната мрежа - текста по-горе

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

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

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

iptables -A INPUT -j REJECT

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


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

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

@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 ...

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

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

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

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

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

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

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

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

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

С netfilter:
виж ROUTE target-a

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

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

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

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

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

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

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

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

Така или иначе това няма много смисъл - друго policy освен DROP/ACCEPT не може да се сложи.

Тъй като базовата функционалност, която се предоставя от netfilter framework-a, съответно iptables framework-a се състои в това да дефинираш callback функция, която се извиква когато някой пакет минава през някой chain. Функцията приема като параметър sk_buff структурата, асоцирана с пакета и на база някакви проверки може да върне или NF_ACCEPT или NF_DROP - в първия случай пакета си продължава нататък, в противен - netfilter издроп-ва пакета и освобождава паметта свързана с него. Всякаква функционалност оттам нататък - DNAT, SNAT, LOG, MIRROR, ROUTE, REJECT, etc, която сама по себе си е свързана или с промяна на пакети on-the-fly или с генериране на други такива, е логически отделена в други модули за ядрото. Съответно за да можеше да се слагат такива policies, трябва да е сигурно че тези модули са заредени и че няма вариант в който да се rmmod-нат. И при положение че на края на всяка верига можеш да си сложиш каквото правило искаш, разработчиците просто са отебали да се мъчат да решават този проблем.

Що се отнася до това дали е разумно - според мен е еднакво разумно/неразумно да се дроп-ват всички unmatched пакети или да се връща грешка. Доколкото имам наблюдения как се държи линукския TCP стек, когато се опитваш да достъпиш TCP услуга на порт, на който няма bind-нат сокет се връща RST пакет, а не ICMP грешка. В случая с UDP това няма как да стане и се връща ICMP port unreachable. Ако това е някакъв хост, а не рутер, според мен е оправдано да може да връща каквото си решиш. В противен случай става малко сложно.

С MIRROR таргет-а няма особен смисъл да ставаш spoof decoy, поне що се отнася до TCP връзки, защото злият хакер няма начин да си види обратно отговорите. Ако лошият може да изпраща подправени пакети, т.е никъде някой по пътя не ги филтрира, то надали ще му трябва особено да ползва някой decoy, особено при положение че шанса да ги издропят на някой хоп около decoy-a нараства...според мен де. Що се отнася до някакъв вид DoS обаче, MIRROR таргета наистина предоставя механизми за traffic amplification на атаката.

Що се отнася до syncookies...не са особено чупещи RFC-та. В смисъл че се жертва донякъде функционалността, която осигурява договарянето на TCP параметри при tcp handshake-a (там MSS, window scaling), не съм обаче много запознат доколко това е фатално. Според мен има някаква вероятност при странни PMTU на връзката да има проблеми, както и при трансфери на големи файлове, performance-a да се преебава, поради невъзможност да се вдига големината на tcp прозореца. Ъмм понеже аз нито съм се  занимавал да изследвам проблема, нито съм много добре запознат със механизма на syncookies, не мога да кажа доколко тези неща са валидни, така че ако някой се е занимавал да каже най-добре.

А като се върнем пак на темата за филтъринга, пак казвам, според мен пък не е фатално да се слага ACCEPT policy. След като накрая  можеш да слагаш каквито си искаш правила. Колкото е лесно да сложиш -P <chain> DROP, толкова е лесно и да сложиш -A <chain> -j DROP, а ефекта е почти еднакъв в крайна сметка.

VladSun,
това което ти се иска/струва не винаги отговаря на действителността. Поне прегледай icmp дефиницията в wikipedia преди тези писания. И да предложим да пренапишат icmp протокола да има само 1 съобщение за грешка а.

както и да е. лек ден на всички :-)

teh, от друга страна, ти пък колко вида ICMP съобщения знаеш, които са създадени да информират отсрещната страна, че услугата която опитват да достъпват, е филтрирана? Според мен няма почти никакво значение дали отсрещната страна ще получи ICMP administratively prohibited или ICMP port unreachable например. Ако е от някакъв хост де. Ако е от рутер forward-ващ  трафик, вече има по-различни съображения и частни случаи, съответно повече причини да не DROP-ваш и REJECT-ваш каквото ти дойде.

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

А иначе лек и на тебе