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

Здравейте.
Опитвам се да напиша правила за IPTABLES на едно малко сървърче. Инсталирал съм си Fedora Core 4, и IPTABLES 1.3.0, на сървъра работят Apache, MySQL, SSH, FTP, Postfix. Искам да направя следното:
1. Да има безусловен достъп от Интернет до Apache, Postfix и FTP
2. Само аз (конкретно IP) да имам достъп през Интернет до SSH и MySQL
За целта съм избрал политиката "Забрана на всичко, и след това разрешаване само на необходимото"
Ето и самите правила на IPTABLES:

Примерен код

*nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *filter :FORWARD DROP [0:0] :INPUT DROP [0:0] :OUTPUT ACCEPT [0:0] # Enable full access from my home IP -A INPUT -s xx.xx.xx.xx/32 -i eth0 -j ACCEPT -A INPUT -p all -s localhost -i eth0 -j DROP -A INPUT -p all -s localhost -i eth1 -j DROP -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p icmp -m icmp --icmp-type echo-request -j ACCEPT -A INPUT -i eth0 -p icmp -m icmp --icmp-type echo-reply -j ACCEPT -A INPUT -i eth0 -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT -A INPUT -i eth0 -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT # PROTECTION SYN flood -A INPUT -i eth0 -p tcp --syn -m limit --limit 25/s --limit-burst 35 -j ACCEPT # PROTECTION port scanner -A INPUT -i eth0 -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 3/s --limit-burst 5 -j ACCEPT # PROTECTION Ping of Death -A INPUT -i eth0 -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 3 -j ACCEPT # Drop hijackers !!! -A INPUT -i eth0 -s 81.169.186.45/32 -j DROP -A INPUT -i eth0 -s 84.170.202.66/32 -j DROP -A INPUT -i eth0 -s 203.172.213.122/32 -j DROP -A INPUT -i eth0 -s 194.242.112.72/32 -j ACCEPT -A INPUT -i eth0 -s 212.241.246.148/32 -j ACCEPT -A INPUT -i eth0 -s 204.13.82.60/32 -j DROP -A INPUT -i eth0 -s 85.140.156.23/32 -j DROP -A INPUT -i eth0 -s 213.234.30.79/32 -j DROP -A INPUT -i eth0 -s 87.106.12.174/28 -j DROP -A INPUT -i eth0 -s 213.91.242.188/32 -j DROP -A INPUT -i eth0 -s 87.126.147.86/32 -j DROP -A INPUT -i eth0 -s 217.160.23.161/32 -j DROP -A INPUT -i eth0 -p tcp -m tcp --dport 25 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 110 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 2120 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 909 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 30000:30024 -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT

Използвах един On-line скенер за отворени портове и установих, че въпреки политиката по подразбиране DROP за веригата INPUT, и че не съм обявил никъде порт 3306 - той все пак е отворен за външния свят.

Някой може ли да ми даде съвет или да подскаже къде бъркам ?

Добре нали имаш стартиран MySQL вероятно ти е отворен порта заради самата услуга.

Здрасти колега
Можеш да пробваш това:

// Приема всички tcp на порт 3306 от localhost
iptables -A INPUT -i lo -p tcp --dport mysql -j ACCEPT
// Приема всички udp на порт 3306 от localhost
iptables -A INPUT -i lo -p udp --dport mysql -j ACCEPT
// Приема tcp на порт 3306 от allowed_ip
iptables -A INPUT -i eth0 -p tcp --dport mysql -s allowed_ip -j ACCEPT
// Приема udp на порт 3306 от allowed_ip
iptables -A INPUT -i eth0 -p udp --dport mysql -s allowed_ip -j ACCEPT
[...] всички други правила нататък...
// drop-ване на всички други пакети
iptables -A INPUT -j DROP

Пиши ми, ако съм ти помогнал

Като гледам не би трябвало да е отворен този порт. Единствено ми прави впечатление, че имаш два адреса в бан списъка, които са с ACCEPT, а не DROP ...

# Drop hijackers !!!
....
-A INPUT -i eth0 -s 194.242.112.72/32 -j ACCEPT
-A INPUT -i eth0 -s 212.241.246.148/32 -j ACCEPT
....

Написал съм ги по инерция тези двамата в бан-списъка да са ACCEPT :-) Благодаря за напомнянето.
Обаче все още не мога да си обясня защо порта ми стои отворен ?! Каква е тази магия ...

Какво имаш на тези портове?

-A INPUT -i eth0 -p tcp -m tcp --dport 2120 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 909 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 30000:30024 -j ACCEPT

