Много ще ми е интересно да видя маските на двата интерфейса или поне как си ги представя питащия.

Правилно си постъпил и няма нищо нередно и грешно в реда който си избрал. Винаги е по-добре да "разкараш" нежеланата поща колкото се може по-рано, с по малко ресурси (при възможност още и при началния /E/SMTP разговора на клиент-сървър) и възможно най-малка част от писмата да достигат до тежките механизми за филтриране. Т.е. да, най-тежките и ресурсоемки филтриращи механизми е добре да се оставят последни.

P.S.
Замисли се също и за смяна на qmail-scanner.pl със simscan.

Ето го и тук:

'Пишем на две места и почва да става некомфортно (тук и форума) ;-) Ще отговоря само на последното:

"Я, сега да видим с твоите любими syn-cookies как ще се оправиш в същия този случай, но при шеговит колега със syn-flood."

Няма проблем! Въпреки, че опашката е пълна (следователно syn cookies проверката е активна вече), когато АЗ се опитам да направя връзка с дадената машина тя ще върне на рутера пакет със cookie (3 bytes sequence number) който connection tracking механизма на рутера ще прехвърли на мен (защото следи какво правя) а не на колегата който флуди и аз наобратно ще му върна пакет със същия sequence. Ще завършим 3 way handshake-а и от тук нататък вече не ни интересува даже syn опашката и комуникираме нормално с условието, че connection tracking-а на локалния рутер си върши работата, а той го прави.'

Отговорих ти. Но the mighty moderators пият бира сигурно вече.

Това за чупенето съм го споменал (губиш window scaling и т.н.) както и, че не е 100% решение (но пък клони към 99). Но при положение, че не са активни (syn cookies) когато опашката се напълни - новите пакети се drop-ват. А когато са активни, пакетите се третират по абсолютно същия начин както и без syn cookies до момента в който опашката се запълни и *чак тогава* започват проверките за новодошлите syn пакети които иначе щяха да бъдат drop-нати. И това протича докато опашката не падне с 1 пакет под максималния и размер. Прочети thread-a който дадох ... има примерен код, даже и Alan Cox се обажда на едно място.

За iLO-то съм съгласен - много е удобно. Но самата идея, че си стигнал да ползваш iLO-то заради зле написания си firewall е притеснителна '>

Домашни почти не, но корпоративни има много. Я се сетил да сложи white list, я не '>

Според мен по удачния начин за brute force защита ще е на application ниво. Т.е. ssh/telnet/.../ или който и да е там демон просто преди да поиска някаква аутентикация да изчака 2-5 секунди след осъществяването на връзката. Другото вече си е работа и задължение на потребителя/админа/.../ - дължина на ключове, пароли, пас-фрази и т.н.

Ще го пусна тук:

"Да речем, че за твоя "brute force ssh protection" използваш следната логика: От всеки един адрес не позволявам tcp/22 връзка ако той се е опитал или е направил такава за интервал по малък от 60 секунди". Най-просто казано.

Приемаме и условието, че въпросната машина е колокирана в някакъв data център.

Също и, че ти прекарваш по-голямата част от времето си в някаква корпоративна мрежа използваща rfc1918 адреси т.е. в най-общия случай си зад NAT и/или proxy. По този начин в повечето случаи всичко в тази мрежа което прави някакви заявки на вън се вижда сякаш идва от един адрес.

Представяме си, че твой колега който иска да се пошегува с теб пуска един скрипт който на 10 секунди прави (или се опитва) връзка до въпросната машина в data центъра на порт tcp/22.

Ти кога ще успееш да направиш легитимна връзка до машината с цел да отстраниш спешно възникнал проблем от мрежата в която прекарваш по-голямата част от деня си?

Това не е ли типичен пример за DoS поради зле написан firewall?

После как ще обясниш на шефа си (който е цъкал с език докато трета седмица си писал firewall-a "брей тоя нашия админ колко е умен и колко много работи по тоя firewall" и ти си го убеждавал, че това е the ultimate firewall) защо не си можал да влезеш на машината и да решиш проблема?

Просто не се прави на това ниво защитата от brute force."

@VladSun

Изтриха коментарите от статията ти, иначе ти бях написал много прост пример как да се DoS-неш сам.

Последния ти "Примерен код" никой никъде в тази тема май не го е пускал. Както и никой никъде не е казал, че става въпрос само за syn flood/DoS защита. Живи и здрави и да не се напивате много довечера ;-)

