Re: lug-bg: Питане отностно message log

[Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>]

Danail Petrow wrote:

> spasenieto za towa e mnogo lesno , /etc/hosts.deny
Обаче човек да падне да се смее като чете такива забавни отговори:). 
Очевидно есенното време не води до тъга и депресии:))
Имал си голям късмет, че сканиранията, които може би си видял са малко. 
Иначе ползвайки /etc/host.deny рискуваш този файл така да набъбне, че 
или за запълни / файловата система или прочита му да стане лимитиращ 
фактор в скоростта на обработка на заявки от твоята система.
А какво ще стане ако някой те сканира скрит зад машини, които са важни 
за теб (пощенски сървъри, web сървъри и прочие)? Интересно е какво ще 
стане ако ти си доставчик и твои клиенти сканират скрити за твои NAT 
машини:)
Когато се прави анализ на защита от нещо е добре да се следва принципа 
"да внимаваме вместо да изпишем вежди да не извадим очи". Идеята с 
филтрите не е никак добра. Най-добрата защита може да е следната:
1) Дефинират се адресни пространства, които могат да използват услугата 
SSH и всички други се отрязват (но не чрез любимите на цял народ 
политики DROP, които просто водят до timeout и така цял свят да разбере, 
че има филтър дето пази порта, а чрез връщане на съобщение тип ICMP 
"port unreachable" за да може атакуващия да изпадне в заблуда, че на 
хоста, който сканира няма такава услуга - това е трън в очите на 
мразещите ICMP, за които е характерно, че и те не знаят защо го мразят, 
но обичат да го филтрират).
2) Използват се по-дълги публични ключове. Дължина от порядъка на 4096 
бита е една добра дължина. Може да има известно забавяне при логин 
процеса (докато се извърши "ръкостискане"), но понякога сигурност и 
скорост не са много свързани понятия. Един ключ да не се използва за 
срок по-голям от 1 година. Добре е да се използва пача на Румен Петров 
от Скаласофт и да се подчини OpenSSH на X.509 сертификатния модел, 
където вече има сертификати и те имат срок на валидност, CRL листи за 
отмяна на OCSP базирана услуга за моментална проверка на статуса на 
валидност.
3) SSH се обвива в SSL. Ако няма по SSH да пренасяте файлове, това 
решение напълно ви устройва (при преноса на файлове по този начин бихте 
наотварили страшно много процесора). Така избягвате и фингърпринт 
детекцията на SSH порта (все едно е, че сте пуснали SSH на висок порт - 
при сканиране може да се определи, че на порт NNNN слуша SSH и да се 
провери версията му) и пробивите в самия SSH. Иска се малко по-сложен 
сетъп. Ако някой прояви интерес, ще му кажа как да го направи.
4) Правят се chroot виртуални среди за влизане през SSH. Това обаче 
осакатява администрирането отвън или изисква да има специална "вратичка" 
за излизане от chroot средата, а това е доста опасно.
5) Не се задават тривиални имена на потребител. Например потребителско 
име "test" е направо анти. Добре е в имената да има букви и цифри.
6) Не давайте на всеки SSH достъп до машината. Ако иска просто да 
използва sftp, го заключете в собствената му директория чрез scponly 
шел. Работи много добре. Обяснете му, че трансфера на големи порци 
информация без rekey процес може да доведе до разкриване на сесийния 
ключ - затова услуги за трансфер на големи файлове базирани на SSH са 
неиздържани от гледна точка на сигурността (вярно, не е много лесно да 
се взломи така сесийния ключ, но е вероятно и то не с малка вероятност - 
всичко зависи от факторите на преносната среда и системата).
7) Ако можете използвайте IPsec и тунелиране за вход към DMZ във вашите 
системи и там работете в зашитена среда. Това е най-доброто решение.
 Поздрави
   Весо


============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================