И пробвай да махнеш
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

и да кажеш дали порта е отворен тогава.

На 2120 - FTP, на 909 - Webmin, 30000-30024 са ми за data-каналите на FTP-то (за да може да се връзват хора, които седят зад NAT и им се налага да ползват PASV режим на трансфер)

Като махна
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

се получават тайм-аути. Например като се опитам да заредя уеб-страница, се появява бял екран, и чак след 5-6 секунди се зарежда съдържанието. Или пък ако пробвам с TELNET да се вържа към порт 25, получавам отговора
220 Greeting Postfix
пак след 5-6 секунди.
А ако го върна обратно, всичко си е наред - няма таймаут-и.

И в двата случая обаче порт 3306 си остава достъпен отвън ...

А като спреш напълно mysqld пак ли ти дава този тест, че е отворен порта?

Е, не разбира се - нали като го спра, никой не отваря порта - няма LISTEN. Въпроса е, че като съм го пуснал, трябва да е достъпен само за мен - а не за всички, както е с останалите услуги. Демек трябва да дропи всички пакети, които не идват от моето IP.

Този код ще спре изцяло достъпа до MySQL - на мен ми трябва да реже всички, освен мен ;-)

Цитат

iptables -t nat -A PREROUTING -p tcp -s 0.0.0.0 -d ip.to.na.servera --dport 3306 -j DROP

В ръководството на IPTABLES изрично се указва, че таблица NAT се използва само за промяна на адресите и/или портовете на източника/получателя на пакета - а за филтрация на пакетите да се използва таблица FILTER.

Сетих се нещо.
Може би проблема идва от това, че имам няколко виртуални интерфейса на един физически. И тъй като в правилата съм написал -i eth0, може би не се получава съвпадение.
Но пак няма логика - защото нали ако нито едно правило не съвпадне, трябва да се приложи политиката по подразбиране - която е указана като DROP.
Хм ....

Пробвах да махна
-A INPUT -i eth0 -p tcp -m tcp --dport 25 -j ACCEPT

и скенера пак показа, че порта е отворен ...

1. Пробвай експлицитно да добавиш в края:
iptables -A INPUT -j DROP
както предложи tony1975
2. Все пак какво става, ако му дадеш:
iptables -A INPUT -p tcp --dport 3306 -j DROP

пробвай и да го сложиш съвсем в началото.

Ако не се справяш - пробвай в debug mode   :
сложи едно правило:
-A INPUT -p tcp --dport 3306 -j LOG --log-level info --log-prefix '### SQL ###'
в края, пусни си в една конзола "tail -f /var/log/messages" и пусни скенера.
Ако не излезе нищо, значи вече или е DROP-нат или ACCEPT-нат (в твоя случай явно второто). Тогава придвижваш това правило с едно правило по-нагоре и пак .. и пак .. докато не откриеш колко правило всъщност ти прави мизериите

Абе, пичове, нали с правилото:
-A INPUT -i eth0 -p tcp --syn -m limit --limit 25/s --limit-burst 35 -j ACCEPT

разрешава конекции по протокол TCP с честота 25 в секунда, без да е указано на кой порт става това.
Не виждам къде в таблицата се указва достъп по SSH и до MySQL сървъра само от конкретно IP.
За да се постигне желания ефект (заедно със защита от syn-flood), таблицата трябва да изглежда примерно така:

-----------------------------------------------
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
:syn-food - [0:0]

# Enable full access from my home IP
-A INPUT -s xx.xx.xx.xx/32 -i eth0 -j ACCEPT
-A INPUT -p all -s localhost -i eth0 -j DROP
-A INPUT -p all -s localhost -i eth1 -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type echo-request -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT

# PROTECTION SYN flood
-A INPUT -i eth0 -p tcp -m tcp --dport 25 --syn -j syn-food
-A INPUT -i eth0 -p tcp -m tcp --dport 80 --syn -j syn-food
-A INPUT -i eth0 -p tcp -m tcp --dport 110 --syn -j syn-food
-A INPUT -i eth0 -p tcp -m tcp --dport 2120 --syn -j syn-food
-A INPUT -i eth0 -p tcp -m tcp --dport 909 --syn -j syn-food
-A INPUT -i eth0 -p tcp -m tcp --dport 30000:30024 --syn -j syn-food
-A INPUT -i eth0 -p tcp -m tcp --syn -j REJECT

-A syn-food -m limit --limit 25/s --limit-burst 35 -j ACCEPT

# PROTECTION port scanner
-A INPUT -i eth0 -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 3/s --limit-burst 5 -j ACCEPT
# PROTECTION Ping of Death
-A INPUT -i eth0 -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 3 -j ACCEPT