"The one" може да се каже на този който е измислил решението. И това определено не съм аз. Карам ви се, защото се занимавате с глупости (даже и ги препоръчвате на трети лица) след като има вече готово решение (от 1997, т.е. десетилетие) вместо да се занимавате с нещо за което няма решение.

Ето ви един thread за размисъл относно syn cookies:

http://www.redhat.com/archive....47.html

@alex_c

Звучиш малко по разумен. Помисли върху това:

Имаш една опашка с определен максимален размер. Когато опашката се запълни - не се допускат повечете хора/единици/пакети/топчета/.../ и се отпращат. Отбелязвам, че и в този случай никой не прави проверка легитимни ли са или не хората.

Със правило като твоето (или на който е там) казваш следното:  "Няма да пускам по повече от 5 човека на минута". Тук също не правиш проверка дали са легитмни или не.

Какво можеш да постигнеш с наложеното правило? Ще държиш опашката наполовина пълна и другите хора ще ги отпращаш или пък опашката ще е постоянно пълна и хората ще бъдат отпращани защото е пълна а твоето правило няма да влезе в сила защото опашката се пълни цялата въпреки, че пускаш само по 5 човека на минута. Като и тук никъде не проверяваш легитмни ли са или не хората на опашката.

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

Отбелязвам, че последното не е 100% решение на проблема
, но е доста по логичен ход от колкото сам да се прецакваш.

@tmcdos:

"Проблема си е във клуба".

За вършене - върши. Проблема е, че не можеш да го разчетеш въпреки, че е в пъти по изчистено, просто и функционално от предните "опити".

[Примерен код]

Просто е още един начин да се прецакаш ;-)

Примерен код

# PROTECTION SYN flood -A protect -i eth0 -p tcp --tcp-flags SYN,RST,ACK SYN -m limit --limit 100/s --limit-burst 200 -j ACCEPT

Ти от къде си сигурен, че с това правило няма да спреш легитимни syn пакети преди още да са напълнили опашката (DoS yourself)?
Или обратното - опашката вече ще е пълна (DoS attack successful) пък твоето правило няма да влезе в сила защото всеоще не е достигнат желания rate?

Този тип ограничение изисква много подробно тестване от всевъзможни източници (различни в отношение "network distance") на всеки един хост върху който ще го прилагаш и пак накрая е твърде вероятно нищо полезно да не си направил а напротив - точно обратното.

Именно против syn flood хората (DJB) са измислили т.нар. syn cookies(1). Имат няколко недостатъка но при положение, че syn cookies проверките влизат в сила единствено когато опашката се напълни и включват проверката за следващите постъпили syn пакети (вместо да ги drop-ват както ще стане ако не е вкл. tcp_syncookies), тогава това *Е* по-доброто решение.

1 - http://en.wikipedia.org/wiki/Syncookies

[Примерен код]

Има малки изключения но като цяло сте изписали три страници глупости.

Ако говорим само за ipv4, "standalone" машина и SPI, iptables скрипта ти *трябва* да изглежда така:

Примерен код

#!/bin/bash ipt=/sbin/iptables myip=10.0.0.110 for table in mangle nat filter; do \ $ipt -t $table -F $ipt -t $table -X $ipt -t $table -Z done $ipt -P INPUT DROP $ipt -P FORWARD DROP $ipt -P OUTPUT ACCEPT $ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $ipt -A INPUT -i lo -j ACCEPT $ipt -A INPUT -p tcp --syn --dport 21 -j ACCEPT $ipt -A INPUT -p tcp --syn --dport 22 -s $myip -j ACCEPT $ipt -A INPUT -p tcp --syn --dport 25 -j ACCEPT $ipt -A INPUT -p tcp --syn --dport 80 -j ACCEPT $ipt -A INPUT -p tcp --syn --dport 113 -j REJECT --reject-with tcp-reset $ipt -A INPUT -p tcp --syn --dport 443 -j ACCEPT $ipt -A INPUT -p tcp --syn --dport 3306 -s $myip -j ACCEPT $ipt -A INPUT -p icmp -j ACCEPT

Файлът /etc/sysctl.conf трябва да изглежда *поне* така:

Примерен код

net.ipv4.icmp_echo_ignore_broadcasts=1 net.ipv4.conf.default.rp_filter=1 net.ipv4.tcp_syncookies=1 net.ipv4.ip_forward=0