|
|
|
Съвети>Сигурност
|
Проста защита за SSH атаки (bruteforce, dictionary)
|
|
|
|
|
|
от Vladsun(12-09-2006)
рейтинг (22)
[ добре ]
[ зле ]
Вариант за отпечатване Повечето администратори виждат огромни логове за неуспешни
(дай боже;) ) опити за SSH логин чрез използване на слаби
пароли и често срещани потребителски имена. С увеличаването
на броя на потребителите, които се нуждаят от SSH достъп до
конзолата се увеличава и вероятността от пробив.
Съществуват много начини за защита от подобен вид атаки
(bruteforce или dictionary). Нека споменем някой от тях:
- смяна на порта на SSH услугата;
Често срещана практика, но при нарочна атака срещу самия
сървер лесно ще се открие на кой порт слуша sshd deamon-a.
Веднага ще се появят предложения за ползване на PSD (port
scan detection), но по същество PSD техниката
"опазва" всички портове, а не само определен. С
използването на подходящи опции на nmap, тази защита би
могла да се прекочи. Следващ проблем е man-in-the-middle
атаките, при които лесно се открива кой порт е за sshd. След
откриването на SSH порта започва втора атака насочена срещу
самите пароли;
- блокиране на определени ИП-та за определено време чрез
следене на системните логове;
Има много проекти базирани на този метод. На мен лично не
ми харесва идеята за периодичността на проверка на логовете.
- забрана за използване на user/pass, разрешаване само на
key-authorization;
Чудесна защита, стига обстоятелствата да ви позволяват
такова решение.
Предлаганото от мен решение се характеризира със следните
свойства:
- защита само на порт 22;
- защита при атаки от типа bruteforce и dictionary;
- липса на периодичност на проверка за невалидни опит за
логин;
- липса на зависимост от системните логове;
- простота на изпълнението;
- лесна промяна на параметрите на защитата;
Като нужен софтуер използвам само iptables + recent
patch-a. Не забравяйте да компилирате recent match-a като
модул за да можете да променяте дължината на таблиците от
ИП-та.
В защитната стена добавяме:
Защитна
стена |
iptables -N SSH
iptables -A INPUT -p tcp --dport 22 --syn -j SSH
iptables -A SSH -p tcp -s 127.0.0.1 -j RETURN
iptables -A SSH -p tcp --syn --dport 22 -m recent --name
bad_ssh --update --seconds 60 -j DROP
iptables -A SSH -p tcp --syn --dport 22 -m recent --name
bad_ssh --set -j RETURN |
Какво правят тези правила?
Първо се прихващат само опитите за инициализация на SSH
сесия. След това се проверява дали IP адреса от който се
получава този опит не е вече в списъка (bad_ssh) със следени
ИП-та и ако е се проверява дали интервала от времето на
последния му опит за инициализиране на SSH сесия към
текущото време е по-малък от 60 сек. Ако не, то syn-пакетa
се отхвърля и едновременно с това се обновява времето на
последния опит за връзка на това ИП. Ако ли да, то пакета
продължава по веригата надолу, като в същото време се прави
запис за времето на опит за достъп и ИП-то в списъка.
Ефектът от обновяването на времето при повторен опит е, че
се изисква поне 60 сек. следеното ИП да не прави повторен
опит за достъп.
С тези защитни правила би могло да се счита, че защитата е
изградена. Но съществува едно явно неудобство - дори при
валиден опит за достъп до SSH услугата, трябва да се изчакат
60 сек. за създаване на втора SSH сесия (лично аз отварям по
няколко конзоли). За преодоляването на това неудобство е
нужно да се следи кое ИП има валиден достъп до SSH сесия и
за него горните правила да не важат. Проверката за валидност
на сесията я правя чрез .bash_profile - изпълнява се при
всеки валиден логин на потребителя.
Създаваме (ако не съществува) .bash_profile във всяка home
директория на всеки потребител, който искаме да защитим. В
тези файлове трябва да има реда:
Код |
sudo
/usr/local/sbin/ssh_user_allow |
Забележете, че се използва sudo, така че групата
(или потребителите) трябва да са описани в /etc/sudoers
файла с root права за пускане на
/usr/local/sbin/ssh_user_allow. Това се налага заради 0644
разрешенията на /proc/net/ipt_recent/* файловете.
Самият файл /usr/local/sbin/ssh_user_allow е със следното
съдържание:
ssh_user_allow |
user_ip=`echo $SSH_CLIENT |
awk '{print $1}'`
echo "-$user_ip" >
/proc/net/ipt_recent/bad_ssh |
Какво прави той?
Първо намира ИП-адреса на логнатия потребител и второ
премахва ИП адреса му от списъка със следените ИП-та.
По този начин iptables правилата описани по-горе няма да
задействат защитата по ИП/време.
Възможно е вместо описания начин за разрешаване на вече
логнати потребители, към iptables правилата да се добави и
--hitcount параметъра. По този начин се указва колко опита
(валидни или не) за определен период от време (в случая 60
сек.) ще се допускат. Проверка за валидност на логин-а не се
прави.
<< Полезни съвети за Firefox | Блокиране на автоматизирани атаки под Линукс и *BSD >>
|
|
|
|
|
Още един метод, който ми е известен От: foxb На: 14-08-2006@14:51 GMT+2 Оценка: 1/НеутраленИма още един метод- Port Knoking
По същество той се състои в използването на клиент, който извършва достъп до точно определени портове при което се разрешава на съответния адрес да използва порт 22.
Предимство --> защитени сте от сканиране
[Отговори на този коментар]
Към: Още един метод, който ми е известен От: Vladsun <vsmin (a) mail__dot__bg> На: 14-08-2006@15:10 GMT+2 Оценка: 1/Неутрален:)
Е, да ;)
http://www.linux-bg.org/cgi-bin/y/index...
От VladSun :) :) :)
Редактиран на: 14-08-2006@15:11
[Отговори на този коментар]
Към: Към: Още един метод, който ми е извес От: Ali Baba <alabala (a) mail__dot__bg> На: 15-08-2006@6:01 GMT+2 Оценка: 1/НеутраленАз съм си на 22 порт но е описано от кое IP и в SSH-a пише само 1 user който има право да влиза.
[Отговори на този коментар] Към: Към: Още един метод, който ми е извес От: growchie <growchie__at__yahoo[ точка ]com> На: 15-08-2006@7:06 GMT+2 Оценка: 1/НеутраленДоба идея е да се прибави и списък с безопасни хостове. Нещо от рода iptables -A SSH -s "bezopasno IP" -j ACCEPT. Сащо така наситина бих препоръчал и смяна на порта на който работи ССХ. В повечето случаи това е напълно достатъчно.
[Отговори на този коментар] Към: Към: Към: Още един метод, който ми е извес От: Vladsun <vsmin< at >mail< dot >bg> На: 15-08-2006@10:22 GMT+2 Оценка: 1/НеутраленКакто казва по-долу gat3way - в един ethernet сегмент става страшно - т.е. няма безопасни ИП-та.
И още нещо дребно (но понякога важно) - нека ако слагаш такъв бял списък, правилото да не е:
iptables -A SSH -s "bezopasno IP" -j ACCEPT
а
iptables -A SSH -s "bezopasno IP" -j RETURN
По-безопасно е - SSH веригата трябва да остане само и единствено по предназначението си.
[Отговори на този коментар] Към: Към: Към: Към: Още един метод, който От: growchie <growchie__at__yahoo[ точка ]com> На: 15-08-2006@10:50 GMT+2 Оценка: 1/НеутраленЗависи от мащаба на мрежата. За големи мрежи си прав. Но от друга страна става въпрос за автоматизирани атаки и ако някой прави глупости от вътрешната ти мрежа, не е проблем да му набиеш обръчите. Аз в списъците обикновено слагам IP адреси извън локалната мрежа за които съм сигурен (например домашен статичен публичен адрес). За ACCEPT по принцип слагам политиките да са по подразбиране DROP на всички вериги въпреки, че си заслужада да помисля дали е разумно да се излиза от SSH веригата. Въпреки, че съображението ми беше, че няма какво повече да правя с този пакет по принцип и ми се стори добра идея да го пусна веднага.
[Отговори на този коментар] Към: Към: Към: Към: Към: Още един метод, който От: Vladsun <vsmin __@__ mail[ точка ]bg> На: 15-08-2006@13:09 GMT+2 Оценка: 1/НеутраленПросто съм си изградил правила, които спазвам когато пиша в rc.firewall:
1. Никога не използвам -I, винаги -A: иначе рискувам да се загубя в правилата;
2. Във вериги, които имат за предназначение да филтрират пакети (DROP, REJECT, TARPIT), не използвам ACCEPT - някъде по-надолу може би има (или в бъдеще ще има) друго филтриращо правило, което влияе на пакета.
3. ACCEPT правилата са ми винаги в края на rc.firewall;
Мисля, че при стена от 500 реда на горе спазването на тези правила е добра идея.
[Отговори на този коментар]
И да не забравяме едно от основните правил От: growchie <growchie< at >yahoo __точка__ com> На: 15-08-2006@7:20 GMT+2 Оценка: 1/Неутрален"PermitRootLogin no"
[Отговори на този коментар] ssh security.. От: gat3way <mrangelov__at__globul[ точка ]bg> На: 15-08-2006@8:26 GMT+2 Оценка: 1/НеутраленПолзването на keys при публично достъпни машини според мен не е добра практика. Злите хахори руут-нат ли една машинка, отнасят и всички останали без особени проблеми - тръгвайки просто да установяват ssh връзки до всичко, що е описано в known_hosts.
Добрата практика според мен включва хост-базираната автентикация (т.е връзваш се само от определени места). TCP spoofing-a е много трудно начинание извън рамките на един етернет сегмент. За допълнителна сигурност може да се позволят връзки само от една добре секюр-ната машина, на която работи единствено vpn server с подходяща автентикация. Връзваш VPN-a с някакъв key, после с password-базирана автентикация достъпваш sshd-тата на другите машини.
В рамките на един етернет сегмент обаче нещата стават груби. Има някои грозни трикове при които можеш да се правиш на машината-цел и да събираш пароли - arp spoof-ваш и чакаш конекции да речем. Самият ssh клиент вади съобщения за възможни проблеми, но не всички хора са параноици. Има и един такъв момент, че публичните ключове при sshv1 и sshv2 са различни, т.е хахора форс-не ли си "фалшивото" sshd да ползва само sshv1, а неподозиращият клиент е ползвал досега само втора версия на протокола (много често е така) и няма запазен в1 ключа, предупреждението е че няма такъв ключ, да продължи ли да се връзва (вместо да изкара онова злобно съобщение !!!!!!!HOST VERIFICATION FAILED, POSSIBLE MITM ATTACK!!!!!!). Самият sshd може много лесно да се "пач-не" така че да ти лог-ва кой с каква парола се е опитвал да се върже (знам от опит).
Естествено при това положение, ако се ползват ключове, не се налага да си параноик, за да установиш че има проблеми. Така че ако на сървър, чието sshd е отворено за машини от локалната мрежа, се ползва key-базирана автентикация, това е малко по-добър вариант...
[Отговори на този коментар] Към: ssh security.. От: ^JJ^ <devnull __@__ mail< dot >bg> На: 15-08-2006@9:38 GMT+2 Оценка: 1/НеутраленСпоред мен ССХ2 ключове със пароли е много добро решение за публични и лични машини .. така хем ключа запаролен хем марзела задволен хем сигурността добра. Единствено трябва да се внимава каде влазяш ;) да не те сгащи лошия тийн с рут права и да се възползва от ключа ти. Относно сканирането смяна на порта би било достатъчно и/или "чукане по порта" за параноиците.
Поздрави.
П.П. Гей'уей .. да вземеш да ми се обадиш ! Вземи от Жоро телефона ако не го знаеш ;).
[Отговори на този коментар] ^JJ^ aloha :) От: gat3way На: 15-08-2006@9:57 GMT+2 Оценка: 1/НеутраленАааа какво става с теб бе човек :) Не съм те чувал от ехее колко време :) Давай по icq :) <159768870>
[Отговори на този коментар] Темата От: Vladsun На: 15-08-2006@10:32 GMT+2 Оценка: 1/Неутрален Благодаря на всички за коментарите.
Имам само една забелжка - нека се придържаме към темата на статията - става въпрос за bruteforce и dictionary атаки към user/pass чифтовете на SSH.
Има много други услуги, които биха могли да се защитят по същия начин - FTP, HTTP basic authorization и т.н.
ПП: Някой да има идея как да взема текущото ИП на потребителя в .bash_profile (това дето съм го сътворил тук не ми харесва)
[Отговори на този коментар]
Към: Темата От: growchie <growchie< at >yahoo< dot >com> На: 15-08-2006@11:01 GMT+2 Оценка: 1/НеутраленВъв баш средата нямаш ли променлива SSH_CLIENT?
я пробвай echo $SSH_CLIENT
[Отговори на този коментар]
Към: Към: Темата От: Vladsun <vsmin (a) mail[ точка ]bg> На: 15-08-2006@13:01 GMT+2 Оценка: 1/НеутраленМерсиииии :)
/офф
Само не мога да разбера защо изгледа при "Преглед" и изгледа при "Публикуване" на статията е различен :(
Блоковете с програмен код са отвратителни ...
Редактиран на: 15-08-2006@13:02
[Отговори на този коментар]
Към: Към: Към: Темата От: Daemon <daemon (a) nwnbg[ точка ]ath[ точка ]cx> На: 20-08-2006@10:53 GMT+2 Оценка: 1/Неутрален### SSH ACCEPT
iptables -A INPUT -p tcp --dport 22 -s realip -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s realip -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s realip -j ACCEPT
iptables -A INPUT -i eth1 -m mac --mac-source 00:D0:B7:08:CF:C5 -p tcp --dport 22 -j ACCEPT
### SSH DROP
iptables -A INPUT -p tcp --dport 22 -j REJECT
И как ще ме хакнат така :D :D :D
[Отговори на този коментар]
Към: Към: Към: Към: Темата От: growchie <growchie __@__ yahoo__dot__com> На: 22-08-2006@9:13 GMT+2 Оценка: 1/НеутраленЛесно, като си сменят мак адреса или проведат някоя ARP атака. Освен това, този пример е в сила само в твоя мрежов сегмент.
[Отговори на този коментар]
Към: Към: Към: Към: Към: Темата От: daemon <daemon__at__nwnbg __точка__ ath __точка__ cx> На: 22-08-2006@9:26 GMT+2 Оценка: 1/НеутраленМда, аз си оставям macc-адреса на 1-ва страница
дето пише ела ми го виж :D.
Както и да е ,това правило го дадох като пример,
така или иначе не го ползвам. По-скоро исках да
дам примера с реалното IP. На мене ми е много полезно при положение че държа над 15 server-a.
A колкото до ARP атаката ти пожелавам успех.
[Отговори на този коментар] Към: Към: Към: Към: Към: Към: Темата От: Vladsun <vsmin (a) mail __точка__ bg> На: 23-08-2006@10:25 GMT+2 Оценка: 1/НеутраленСитуация: държиш сървери за хостинг, като към хостинг пакетите даваш и SSH достъп на потребителите. Няма начин да ограничаваш по ИП (за МАС адрес да не говорим).
[Отговори на този коментар] Към: Към: Към: Към: Към: Към: Към: Темата От: daemon <daemon __@__ nwnbg __точка__ ath __точка__ cx> На: 24-08-2006@10:05 GMT+2 Оценка: 1/НеутраленXaxaxaxaxaaxaxxaaxaxaxa разсмя ме :))))))))
[Отговори на този коментар] Към: Към: Към: Към: Към: Към: Към: Към: Темата От: Vladsun <vsmin (a) mail< dot >bg> На: 24-08-2006@14:19 GMT+2 Оценка: 1/НеутраленРадвам се :)
Положителните емоции са хубаво нещо :)
По темата: твоето решение е ОК, но НЕ е достатъчно гъвкаво.
[Отговори на този коментар] Към: Към: Към: Към: Към: Към: Темата От: gat3way На: 6-09-2006@20:54 GMT+2 Оценка: 1/НеутраленТи от тези хора които вярват, че снифенето в switched среда е невъзможно ли си или просто всичките ти суичове са умни и с дефиниран коректно порт секюрити? Имам ли root достъп до която и мрежа в твоя етернет сегмент рано или късно ще разбера кой е този мак адрес, на който е позволено да се връзва..по-точно в момента в който някой се върже на 22-тия порт на машината. А и между другото, така ще се връзва само някой от твоят етернет сегмент, отвън няма никакъв начин да му знаеш мак адреса. Както и да е.
МАК адресът мога спокойно да си го подправя. АРП атака не ми се налага да правя срещу твоята машина, но и да ми се налагаше, какво ще направиш, статични АРП таблици на всяка машина ли ще слагаш? Тебе не те мързи явно да ги променяш на 15 станции всеки път когато вкараш нов мрежов интерфейс в твоята мрежа.
Абе, ВСИЧКИ решения уповаващи се на някакви проверки на мрежовия слой са малоумна работа..ethernet си остава най-несигурния протокол, каквото и да говорите..
[Отговори на този коментар]
Към: Темата От: none2 На: 24-08-2006@22:19 GMT+2 Оценка: 1/Неутраленhttp://freshmeat.net/projects/sshban/
[Отговори на този коментар]
Към: Към: Темата От: Vladsun <vsmin__at__mail__dot__bg> На: 25-08-2006@11:01 GMT+2 Оценка: 1/Неутрален... Предлаганото от мен решение се характеризира със следните свойства:
...
- защита при атаки от типа bruteforce и dictionary;
- липса на периодичност на проверка за невалидни опит за логин;
- липса на зависимост от системните логове;
...
sshban is simple daemon designed to ban SSH flooders, using a pipe to receive data from syslog.
[Отговори на този коментар]
Вариат на правилата със БЯЛСПИСЪК От: Неутрален На: 18-09-2006@13:10 GMT+2 Оценка: 1/Неутраленhttp://blog.andrew.net.au/2005/02/16#ip...
[Отговори на този коментар]
SSH от чужбина от най-различни адреси От: ходещия На: 17-10-2006@21:02 GMT+2 Оценка: 1/НеутраленЗдравейтел
Интересна дискусия сте заформилил
Имам следния проблем-налага ми се да пътувам по чужбините и оттам да се логвам към една машинка тука в БГ.В момента съм сменил порта и съм разрешил логването само на три потребителя които после вече стават root но се появи друг проблем, уакзания от мене порт е нестандартен и често е забранен от админите на мрежите които се налага да ползвам. Често това са офиси на разни фирми, понякога хотели, най-лошото е да се ползват компютрите дето са долу в хотела до рецепцията ако не предлагат някакъв достъп по стаите за да си ползва човек лаптопа.
Та при това положение какво ще измислите за да ми е секюрната връзката?
Очевидно няма как да огранича адресите от които ще се влиза, и с порта не мога да шавам, налага се даже да ползвам неизвестни за мене машини които нищо чудно да имат и кей логър.
[Отговори на този коментар]
Към: SSH от чужбина от най-различни адреси От: Vladsun <vsmin< at >mail< dot >bg> На: 19-10-2006@23:06 GMT+2 Оценка: 1/НеутраленОт key-logger няма как да се предпазиш.
Иначе не мисля, че е много лесно, дори и с Man-in-the-Middle-Attack да се разбие една сигурна връзка като SSH, Protocol v.2.
[Отговори на този коментар]
|
|
|
|
|
|
|
|