# Drop hijackers !!!
-A INPUT -i eth0 -s 81.169.186.45/32 -j DROP
-A INPUT -i eth0 -s 84.170.202.66/32 -j DROP
-A INPUT -i eth0 -s 203.172.213.122/32 -j DROP
-A INPUT -i eth0 -s 194.242.112.72/32 -j ACCEPT
-A INPUT -i eth0 -s 212.241.246.148/32 -j ACCEPT
-A INPUT -i eth0 -s 204.13.82.60/32 -j DROP
-A INPUT -i eth0 -s 85.140.156.23/32 -j DROP
-A INPUT -i eth0 -s 213.234.30.79/32 -j DROP
-A INPUT -i eth0 -s 87.106.12.174/28 -j DROP
-A INPUT -i eth0 -s 213.91.242.188/32 -j DROP
-A INPUT -i eth0 -s 87.126.147.86/32 -j DROP
-A INPUT -i eth0 -s 217.160.23.161/32 -j DROP


-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

COMMIT
-----------------------------------------------

По принцип може и без реда:
-A INPUT -i eth0 -p tcp -m tcp --syn -j REJECT

но без него при сканиране ще бъде открито, че всички останали портове са филтрирани, докато така ще се върне ICMP съобщение: destination port unreachable.

P.S. Сега видях, че съм именовал веригата за ограничаване на SYN пакетите syn-food, а не syn-flood (не че е от значение, но някак си храната няма място тук ), но ме мързи да го поправям

Best wishes!
Alex

Та, по "моя" начин стената би изглеждала примерно така:

Примерен код

-A INPUT -s xx.xx.xx.xx/32 -i eth0 -j ACCEPT -A INPUT -p all -i !lo -s localhost -j DROP -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -s 81.169.186.45/32 -j DROP -A INPUT -i eth0 -s 84.170.202.66/32 -j DROP -A INPUT -i eth0 -s 203.172.213.122/32 -j DROP -A INPUT -i eth0 -s 194.242.112.72/32 -j DROP -A INPUT -i eth0 -s 212.241.246.148/32 -j DROP -A INPUT -i eth0 -s 204.13.82.60/32 -j DROP -A INPUT -i eth0 -s 85.140.156.23/32 -j DROP -A INPUT -i eth0 -s 213.234.30.79/32 -j DROP -A INPUT -i eth0 -s 87.106.12.174/28 -j DROP -A INPUT -i eth0 -s 213.91.242.188/32 -j DROP -A INPUT -i eth0 -s 87.126.147.86/32 -j DROP -A INPUT -i eth0 -s 217.160.23.161/32 -j DROP -N ICMP -A INPUT -i eth0 -p icmp -j ICMP -A ICMP -p icmp -m icmp --icmp-type echo-request -j RETURN -A ICMP -p icmp -m icmp --icmp-type echo-reply -j RETURN -A ICMP -p icmp -m icmp --icmp-type time-exceeded -j RETURN -A ICMP -p icmp -m icmp --icmp-type destination-unreachable -j RETURN -A ICMP -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 3 -j RETURN -A ICMP -j DROP # PROTECTION services -A INPUT -i eth0 -p tcp -j TCP -A TCP -p tcp --syn -m ! limit --limit 25/s --limit-burst 35 -j DROP -A TCP -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m ! limit --limit 3/s --limit-burst 5 -j DROP -A TCP -p tcp -m state --state INVALID -j DROP -A TCP -p tcp --dport 25 -j RETURN -A TCP -p tcp --dport 80 -j RETURN -A TCP -p tcp --dport 110 -j RETURN -A TCP -p tcp --dport 2120 -j RETURN -A TCP -p tcp --dport 909 -j RETURN -A TCP -p tcp --dport 30000:30024 -j RETURN -A TCP -p tcp -j REJECT -A INPUT -p tcp -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -j DROP

Това, което alex_c забеляза, всъщност го има и при Ping-of-Death защитата - ти ВЕЧЕ си приел тези пакети по-горе.

Както виждаш използвам много малко ACCEPT правила при това само в края. За DROP правилото винаги си сигурен, че не искаш пакета да продължи по нататък, независимо какво има след него. За ACCEPT правилата обаче, това съвсем не е така - винаги може да се появи нещо след него, което да иска да отхвърли този пакет по друг признак

@VladSun:
 За ACCEPT правилата обаче, това съвсем не е така - винаги може да се появи нещо след него, което да иска да отхвърли този пакет по друг признак

