готино
От: Hapkoc <sasoiliev_trash (a) mail< dot >bg>
На: 28-07-2005@15:21 GMT+2
Оценка: 1/Неутралени простичко.
чудил съм се как може да се направи такова нещо - мерси. :)
[Отговори на този коментар]
За нищо :)
От: Vladsun
На: 28-07-2005@16:42 GMT+2
Оценка: 1/НеутраленКогато го пооправя да следи и за последователността на отваряне на портовете ще стане още по-добре :)
[Отговори на този коментар]
Knockd
От: lamBy <lamby< at >disnetbg__dot__com>
На: 28-07-2005@17:07 GMT+2
Оценка: 1/НеутраленРешението при мен е с
http://www.zeroflux.org/cgi-bin/cvstrac...
knockd.
Демон който слуша за последователност на
точно определени пакети по ТСП и УДП, и
изпълнява определена команда предварително
описана в определен файл :)
Статията е добра, но може би трябва да се
обясни малко повече за Защитните
стени /iptables/, все пак услугата която е
описана е пряко свързана с нея.
Поздрави СЛ.
[Отговори на този коментар]
Ре: knockd
От: Vladsun
На: 28-07-2005@20:58 GMT+2
Оценка: 1/НеутраленИнтересно, ще го разгледам тия дни. А за обясненията - почнах статията с много ентусиазъм, ама много писане стана ... ;) По-нататък ще я пооправя :)
[Отговори на този коментар]
порт почуквания...
От: х:х
На: 29-07-2005@12:51 GMT+2
Оценка: 1/НеутраленЦялото нещо като концепция е с пукнатини (flawed). Защо? Защото тези "порт почуквания" могат да се подслушват и да се възпроизведат доста лесно. Верно, по-сигурно е от нищо, но определено не е най-добрият вариант.
Дори да се използва криптиран стринг, за да се замаскира последователността, пак има реална възможност да се злоупотреби.
Друга възможност може да бъде ssl защитен сайт, изискващ аутентикация. После, от такова място може да се изпълни команда с повишени привилегии.
Има и далеч по професионални подходи за отдалечен достъп от недефинирани източници.
*swan roadwarrior например.
[Отговори на този коментар]
Ре:сигурност
От: Vladsun
На: 29-07-2005@15:35 GMT+2
Оценка: 1/НеутраленНе съм много съгласен защото:
1) 99,9% от атаките не са от потребители, които могат да подслушват канала за връзка;
2) трябва да има априорна информация за наличието на такава защита за да се прави нарочно подслушване на канала за последователността на портовете;
3) в случай на прилагане на същата техника за позволяване на достъп до други сърверни услуги, в частност до SSL сайта, какво ще е предложението?
4) статията дава основи за подхода и пример; не се твърди, че е изчерпателна или най-доброто в областта;
[Отговори на този коментар]
И като допълнение....
От: Topper <topper (a) data[ точка ]bg>
На: 29-07-2005@18:05 GMT+2
Оценка: 1/Неутрален Влади, това е страхотен похват ;) На мен не ми бе дошъл на ум... Но статията ме наведе на друга мисъл - защитата от опити за влизане през SSH, за което аз ползвам нещо доста ефективно, малко (т.е. ефектно) и богато на възможности, а имено: Denyhosts http://denyhosts.sourceforge.net/featur... На базата на тази програма (понеже автора я беше изоставил малко, до скоро) има и друга разработка - BlockHosts http://www.aczoom.com/cms/node/16 , но сега DenyHosts се развива шеметнор почти всеки ден автора публикува подобрения. И двете работят на базата на сканиране на логовете за сигурност (или месидж логовете, според случая)и в основата им е блокиране на хостове посредтвом hosts.deny и hosts.allow Може би ще е по-добре да ги обсъдим във форума?
Редактиран на: 29-07-2005@18:06
[Отговори на този коментар]
или
От: kostadinz
На: 29-07-2005@19:30 GMT+2
Оценка: 1/Неутраленssh сървъра може да дебне наличието или липсата на някакъв файл/файлове във web сървър някъде по света (може и да е фрее) и да дава или отказава достъп до портовете.
А може и да дебне дали ще бъде пингнат от точно определено ИП (пак от машина на която имаш акаунт)
[Отговори на този коментар]
или ;)
От: Vladsun
На: 29-07-2005@20:34 GMT+2
Оценка: 1/НеутраленИли може да се сложи GSM устройство и да се приемат команди през DTMF :) - искам да кажа: вариантите за постигане на поставената цел са адски много. Статията имаше за цел не толкова да се конкретизира върху сигурността на SSH, а да се покаже похват за построяване на променяща се в зависимост от текущите условия защитна стена. Приложенията на такава стена са също така много. Съжалявам, че не съм успял да го подчертая ... наистина!
[Отговори на този коментар]
Доста сложно решение
От: Nasko
На: 30-07-2005@11:00 GMT+2
Оценка: 1/НеутраленВярно е, че това доста би повишило
сигурността, но според мен е достатъчно да
се забрани достъпа с Име/Парола до SSH. Така
на потребителите които трябжа да имат достъп
се дава защитен с парола частен ключ, а на
сървъра остава съответният публичен. Всички
опити за налучкване на акаунт за сървъра са
обречени на неуспех.
Единствен недостатък е че порт 22 седи
отворен и мойе да се извлече малко
информация за системата, напр. версия на
SSH.
Но пък модификация в за6титната стена и
*.pl ...?
[Отговори на този коментар]
re: *.pl?
От: Vladsun
На: 30-07-2005@20:59 GMT+2
Оценка: 1/Неутрален Хипотетично ... ако всички портове на един сървер са затворени за външния свят, то всякакви експлойти на сърверни приложения стават безполезни, нали? Може би е крайно време да променя името и малко от съдържанието на статията за да стане по-обща.
И не виждам нищо сложно в решението :)
ПП: това "Но пък модификация в за6титната стена и *.pl ...? " не го разбрах ...
Имаше време, когато потребителя звънеше по телефона за да се променят правилата на защ. стена и да бъде допуснат до услуги :)
Редактиран на: 30-07-2005@21:03
[Отговори на този коментар]
или просто да се промени порта
От: Мариан Гацев <gacev__at__fmi< dot >uni-sofia< dot >bg>
На: 31-07-2005@14:23 GMT+2
Оценка: 1/НеутраленТози порт 22 наистина стана много популярен в последно време ;-). Мился си, че поне за тези машини, на които се влиза през ssh само от няколко човека, трябва да бъде променен порта от 22 на някой нестандартен и трябва да се влиза само с публичен ключ. Иначе това не елиминира port knocking-а.
[Отговори на този коментар]
Промяна на порта
От: growchie <growchie __@__ yahoo __точка__ com>
На: 1-08-2005@11:18 GMT+2
Оценка: 1/НеутраленНаистина това е доста просто и добро решение. Шибаните скриптове са ужансно тъпи и блъскат като гламави само на 22 порт. ако в защитната стена се направи един списък с безопастнике хостове за тях може да се остнави и порт 22. Иначе може да се използва порт редирект да речем на порт 1212 (повечето кухи скриптове не се занимават с портове над 1024) към порт 22 за останалите. и не забравяйте ако политиката на веригата е DROP, правилото което блокира достъпа също трябва да е DROP (или Reject-Reject съответно). Иначе снифърите ги откриват като портове в стелт режим.
[Отговори на този коментар]
Точно това !?
От: Topper <topper__at__data__dot__bg>
На: 2-08-2005@8:01 GMT+2
Оценка: 1/НеутраленАми май точно такова решение ви предложих - denyhosts или blockhosts ! Само че нямаше смислена рекация, може би защото обичаме да ни е трудно :/ Както и да е - хората са открили топлата вода и го правя успешно.
[Отговори на този коментар]
Жалко :(
От: Vladsun
На: 3-08-2005@9:07 GMT+2
Оценка: 1/НеутраленЩеше ми се да се бяха получили повече съзидателни отзиви за статията - за грешки, възможни подобрения и др.
Нека приемем, че статията не е специално за защита на SSH и да я разглеждаме по-общо, като инструмент за дистанционно отваряне/затваряне на определен порт.
Аз веднага си намерих грешка :) :
в правилата за "почукването" не трябва да е DROP, a RETURN. Иначе има опасност да отрежем някой порт, който ни трябва.
[Отговори на този коментар]
Въобще не е жалко
От: growchie <growchie__at__yahoo[ точка ]com>
На: 4-08-2005@8:19 GMT+2
Оценка: 1/НеутраленСтатията ти е много добра. Проблемът е, че търсех точно решение как да се справя с проклетите червеи и за този случай не ми се наложи да правя толкова сложно решение. Проблемът идва то това, че трябва да се почука на портовете преди логин. Или трябва да се ползва скрипта който си написал, или да се направи ръчно телнет на портовете в опререления ред и чак след това ССН. Когато си на почивка или имаш няколко потребитеря, които се логват това не е най-гъвкавото нещо. Аз направих елементарен редирект от друг порт към порт 22 за недоверените адреси и оставих 22 порт за доверените (сейф листинг), като този редирект прави и едновревенно с това почукването. Не е и на половина толкова сигурно като това но благодарение на него вече червеите не ми пълнят лога. В този смисъл статията ти ми беше доста полезна.
[Отговори на този коментар]
Що не ползваш LOG като таргет
От: growchie <growchie (a) yahoo[ точка ]com>
На: 4-08-2005@12:13 GMT+2
Оценка: 1/НеутраленВинаги е добре да се зане кой и кога се закача. Едно логче на полукванията няма да е зле. Освен това може да пуснеш проверка за опит за сканиране да речем на няколко ниски порта и ако се види такава екстра да се забранява за да речем един ден това ИП. Сега като си мисля не е зле да се направи проверка за всички ИП-та които се закачат да речем на 22, 25 и 80. Ако някой го прави независимо в какъв порядък в интелрвал по-малък от да речем 3 минути значи може и да е сканиране.. Ако е така логваме го. Мм като се прибера ще го пробвам това.
[Отговори на този коментар]
DoS
От: iive <iive__at__abv[ точка ]bg>
На: 4-08-2005@13:59 GMT+2
Оценка: 1/НеутраленМетодът с почукването е интересен, но...
Въпросът е в проблемите които можем да си навлечем с такава система.
Примерно ако някой започне случайни почуквания по машината, дали това би затруднило собственика да направи правилното почукване и по този начин да му отреже достъпа.
[Отговори на този коментар]
Re: DoS
От: Vladsun
На: 4-08-2005@15:15 GMT+2
Оценка: 1/Неутрален Има шанс за такова нещо ... мислил съм го и стигнах до извода, че най-добрия вариант е да се добави защита от сканиране на портове базирана отново на recent-match-a и limit-match-a за новите връзки. По този начин само сканиращото ИП ще бъде отрязано. Ако сканирането е прекалено бавно (за да се избегне тази защита), то тогава описаното почукване ще има време да отключи порта. Така дори и DoS атака от потребител с предварителна информация за това, кои са заключващите портове няма да е успешна.
ПП: Трябва да се има предвид, че защитата дейтва само в етапа на установяване на възка. Т.е. при установена връзка DoS няма.
Редактиран на: 4-08-2005@20:28
[Отговори на този коментар]
Re: LOG
От: Vladsun
На: 4-08-2005@20:24 GMT+2
Оценка: 1/НеутраленЗа почукванията от ЛОГ няма нужда - има нужда от ЛОГ на опитите са сканиране на портове.
Виж, за по-ниските портове (21, 22, 25) логване и забрана за изветно време има смисъл, но трябва да се комбинира с "бял списък" от ИП-та за да се избегне неволното блокиране на достъп.
А по отношение на техниките за PSD (Port-Scan-Detection) има няколко метода, но най-правилния е следене на критерии за точно оперделнео ИП, а не глобално. Точно в тази насока recent-match-a ми е любим защото се пази инфомрация за всяко отделно ИП. С конвенционалните методи от сорта на:
#Furtive port scan
$ipt -N port-scan
$ipt -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j port-scan
$ipt -A port-scan -m limit --limit 10/s --limit-burst 20 -j RETURN
$ipt -A port-scan -j DROP
#Syn-flood protection
$ipt -N syn-flood
$ipt -A INPUT -i eth1 -p tcp --syn -j syn-flood
$ipt -A syn-flood -m limit --limit 20/s --limit-burst 20 -j RETURN
$ipt -A syn-flood -j DROP
се прилага глобално правило, което може да доведе DoS.
[Отговори на този коментар]
Ти в скриптове ли си пишеш правилата?
От: growchie <growchie __@__ yahoo[ точка ]com>
На: 5-08-2005@13:45 GMT+2
Оценка: 1/НеутраленИнтересен подход (в БСД така го правят). Аз ползвам iptables-save iptables-restore. Незнам как е по-правилно. Във всеки случай не ми харесва как графичните фронт-енди генерират правилата.
[Отговори на този коментар]
Re: Скриптове
От: Vladsun
На: 5-08-2005@16:49 GMT+2
Оценка: 1/Неутрален:)
За първоначално генериране ДА :)
Иначе за по-бърз рестарт НЕ :)
Т.е. при мен реда е:
init iptables (script)
iptables_save
..........
reboot
iptables_restore
.............
change iptables (script)
iptables_save
.............
reboot
iptables_restore
Иначе, без скриптове, не знам как ръчно ще се добави двойчно-дървовидна структура за обхождане на цяла мрежа (с цел намаляване на правилата през, които минава всеки пакет) - или поне не за повече от 2 мин. :)
ПП: Графична среда на моите сървери не съм виждал :)
[Отговори на този коментар]
Добро!
От: v_o_y_a_g_e_r <voyager123bg (a) yahoo __точка__ com>
На: 16-08-2005@18:03 GMT+2
Оценка: 1/НеутраленБраво за статията, и аз се занимавах преди известно време с този въпрос, мисля трябва да се спомене за този сайт: http://portknocking.org/
:) приятно четене
[Отговори на този коментар]
Или друго решение на тази база
От: Topper <topper< at >data __точка__ bg>
На: 7-09-2005@9:47 GMT+2
Оценка: 1/НеутраленИли пък този сайт - интересни решения !
http://doorman.sourceforge.net/
[Отговори на този коментар]
Грешни правила
От: denikide <denikide__at__gmail __точка__ com>
На: 28-04-2007@11:06 GMT+2
Оценка: 1/НеутраленКато цяло това нещо е супер. Обаче има няколко проблема с правилата така както са написани. Първо там където е -j RETURN при последователно сканиране на портове ще си сетнем ип адреса в /proc/net/ipt_recent/SSHK тък като този -j RETURN не позволява на следващите правила да изтрият записа от SSHK. Правилно би било в случая да се сложи този -j RETURN след последният --remove. Друго при подразбиращ се DROP на INPUТ веригата също няма да сработи защото ще мине само NEW пакета към 22, а всички останали от TCP сесията към 22 порт ще бъдат дропнати. Ако добавим и предложението за LOGване на сканиране по тези портове, обобщено правилата може да се дооформят така:
iptables -N SSH_KNOCK
iptables -I INPUT 26 -m state --state NEW -p tcp -j SSH_KNOCK
iptables -I INPUT 27 -p tcp --dport 22 -i ethХ -j SSH_KNOCK
iptables -A SSH_KNOCK -p tcp --dport 22 -i eth0 -m recent --rcheck --name SSHK -j ACCEPT
iptables -A SSH_KNOCK -p tcp --dport $port -m recent --name SSHK --set -j DROP
iptables -I SSH_KNOCK 3 -p tcp -m state --state NEW --dport 12211 -j LOG --log-prefix " Someone is knocking port 12211 "
iptables -A SSH_KNOCK -p tcp --dport $prev_port -m recent --name SSHK --remove -j DROP
iptables -I SSH_KNOCK 3 -p tcp -m state --state NEW --dport 12211 -j LOG --log-prefix " Someone is knocking port 12213 "
iptables -A SSH_KNOCK -p tcp --dport $next_port -m recent --name SSHK --remove -j DROP
iptables -A SSH_KNOCK -m recent --rcheck --name SSHK -j RETURN
iptables -A SSH_KNOCK -p tcp --dport 22 -j DROP
[Отговори на този коментар]