Изпечатай

[VladSun]

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

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

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

[teh]

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

[tmcdos]

@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 има доста интересни статии.

[VladSun]

Цитат (tmcdos @ Юни 01 2007,15:12)

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

За запълването на входящия канал - определено няма спасение.

Но за ДоС има ... В днешно време ДДоС е големият ужасТ.

[teh]

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

[tmcdos]

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

[teh]

@VladSun

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

[VladSun]

Цитат (teh @ Юни 01 2007,15:58)

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

Не са - просто са с оценка по-малка от 1 и не се виждат по подразбиране ...

Чакам ...

[teh]

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

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

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

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

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

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

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


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

[teh]

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

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

[VladSun]

Цитат (teh @ Юни 01 2007,16:22)

1. Домашни почти не, но корпоративни има много. Я се сетил да сложи white list, я не '> 2. Според мен по удачния начин за brute force защита ще е на application ниво.

по 1. - Е, аз за какво съм сложил тоя "white list" навсякъде?
по 2. - Съгласен до някъде, но мисля, че много се отклоняваш от същинската тема на статията "Адаптивна защитна стена". Показвам как се осъществява адаптация на защитна стена при откриването на атака. Никъде не съм казал: задължително използвайте идентифицирането за тази, тази и тази атака. Всеки е в свободата си да избере какви атаки да предизвикват адаптацията... Приеми го като framework. '>

ПП: Все пак има малка разлика - ако осъществяваш bruteforce защитата на application level по този начин, то няма да защитиш машината от други видове атаки към машината от същия хост.

[gat3way]

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

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

[teh]

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

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

[VladSun]

Цитат (teh @ Юни 01 2007,16:54)

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

Ти така и не се обоснова убедително ...

Е ли пък да ми отговориш за любимите ти сини бисквитки ...