Не съм съгласен с това - след като веднъж един пакет е ACCEPT-нат, той излиза от текущата таблица (filter, nat или mangle) и повече не се проверява за съответствие от правилата след реда, с който е извършено ACCEPT-ването.
Не случайно (или може би е улучил мястото ) tmcdos е сложил правилото:

-A INPUT -s xx.xx.xx.xx/32 -i eth0 -j ACCEPT
в началото на таблицата, а именно, за да приемат и да не се проверяват повече пакетите със сорс адрес xx.xx.xx.xx/32 повече.

Best wishes!
Alex

Съвсем нарочно и преднамерено съм си сложил "вратичката" още в началото, това го научих малко по-отдавна  
Алекс, наистина заслужи бирата - остава само да я изпием. За пореден път се убеждавам колко е важен реда на правилата.
Влади, аз продължавам да съм убеден, че DROP-ACCEPT начина на работа позволява да имаш по-малко правила и (поне на мен) ми е по-лесен да си го представя, отколкото ACCEPT-DROP. Както винаги - въпрос на лични предпочитания. Между другото, ти с коя версия на IPTABLES си, използваш ли някакви допълнителни пачове ? Защото доколкото зная, до версия 1.3.1 опцията LIMIT не може да работи с инверсия:

Примерен код

-A TCP -p tcp --syn -m ! limit --limit 25/s --limit-burst 35 -j DROP -A TCP -p tcp --syn -m limit ! --limit 25/s --limit-burst 35 -j DROP

този код не работи.
Преработих си малко правилата, и сега вече порт 3306 е отворен само за мен и никой друг.

Примерен код

*nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *filter :FORWARD DROP [0:0] :INPUT DROP [0:0] :OUTPUT ACCEPT [0:0] :protect - [0:0] -A INPUT -s хх.хх.хх.хх/32 -i eth0 -j ACCEPT -A INPUT -p all -s localhost -i eth0 -j DROP -A INPUT -p all -s localhost -i eth1 -j DROP -A INPUT -i lo -j ACCEPT # PROTECTION port scanner #-A INPUT -i eth0 -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 3/s --limit-burst 5 -j REJECT --reject-with icmp-host-unreachable # Drop hijackers !!! -A INPUT -i eth0 -s 81.169.186.45/32 -j DROP -A INPUT -i eth0 -s 84.170.202.66/32 -j DROP -A INPUT -i eth0 -s 203.172.213.122/32 -j DROP -A INPUT -i eth0 -s 194.242.112.72/32 -j DROP -A INPUT -i eth0 -s 212.241.246.148/32 -j DROP -A INPUT -i eth0 -s 204.13.82.60/32 -j DROP -A INPUT -i eth0 -s 85.140.156.23/32 -j DROP -A INPUT -i eth0 -s 213.234.30.79/32 -j DROP -A INPUT -i eth0 -s 87.106.12.174/28 -j DROP -A INPUT -i eth0 -s 213.91.242.188/32 -j DROP -A INPUT -i eth0 -s 87.126.147.86/32 -j DROP -A INPUT -i eth0 -s 217.160.23.161/32 -j DROP -A INPUT -i eth0 -p tcp -m tcp --dport 25 -j protect -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j protect -A INPUT -i eth0 -p tcp -m tcp --dport 110 -j protect #-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j protect -A INPUT -i eth0 -p tcp -m tcp --dport 2120 -j protect -A INPUT -i eth0 -p tcp -m tcp --dport 909 -j protect -A INPUT -i eth0 -p tcp -m tcp --dport 5222:5223 -j protect -A INPUT -i eth0 -p tcp -m tcp --dport 5269 -j protect -A INPUT -i eth0 -p tcp -m tcp --dport 30000:30024 -j protect # Should be last in this block -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT # 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 # There is no need for the next rule, since if packet does not match the rule above, it will leave chain PROTECT # and return back to the originating INPUT chain, where a DROP by default will be made #-A protect -i eth0 -p tcp --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-host-unreachable # PROTECTION Ping of Death -A INPUT -i eth0 -p icmp -m icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 3 -j ACCEPT # Accept all ICMP answers, hopefully they do not need further processing # but this is not tested against DoS attacks -A INPUT -i eth0 -p icmp -m icmp --icmp-type echo-reply -j ACCEPT -A INPUT -i eth0 -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT -A INPUT -i eth0 -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT # if this is Ping-of-Death or something similar, it will not match the rules above, so we handle it here -A INPUT -i eth0 -p icmp -m icmp -j REJECT --reject-with icmp-host-unreachable COMMIT

