C, PHP, VB, .NET

„Brute Force“ е атака, при който атакуващият изпраща множество заявки към сървъра с различни двойки от име и парола, с цел да „налучка“ някоя правилна комбинация. Най-често на атака са изложени потребителски имена като „admin“, „administrator“, „root“, и т.н. По този начин атакуващият се опитва да получи достъп до даден защитен ресурс, без да използва пробив в сигурността.

Първото и основно правило за защита срещу brute force атаки е да използваме колкото се може по-сложни пароли. Обикновено тези атаки изпробват набор от речникови думи, имена и понякога цифри. Освен това, независимо колко сложна е вашата парола, не е добра идея да я използвате за всички сайтове, на които влизате (най-малкото администратора на чуждият уеб сайт ще може да проникне във вашия личен).

Независимо колко стриктна и добра политика използваме за паролите ние не бихме искали да позволим някой да изпробва стотици комбинации от имена и пароли върху вашата система. Най-малкото не сме сигурни дали някой от нашите потребители не използва лесна за разгадаване парола – например името си в комбинация с годината на раждане: „Иван1978″. Една целенасочена атака срещу този потребител би изпробвала различни комбинации от данни, които са свързани с потребителя Иван. Паролата от своя страна изглежда сигурна (съдържа и думи и цифри) и би преминала вашия валидатор. Поради тази причина е наложително да се защитите, като едновременно с това не затруднявате потребителя излишно.

1. Captcha: вече разгледахме използването на Captcha за целта за спиране на автоматизирани brute force атаки. Това е може би най-ефективният разработен досега метод за справяне с проблема на автоматизирани атаки. За съжаление този подход определено затруднява потребителите, като отнема допълнително време при всяко влизане в системата. Captcha е подходяща за защита на форми, които се попълват еднократно (например форми за регистрация). Когато става дума за форми за автентикация, които се попълват ежедневно, то въпросът е спорен. Всичко зависи от това до колко конфиденциална информация пазите и дали си заслужава да затруднявате потребителя с попълването на форма с captcha всеки път. Освен това captcha не решава друг проблем – не е казано, че една brute force атака трябва да е автоматизирана. Не е изключено човек ръчно да изпробва различни комбинации от имена и пароли. Все пак не говорим за ограничения във времето…

2. Блокиране на IP след определен брой неуспешни опита за влизане: можете да си съставите база от данни със списък от IP адреси, които са направили неуспешен опит за влизане в системата. За всеки IP адрес трябва да се пази и втора колона със брой неуспешни опити за достъп. По този начин, преди да извършите проверка за автентикация на данните, може да проверите дали текущото IP не е „прекалило“ с грешните опити за вход в системата и ако това е така – да го пренасочите към друга страница, която му предоставя информация как да си поиска от вас загубената парола. В зависимост от типа потребители на вашата система можете да блокирате не само отделни IP адреси, но и цели зони (IP range). При успешно автентикиране в системата от даден IP адрес, неговите записи в базата от данни за неуспешни влизания трябва да бъдат изтрити, за да се избегне натрупване на случайни грешки през големи интервали от време. Чрез метода за блокиране на IP се справяте не само с автоматизираните атаки, но и с атаките извършвани от човек. Честа практика (с цел редуциране на заявките за отблокиране на IP адреси към екипа за техническа поддръжка) е да не блокирате потребителите перманентно, а само за определено време (например един час). Така обаче защитата само „отлага“ атаката, а не я предотвратява.

3. Лимит на максималния брой заявки към сървъра чрез защитна стена: един IP адрес би могъл да изпрати множество заявки за автентикация към сървъра едновременно. По този начин ние все още няма да имаме запис за това IP и бихме могли да позволим на заявките да преминат „бариерата“ от предишната точка. Обикновено не е разумно да натоварвате самото приложение със следене на броя заявки към него. Добре е да сложите такъв лимит на вашия http сървър и на вашата защитна стена (firewall). Например за iptables може да използвате модула „connlimit“.

4. Лимит на максималния брой заявки към сървъра чрез приложението: ако все пак искате да се подсигурите и да предотвратите напълно едновременно подадените заявки за автентикация, то може да организирате приложение от тип „опашка за автентикация“. Всяка заявка за автентикиране се вкарва в структура от данни тип FIFO (first in – first out) и така сме сигурни, че никога няма да бъдат изпълнени няколко едновременни заявки към базата от данни. Този метод обаче трябва да се използва изключително внимателно и изисква сериозна оптимизация с цел бързодействие. Добре е да се погрижите да има равностойно бързодействие на базата от данни спрямо http сървъра. В противен случай рискувате да получите претрупване на опашката и много клиенти да получават timeout. Затова е добре в http сървъра да пазите cache от познати „лоши“ IPта и да не им позволявате да влизат в опашката за автентикация повторно. Периодично трябва да филтрирате сървъра чрез защитната стена от подобни IP адреси, които правят постоянни заявки. Това ще бъде разгледано в темата за DDoS атаки. При мултипроцесорни сървъри (каквито са почти всички нови компютри в днешно време) е добре да се възползвате от използването на нишки за съставянето на няколко опашки за автентикация (в зависимост от броя процесори на сървъра за базата от данни). Не е разумно да се лишавате напълно от бързодействието и функционалностите на сървъра си само и единствено с цел защита. Ползата от „опашка за автентикация“ по принцип е спорна и в повечето случаи се оказва излишна.

5. Политика за блокиране на акаунти: става дума за атаки от т.нар. „bot nets“. Това са мрежи от различни IP адреси, които атакуват сървъра. Често това са инфектирани с вирус компютри на нищо неподозиращи потребители в Интернет. Мащабът на такава мрежа може да бъде огромен. Също така не е задължително те да атакуват по едно и също време  (което всъщност би причинило по-скоро DDoS атака), а през кратки интервали. Тук тактиката с блокиране на отделно IP след неуспешен брой опити за вход би била неуспешна, защото всяко едно IP от атакуващата мрежа само за себе си има определен брой опити. Ако например сме сложили лимит от 5 неуспешни опита за IP адрес, то една мрежа от 1000 IPта би имала 5000 опита. Когато те атакуват определен акаунт (администраторския или на някой определен потребител), то би трябвало да се почувстваме застрашени, защото ще изпробват прекалено много различни комбинации от възможности (тъй като това е „targeted“ атака, то атакуващите обикновено са разузнали за определена информация за дадения потребиел). За да се защитим от такава атака е добре да пазим допълнително поле в базата от данни, в която се съхраняват имената и паролите. Това поле трябва да съдържа общия брой неуспешни опити за влизане към дадения акаунт. Когато се извършва автентикацията е нужно да се провери този запис и ако броя опити за пробив е голям, то е добре да се направи т.нар. „заключване на потребителския акаунт“ (account lockdown). Системата няма да позволи достъп до такъв потребителски акаунт, докато администратор не „отключи“ акаунта. По този начин можете да съставите списък от атакувани акаунти и да се погрижите техните пароли да са достатъчно сигурни или да търсите индивидуално решение на тяхната защита.

6. Фиксиране на акаунт по IP адрес: в случай на зачестили атаки към определен акаунт може да въведете функционалност за стриктно следене на IP адреса, от който влиза. Това е честа практика при администраторските акаунти.

Задача: Реализирайте описаните практики на някой език за web програмиране. Помислете за допълнителни варианти за защита.