Zdraveite,
 Imam pusnat server. Sas Slack 10 sam. Ot vreme na vreme
 vijdam ce se opitvat opredeleni IP-ta da vlezat prez SSH-a v
Linuxa.
 Idejta mi e ima li njkakva programa ili njkakva idej kak
 tocno da si napravj njkakav script koito pri njkolko
 neuspesni opita da vlezesh prez SSH avtomaticno da slaga
pravilo v IPTABLES koito da blokira tova IP na vhod?

 SSH-a nemoga da go zatvorj ce kogato ne sam do servera i
nesto se naloji rabotj prez nego ?

 Iskam naprimer pri 2 ili 3 neuspesni opita da blokira IP-to
koeto se opitva da vleze prez SSH .... 

Nadjvam se da ste me razbrali..
Blagodarj ...

 Има такива защити, наричат се Intrusion Detection System
(IDE). Аз лично ползвам Portsentry, но има и други.

 Цялата концепция на IDS (не IDE, това е друго ;) предполага
 че пускаш повече трафик към/от себе си от колкото е
 желателно. Всичкият нежелан трафик трябва да се филтрира,
 независимо какво върви в/у машината ти, още повече ако е
 маршрутизатор. Предлагам ти да разгледаш документацията на
 Netfilter (netfilter.org) и по специялно внимание да обърнеш
на mangle таблицата.

 Не знам каква е идеята на IDS (lapsus calami;)), само знам,
 че се грижи за разпознаването на опити за пробиви и
 съответно прилага някакви методи на защита. Например,
 блокира достъпа на съответното IP за известен период от
 време. Това може да стане както чрез iptables, така и по
друг начин (например с route).

 Какво прави специално Portsentry. Отваря огромно количество
 сокети, като по този начин заблуждава атакуващия, че на
 машината работят десетки услуги. При сканиране се виждат
 множество отворени портове. С една дума, Portsentry симулира
 уязвимост на системата, за да предизвика евентуалния
 злосторник. Интересното е, че при сканиране може да връща
 интересни отговори на врага: "Внимавай! Наблюдават те" или
 "Марш оттук!" и разни такива. Представяте ли си колко
обезкуражаващо е това:)

 Както и да е, много се разприказвах. Струва си да се опита и
Prelude IDS, разбира се.

 Такива системи (Portsentry) не са сериозен метод за защита и
не са толерирани от много специалисти. Защо?

 Цялата работа с върщане на странни (хм..) съобщения на
 атакуващия (предизвикване евентуалния злосторник) е меко
казано несериозна. 

 Всеки един опит за пробив може да се симулира от spoof-нат
 източник (например DNS или още по зле - ROUTER). Какво може
да се направи по натам е ясно.

 Съвсем не отричам такива системи, но обикновено начина по
 който се имплементират е тотално неправилен, а както и като
идея.

 Когато става дума за голяма мрежа е нормално да се разчита
 на IDS подобен софтуер, който алармира при успешни и
 неуспешни опити за пробив, но не предприема друго критично
 действие. Правило #1 на такива места е трафикът от
 'непознати места' да се реже още преди да е стигнал до
POSTROUTING и INPUT (примерно, за Linux).

 Напълно съм съгласен. Всичко това са трикове, които малко
 илио много са от полза, но ползата им не бива да се
 абсолютизира. Разбира се, като казвам, че работата на IDS е
 да реагира, това не означава непременно да блокира или да
 прави каквото и да било спрямо атакуващия. Може просто да
 алармира администратора, чието задължение и без това си е да
 следи системата. В това отношонеие, в комбинация на пример с
logcheck наблодението се улеснява неимоверно.

защо не пробваш с portknocking ?

 Относно опитите за SSH logins, напоследък имаше много
 mallware, който правеше опити за login с прости
 потребителски имена като "guest", "test". Mожеш да прочетеш
този постинг, за да добиеш представа:
http://www.ssc.com/pipermail/linux-list/2004-July/021305.html

 Относно превенцията на горните опити за неоторизиран достъп
 до SSH сървъра ти посредством netfilter, можеш да направиш
следното:
 1. Да сложиш default policy DROP на INPUT chain-a, и да
 разрешиш само тези услуги които трябва да са публично
достъпни.
 2. За порта, на който слуша ssh демона ти, можеш да разрешиш

 само определен брой IP адреси, които да имат достъп. За
 съжаление това не винаги е възможно (за мен това е
неприложимо).
Какво съм направил аз по този повод? Използвам public key
 authentication, и съм забранил password authentication.
Това
мисля решава проблема.
 Така, че гледай да имаш нова версия на SSH, сложи
 PermitRootLogin no в sshd_config, приложи някаква политика
 за сложността и трудността на паролите си и не се страхувай,
от тези автоматизирани опити за достъп.

