Изпечатай

[gat3way]

Така или иначе това няма много смисъл - друго 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]

Цитат (Radev @ Ян. 30 2007,07:42)

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

Да.
То няма как да е особено нестабилно '>

[teh]

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

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

[gat3way]

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

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

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