Само защитата от сканиране на портове още не съм измислил как да я направя, но ще се справя.

Благодаря !

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

Ако говорим само за 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

@teh
Не разбирам какво имаш против ограничаването на наводняването със SYN пакети?

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

teh, не се сърди - но твоето решение не ми върши работа.

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

Примерен код

# 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

@tmcdos:

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

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

@alex_c

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

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

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

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

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

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

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

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

@teh
Прав си за DoS с така направена syn-flood защита. То за това хората са измислили hashlimit.

Но тъй като ТИ си ЕДИНСТВЕНИЯ (ДЪ УАН) разбирач тука, аз спирам да пиша защото по незнайни за мен причини (което е естествено при условие, че аз не съм ДЪ УАН) пак ще ме обвиниш в сляпо преписвачество ...

Айде, живей си весело!

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

@teh

Съгласих се с теб, че SYN-cookies са добро решение. Също и със забележката, че никъде не се проверят хората/пакетите/топчетата ... кой е легитимен, и кой не е.

Малко коментари по

Примерен код

/sbin/sysctl -w net.ipv4.conf.all.send_redirects=0 /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0 /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0 /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0 /sbin/sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 /sbin/sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 /sbin/sysctl -w net.ipv4.conf.all.log_martians=1 /sbin/sysctl -w net.ipv4.conf.all.rp_filter=1

send_redirects=0
accept_redirects=0
Първият параметър изобщо не влияе, ако срещу теб започне DoS-атака. Влияението на втория е спорно, и обикновено препоръчват да се оставя в 1, особено ако хоста се намира в мрежа с множество възможни маршрути.

log_martians=1
Това само би спомогнало на целите на атакуващия, особено ако използва невалидни значения в адреса на изпращача - всеки пакет ще се логва.

rp_filter=1
Това също не помага за защита от DoS, защото изисква нападнатия хост да проверява обратния път до атакуващия, допринасяйки за допълнително натоварване на мрежата.

mc_forwarding=0
Това влияе само на пакетите с групов адрес, и на нормален хост изобщо не работи - само на маршрутиратор.

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

По принцип общи правила за защита от DoS май не съществуват, и всеки сам се спасява   Ако атаката се състои в тъпо запълване на външния канал с входящи пакети, няколко правила на моя сървър няма да помогнат кой знае колко. Ако атаката е конкретно към дадена машина, се опитва да се идентифицира паразитния трафик, и да се филтрира.

Това, което аз наблюдавам при мен, е че периодично с автоматични скенери за дупки в сигурността се сондира WEB-сървъра, с идеята да бутнат някакъв троянец и да вземат машината под контрол за по-нататъшна "дообработка"
Най-често ме проверяват за присъствието на:

Примерен код

blog drupal phpgroupware xmlrpc xmlsrv awstats mambo dbadmin myadmin sysadmin webadmin PMA horde

Но това вече излиза извън темата на разговора  

Примерен скрипт за IPTABLES - според мен е тежък, но може да послужи да си извади човек по нещичко оттук-оттам.
TBF пач за разширяване на възможностите на limit и hashlimit за инверсия в правилата.

На The Open Net има доста интересни статии.

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

Добре
Приемам темата за приключена успешно с ваша помощ, приятели.

@VladSun

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

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

"Да речем, че за твоя "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."

Хех, аз ти казах без IP spoofing, а ти ми написа пример с NAT

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

Това не означава ли, че си в "white list"?

Сега ще кажеш - да, ама IP то се взима динамично ...
И аз ще ти отговоря: Корпоративна мрежа с NAT и динамично IP?

Всъщност има ли още и домашни потребители, които да са зад NAT?!?!


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

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

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

Що си мислите, че syncookies са нещо толкова прекрасно? Според мен, не са. Може да не "чупят" протокола, ама чупят прекрасните му възможности за congestion avoidance и за "самонагаждане" спрямо скоростта на връзката. Ако предоставяш някаква по-използвана услуга, тогава syncookies повече пречат на нещата, отколкото помагат. И апропо, ядрото "информира" сървърният сокет за наличието на нова конекция чак когато тя бъде счетена за "established" , а не както е било в пред-2.4 дните, при получаване на SYN пакет. Последното доста подобрява ситуацията при една SYN атака, защото не се заделят напразно ресурси за конекции, които никога няма да обслужват легитимни клиенти.

И между другото, много полезно е когато колокираш машина в някой дейтацентър, машината ти да има мениджмънт процесор като например iLO. Не само защото някой може да DoS-не системата, но и поради много други фактори. Както и да е...

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

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

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

Ето го и тук:

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

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

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