Колкото до:
 "Iskam naprimer pri 2 ili 3 neuspesni opita da blokira
IP-to
 koeto se opitva da vleze prez SSH .... ", можеш да
използваш
swatch или tensi, за да мониторваш log файла си за такива
 опити и да извършваш определено действие при неуспешен
login.

 Мисля, че това е по чист вариант от всякакви IDS или HIDS
системи (на които аз лично съм почитател).

 До Никола: Понякога имам чувството, че живееш в 98 или 99
 година. С какво PortSentry, ще му помогне при този проблем,
 след като то деиства някъде около OSI layer 4, a неговия
проблем е някъде около OSI layer 7?
 Да не говорим, че PortSentry отдавна изживя времето си,
 Abacus бяха изкупени от Cisco. A дебиан версията с нищо
изключително не блести. Виж Snort, може и да му помогне.

 До незнаен: Говорейки за mangle таблицата, се сещам какво
 правиш гледайки от глупави примери из интернет. Никога, ама
 никога не ползвай mangle таблицата за филтриране на пакети.
 Защо? защото тя НЕ е предназначена за това. За справка
 постинги в netfilter-list на Harald Welte (знаеш кой е
 нали?) и Antony Stone. Просто забрави за глупостта "stop the
 badness before it hits our routing table", няма да стане
 нищо ако я хитне и тогава я спреш. А това да дропиш места
 дето не си познавал, и че било правило номер 1, IMHO е пълна
простотия.

 Съжалявам ако съм бил директен, такъв съм си. Ама човека ви
 зададе прост въпрос, а вие взехте да му разказвате за атомни
бомби. Добре че не го накарахте и honeypot да си инсталира.

 Katerinski, такива troll-ове като теб с лопата да ги ринеш.
 Има няколко ВУЗА в БГ дето ги произвеждат даже. Нямам
 представа кой си, но с доста неща не си наясно, че имаш и
наглостта да ми говориш общи приказки, без аргументи. 

 Нямам намрение да оборвам незнанието ти, но ще вмъкна -
 винаги има начин да даваш достъп на изрично зададени адреси
 достъп до услуга, пък били те и динамични. Един вече го
споменаха, има и още.

 Малко за mangle да си поговорим. Няма как да се сещаш какви
 глупави или сложни примери съм гледал, защото просто не си
 наясно. Като си се разчел из mail листите на netfilter.org
 да беше научил нещо? Поразпитай там откъде започва пътя на
 пакетите. Само не споменавай че си от БГ. Можеш и да им
 предложиш мнение (особено на Harald Welte или на Edmund
 Burke примерно хах) да махнат DROP target-а от mangle, тъй
 като той е само за маркиране на пакети. Само между другото
 mangle не е извън routing таблицата ти. Веднага след като
 пакетите ти минат по lan или каквото имаш там device се
 обработват от mangle/PREROUTING преди да продължат. Начинът
 да филтрираш мрежа с реални адреси е като спираш нежеланият
 трафик или в mangle или в nat. Можеш и във filter, с
по-голяма вероятност да сбъркаш.


За IMHO-то ти се сетих за една вечна мисъл на Чърчил. 
 А това което имаш за 'пълна простотия' е всъщност основна
 концепция за сигурност. Иначе беше и добър завършек на
заядлив коментар от дървен (bofh) философ. 

 ;-) "Трол" е лаф на Жоро Чорбаджийски, нали не си той?
Защото няма да правя усилия да пиша.
 Понеже ми говориш наизуст, а аз много мразя, ще извадя някои
твои реплики и ще ги обсъдим, става?

 "Нямам представа кой си, но с доста неща не си наясно, че
 имаш и наглостта да ми говориш общи приказки, без аргументи.
"
 Хех, с кое не съм наясно (туй ще ми го обясниш след малко),
 мисля че доста ясно обясних на човека как да се защити. Или
 пък се засегна за mangle-a :) ? Къде видя това "без
 аргументи"? за всяка една моя дума, приложих примери и
аргументи.

 За "динамичните" достъпи до услуги, ами щом ти харесва port
 knocking-а, ползвай си го, за мен това не е good security
practise. А ако искаш изброй ми и другите.

 А за mangle-a, какво да си говорим :) Виждам си се
 попритеснил, щом и за Edmund Burke взе да говориш, а негова
 мисъл ми е в сигнатурата. Знаеш за какво говоря. Няма какво
 да питам откъде започвал пътя на пакетите, а къде ли
 свършва? Аха! Да не би да говориш за "kernel packet
 travelling/traversal" ? Ама какви са тия ланове, device-и
 ;-) объркваш ме. Абе ти да не си от ония пишман лан
 администратори? Дано не си :). Виж сега, PREROUTING chain-a
 на mangle таблицата е преди routing таблицата ти, обратно на
 твоето твърдение че е, инак няма смисъл да дропиш там както
 ти правиш (за справка
 http://open-source.arkoon.net/kernel/kernel_net.png ,
 ftp://ftp.gnumonks.org/pub/doc/packet-journey-2.4.html
 ,http://iptables-tutorial.frozentux.net/chunkyhtml/traversingoftables.html
 ), вярно има DROP target, но простo mangle не е
 предназначена за филтриране, нито пък само да си маркираш
 трафика, както си мислиш ти. Има си място за филтриране, и
 то е filter таблицата, сам го знаеш, и няма защо да се
