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

Здравейте

Реших да направя тест на един с сървър с момоща на hping3  , докато се усетя си бутнах локалната мрежа, теста го пусках от едно от PC-тата в мрежата.  Въпроса ми е мога ли да блокирам излизането на syn flood , защото днес го пуска аз утре някой друг. Това което ми идва наум е да лимитирам броя конекции но несъм сигурен колко съм на прав път.
Това с което си задръстих мрежата беше: hping --faster -S mysite.com -p 80

Сигурен ли си - малко странно ми се вижда си си бутнал мрежата с ICMP ECHO request...

В случай е syn flood, на другите компютри в мрежата се загубва целия интернет , в момента в който спра hping3 и след 10сек всичко се оправя.

echo 'net.ipv4.tcp_syncookies = 1' >> /etc/sysctl.conf ; sysctl -p

Ако режеш пакетите с INVALID state идващи от вътрешния интерфейс на рутера ти, вероятно ще си помогнеш...донякъде. Лимитирането на броя на TCP връзките няма да помогне, понеже нямаш такива. Това което излиза навън е SYN-ACK и евентуално ти се връща RST. Handshake няма, съответно и TCP връзка няма.

'net.ipv4.tcp_syncookies = 1'  съм го сетнал.

Относно броя връзки , говоря глупости .
INVALID state ги дропвам но без резултат.

Това ме навежда на мисълта ,че човека Х се закача на публичен WiFI и го скапва е един hping :(
Дали има някаква друга борба със това?

Сигурен ли си че ги дропваш където трябва? Не знам каква ти е конфигурацията на рутера, но трябва да дропваш INVALID пакетите не идващи от външния интерфейс, а от вътрешния. Не знам на коя таблица и кой chain си го закачил, но със сигурност не трябва да е на INPUT и със сигурност не трябва да match-ва пакети идващи отвън.

syncookies няма да помогне, понеже е правен със съвсем друга идея. Нагледно предполагам си представяш картинката но все пак, става следното:

1) Някой лош хост от мрежата засипва друг добър хост със SYN пакети с подправен сорс адрес (което реално прави hping -S blabla --faster

2) Добрият хост тръгва да довършва handshake-а, връщайки SYNACK пакети към blabla. Ако на рутера няма правило да се режат, понеже не match-ват особено добре на conntrack таблицата му, демек са невалидни, те ще излязат навън

3) Ако blabla е реален хост ще ти върне RST, защото му пристига SYNACK без да е иницирал връзка. RST пакетите ще ходят обратно и допълнително ще ти задръстят честотната лента.

4) Ако ти е "слаб" bandwidth-а навън, ще се задръсти с SYNACK пакети и техните RST отговори.

Режейки невалидните SYNACK пакети си спестяваш изкарването им навън, както и RST отговорите. Това не е спасение при особено силен flood защото вътрешният ти интерфейс може да бъде задръстен от трафик и освен това conntrack таблицата си има лимити и stateful packet filtering-а е по-претенциозен откъм системни ресурси. Ако рутерът ти е някакъв скапан linksys с който връзваш 802.11 до навън, кофти работа, не можеш да направиш много.

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

Дропвам INVALID пакети в INPUT , FORWARD , OUTPUT на всички интерфейси. Това което си мисля е ,че интерфейса от кадето идва flood-а се задръства и от там и се гиби интернет-а. Това вече май няма как да се избегне.

А дали не си буташ switch'a ?

Незнам дали е вярно това което, ще пейстна , но го бях чел в редовете на един firewall ..

#stop DoS attack
iptables -A INPUT -i ethX -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
# stop Xmas Tree type scanning
iptables -A INPUT -i ethX -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -i ethX -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
# stop null scanning
iptables -A INPUT -i ethX -p tcp --tcp-flags ALL NONE -j DROP
# SYN/RST
iptables -A INPUT -i ethX -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# SYN/FIN
iptables -A INPUT -i ethX -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# stop sync flood
iptables -N SYNFLOOD
iptables -A SYNFLOOD -p tcp --syn -m limit --limit 1/s -j RETURN
iptables -A SYNFLOOD -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp -m state --state NEW -j SYNFLOOD

А дали не си буташ switch'a ?

Да. И на мен ми прилича повече на MAC flood атака срещу суича.

мм ,за 10сек да си препълня CAM , и то прес wireless . Проблема ми е ,че в момента тествам на една кутийка TP-Link(TL1043) с OpenWRT  до която нямам физически достъп и всичко се случва през Wireless. Иначе тествах и с PC за GW ,но там немога да си позволя flood в момента.

Абе за да се препълни CAM таблицата би следвало да се появяват прекалено много фреймове с различни MAC адреси, което не виждам как би се случило при ползването на hping с тези опции. Апропо рутерът ти е въпросната wifi джаджа с openwrt? Да не би да му препълваш conntrack таблицата? Едно време онези линксис-ски таралясници така клякаха дори като си пуснеш torrent клиент някакъв.

Да , едната мрежа къде тествам е с Wifi Router с OpenWRT , там разпада връзката.
Другото място където тествам е с PC за router , там на една от машините имам nagios който следи мрежата (пинг тест прави). Всички машини са в един мрежов сегмент. След теста с hping , nagios праща писма ,че машините са Down.
Направих си опит да режа разни пакети и при --state NEW -j DROP , wireless-а  не се разпада но и инрернет-а си режа така :)

Предположението се оказа вярно.
cat /proc/net/ip_conntrack |wc -l
39223
Това се вижда на gateway-a зад когото е атакуваната машина, подобни са цифрите и на gateway-a зад който е машината от която пускам aтаката.
И това е след 20сек , hping3 --faster -S mytarget.com -p 80
Спасението което виждам е лимитиране на сесиите.
Но това да лимитирам сесиите е грозно, защото по този начин ще наруша качеството на услугите.
Някаква идея ?

Мммммне, мисля, че няма начин да ограничиш това ефективно. Според мен по-добре виж в посока дали не може да се подържа по-голяма такава таблица по някакъв начин. Обаче нямам много идея как точно би станало, отдавна не съм се занимавал с подобни проблеми. Твърде вероятно може да се наложи ядрото да се прекомпилира, което определено би било проблем.

Относно conntrack вдигнал съм го на 65535, прекомпилирането на ядрото не е проблем но до момента невиждам режение което го налага. Лимитирането на сесии най ефективно ми се струва.
Направих опит на gw зад който е машината която атакувам да сложа:
iptables -I FORWARD -p tcp -s bad-flooder -d good-target -m state --state NEW -m recent --set
iptables -I FORWARD -p tcp  -s bad-flooder -d good-target  -m state --state NEW -m recent --update --seconds 60 --hitcount 200 -j DROP
И conntrack не се препълни по обесними причини.

Сега пробвай hping3 с --rand-source. Твърде вероятно пак ще успееш да препълнеш таблицата.

Здравейте и аз имам проблем с hping3 --rand-source, рутера (debian lenny) ми зависва до края на атаката, и след това интернета пак тръгва.

iptables -I FORWARD -p tcp -m state --state NEW -m recent --set
iptables -I FORWARD -p tcp -m state --state NEW -m recent --update --seconds 60 --hitcount 100 -j DROP
Връзваш всяко IP s MAC през ARP.
Настройваш си Swith-a на един порт да позволява възможно най малко адреси.


И туковиж помогнало , но това  не е адекватно решение а марoдерщина , въпросното нещо би помогнало ако атаката излиза зад твоя рутер :)