правиш на дебил. 
 Виж и това:
http://iptables-tutorial.frozentux.net/chunkyhtml/mangletable.html)

 "Начинът да филтрираш мрежа с реални адреси е като спираш
 нежеланият трафик или в mangle или в nat. Можеш и във
filter, с по-голяма вероятност да сбъркаш."

 Първо не мисля, че на netfilter му пука какво ти смяташ за
 реален или виртуален адрес. Второ, повярвай ми не може ей
 туи netfilter, да се обърка ако вземеш че филтрираш във
 FORWARD на filter, защото моето момче, да ти издам една
 тайна, тя затова е направена. Що ти не идеш да питаш в
 netfilter листа, правилно ли е да дропя в mangle, а и за
 разнообразие в nat, и няма проблеми, спомени че си
българин.
 Виж, наистина мисля че си малко заслепен, и че говориш
 глупости. Аз нямам претенцията да знам кои са основните
 концепции за сигурност, или пък "правило номер едно" :), да
 си призная не ги знам. Само че се старая да си карам по
правилата и manual-ите, а там пише друго.
 Между другото, Google показва изобилие от експерти като
теб,
започвам да си мисля, че в мен е проблема :)
http://www.google.com/linux?num=30&hl=en&lr=&ie=UTF-8&q=%22prerouting+drop%22&btnG=Google+Search

 Хайде, и не с лошо, дано забележиш, че пак не говоря
 "наизуст" и "без аргументи". И вземи се консултирай с Никола
 или Кольо, или просто някои твой приятел на който имаш
доверие.

 P.S. Не казвам, че не е възможно да дропиш в mangle или nat,
 а че не правилно и не се прави така, и че не е правилна
"концепция за сигурност" както се изразяваш ти.

 Не съм Жоро Чорбаджийски, ама дай да не се обиждаме :] А
 същият е много далеч от измислянето на собствени фрази и
лафове. 'Трол' е известно като /. определение (не noun). 

 Според доста хора не съм пишман администратор, а още
 по-малко bofh. Напълно наясно съм със садържанието линковете
 които си се престарал да търсиш. Факт е че нито един
 аргумент не даде за mangle, а се опита да обясняваш какво си
 мислили други хора. Ако имаш какво да кажеш - давай, иначе
 stay silent. Виждам харесваш да ползваш английски думички,
така че ще ме разбереш. 

 За динамичните адреси - port knocking е превъзходен security
 practice, още повече като се прави кодирано. Друг вариант от
 края на 90-те (които май с носталгия припомни на Никола
 Антонов) са безплатните DYNDNS услуги. Дотатъчно е във
 firewall скрипта си да сложиш не IP, а име на хост. След
 това остава да презареждаш правилата през адекватен интервал
 от време. Има и други възможности, направи си труда да
прочетеш.

 Частта за 'моето момче' направо уби рибата и я оставям без
 коментар. Сериозно си мисля че проблемът е в теб. И както
чувам не съм само аз.

 Не знам дали ще е полезно това, което съм направил, но при
мен е така:
 Инсталирал съм snort, който следи целия трафик към мрежов
интерфейс, който му е посочен напр. eth0.
От тук можеш да го изтеглиш.
http://www.snort.org
Снорт-а пише в един лог-файл, който е доста подробен. 
 Има т.нар. рулери, които са критерии за намеренията на
опитващите да достъпят машината ти по определен начин.
 Само снорт-а не е достатъчен. Добавил съм към него и
guardian.
В момента актуалната версия е Guardian 1.7.
 Това е един скрипт, който чете лог-а на снорт-а и реагира
както му кажеш.
 По-точно има наколко готови скрипта, iptables_block.sh и
 iptables_unblock.sh, които са елементарни, но се стартират
когато е необходимо.
Този съвет ми го даде KUZA и съм благодарен за идеята. 
Ще се радвам ако и друг сподели мнение за тази комбинация.
При ядра 2.4 ползва iptables и то доста успешно.
 До сега съм много доволен от тази комбинация и ми върши
добра работа.
 Можеш и да си направиш собствен рулер в зависимост от
 изискванията ти, но има доста готови и мисля че няма да ти
се наложи.