1) Можно строить многослойные системы защиты от злостных `кул хацкеров`. но при всем при этом никогда нельзя надеяться, что система под замком на все сто. и как же понять, взломали меня уже, или нет?
Как вариант идет контроль за целостностью файловой системы и пачка программ (да и просто соображний) на тему. ну а есть ли еще что-нибудь? ведь можно и эту самую программу сразу после взлома (рута) поломать на ответ «все хорошо».
2) Ну а какой-то взлом может и вообще оказаться просто незамеченным. Если кто подберет пассфразу рута к ssh и побалуется с логами, то так и не узнает никто о взломе! Конечно тут все скажут, что не надо давать по ssh рута. но это я написал как неоригинальный пример незметного взлома. а какие есть еще?
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
не включай компьютер. никогда.
Существуют программы, которые в некоторой своей базе хранят «md5-отпечатки» критичных системных файлов (ну, или тех, которые ты задашь в настройках подобной программы). Довольно-таки сложно засунуть свой файл на место системного с одинаковыми md5-хешами <font size=«-2»>(правда, тут пролетало про нахождение коллизий в MD5 за восемь часов… Но MD5 — не панацея, а лишь пример)</font>. В самой базе тоже не легко исправить значения md5-хешей на свои, тем более, если она [база] хранится совсем на другом компьютере.
Пример описываемой программы: tripwire.
А почему бы и не давать рута по ssh? У меня вообще пассфраза по сети не передаётся, я по ключу авторизуюсь (а посему, кстати, пароль рута можно вообще задать хоть 64-х значный, забыть или вообще запретить).
Во всём остальном см. абзац выше.
Ребят, ну скажите что-нибудь дельное!!! Совет не включать комп не помог. Рассказ про хэши порадовал до глубины души. fly4life, читай вниметельнее. я уже писал сам про это все (кстати, кроме md5 есть еще не менее 6 способов подсчета сумм. и ее между прочим мало. точную проверку (с точностью до взлома базы) тут надо еще дополнить хотя бы размерами файлой). Человеку получившему рут исправить базу как два пальца, если она только не, как ты сказал, на другом компе, или на сидюке (на флоппи вряд ли влезет). но как я говорил, чихать можно на эту базу. стоит лишь поправить саму программу, которая ее считывает (кстати, для md5 можно просто брать md5sum).
Что до tripwire, то должен огорчить. она давно стала коммерческой. зато есть масса других: aide, naboum, samhain.
По поводу ssh. Существуют три метода авторизации. по адресу хоста, по паролю локального юзера, по паре ключей. Так вот, эта самая пара состоит из приватного и общедоступного. и должен огорчить, что приватный генерируется после запроса пассфразы. и при таком методе аутентификации у пользователя (после проверки соответствия ключей на сервере и поключающейся мащине) запрашивается пассфраза. Ну, может тебя это не волнует и ты отрубил проверку пассфразы. но это как-то несекьюрно.
А на вопрос-то никто ни разу и не ответил!
Хм. Ну, раз ты всё и сам знаешь…
Простите, после чего генерируется приватный ключ?!
Это называется «каша в голове» и полное не понимание механизма «авторизации по ключу».
Приватный и публичный ключи <font size=«-2»>(та самая пара, с помощью которой происходит авторизация)</font> генерируются одновременно и единожды при создании этой пары <font size=«-2»>(хотя, впринципе, публичный ключ можно восстановить из приватного, но никак не наоборот)</font>. Затем, содержимое публичного ключа копируется в файл ~/.ssh/authorized_keys на удалённом хосте (том, на который в последствии будешь логиниться). Этот ключ можно показать хоть всему интернету — в нём никаких секретов нету (на то он и «публичный»). Приватный же ключ, как раз, показывать никому не стОит.
Аутентфикация при таком методе происходит следующим образом (в двух словах):
- при инициализации соединения клиент посылает на сервер публичный ключ;
- сервер ищет этот ключ у себя в authorized_keys и, если находит, то посылает зашифрованную открытм ключём некоторую последовательность;
- эта последовательность может быть расшифрована лишь приватным ключём, парным данному публичному;
- если расшифровка удалась, значит приватный ключ тот, и сервер пустит клиента. Иначе — облом.
А пассфразой, о которой ты говоришь, рекомендуют (но не обязательно) шифровать сам приватный ключ, чтобы человек, укравший у тебя его, не смог им воспользоваться, не зная пароля. Запрашивается эта фраза, когда попытаешься воспользоваться приватным ключём (т.е. когда потребуется расшифровать присланную сервером последовательность). Таким образом, «пассфраза» никуда дальше твоего локального компьютера не идёт, и вся защита сводится к тому, чтобы спрятать понадёжнее приватый ключ либо его запаролировать.
А в чём вопрос-то? Понять, взломали ли тебя или нет? Ну, если подходить к вопросу так, как подходишь ты, то нет, никак и никогда не ощутишь факта взлома. И совет в этом случае был дельным: никогда не включай компьтер. По крайней мере, в сеть. Тогда можно быть уеренным на все сто, что тебя никто не тронул <font size=«-2»>(опять же, если ты не пользуешься какими-то принесёнными от «друзей» накопителями информации)</font>.
Но я уверен, что сеть тебе нужна, так? Тогда пора перестать бояться теоретических опасностей, когда вокруг так много реальных.
Ну я бы с кашей не спешил… А ты просто говорил про ключ с пустой фразой.
Опять таки, я тут никого не просил рассказать о совершенном методе защиты от взлома (зря ты про теоретически\практические опасности). меня интересует другое — какие еще есть способы проверки, что пока не взломали. «Как подхожу к вопросу я» я что-то еще сам не понял (расскажите!).
В общем, если не ёрничать, знаете что — поведайте. потому aide меня не очень-то устраивает. уж больно просто ее убрать на нет с рутом.
Угу, «каша». Знаешь почему? Потому что для принципа авторизации «по ключу» нет никакой разницы, пустая ли фраза, не пустая… Если тебе всё-таки интересно, то поищи в гугле документацию на эту тему.
Скажу честно, чтоб не ёрничать, другой способ мне в голову не приходит =(.
Но всё-таки очень даже интересно, почему не устраивает способ с хранением хешей неких критических для системы файлов? А что, установил систему, сделал сразу же «слепок», сохранил этот слепок где-нибудь подальше от своей системы (будь то другой хост или же болванка — не суть важно). И, скажем, раз в час/сутки/неделю/месяц, загрузившись с какого-нибудь LiveCD, сверяешь сохранённые «слепки» файлов с текущими «слепками». Просто, дёшево и сердито.
«была б эта каша ещё и перловкой…» :)))
в общем-то, уверенным о «(не) поломали» можно быть только в одном случае — если у тебя нет возможности изменять коды на машине. в принципе нет.
к такому виду можно отнести загрузку с live-cd/dvd.
причём, обязательное условие тут будет запрет на запуск с tmpfs — а этого можно добиться только расположением оной на некотором ином сервере.
(что, однако, в разы усложняет саму систему и негативно сказывается на её стабильной и безотказной работоспособности)
как некоторый компромиссный вариант, для обеспечения «промежуточного» уровня безопасности, можно использовать chattr. на особо критичные системный файлы, каталоги и файлы журналов поставить вполне понятные после прочтения документации аттрибуты.
кроме того, весьма желательно настроить «сервер журналирования», на который посредством syslog-ng будут отправляться некоторые критичные журналы. (это можно заменить и периодической записью на cd/dvd, но несколько неудобно: либо ставить привод на сервер/шлюз, что несколько непрактично, либо, опять же, настравивать на работу с другим, соседним, компом…)
естественно, что доступ удалённый суперпользователю должен быть запрещён.
кроме того, для некоторых систем необходимо явно запрещать suid-биты, а для раздачи прав использовать sudo. при совместном правильном использовании с chattr можно дбиться некоторого довольно большого порога недоступности системы на локальном уровне.
ведь, надо сказать, что уровней защиты — несколько, не один какой-то, определённый.
«удалённые» уязвимости — тоже суть неприятности, которые, при обстоятельствах с некорректной настройкой, могут привести к получению управления системой. поэтому, крайне желательно разнести сервисы по jail-ам, или, как минимум, по chroot-ам. (или, конечно, можно вообще расположить по отедельным vm, по типу того, как в xen)
ps: чувствуется, с прошлого раза поднятия этой темы качество вопроса увеличилось… :)))
Про загрузку с CD я уже не раз думал. но это не про сервер. Сервер должен работать все время. иначе это не дело.
По части журналов, то тут удобнее тогда было бы просто использовать что-то типа logsurfer\swatch. но у меня нет второго компа. а без него это полуэффективно (можно слать почту, но тогда ведь можно и успеть удалить письмо, пока не запустился sendmail с желанием отослать все, что накопилось). А наличие на машине tripwire\aide & logsurfer\swatch уже сразу говорит взломщику, что надо искать базу, или письмо на отправку.
chattr полезен. но не против рута…
Замечания хорошие, но неужто кроме журналов и целостности файлов ничего нет?
Fly, я уже давно разобрал по полкам ssh. я прекрасно знаю, что шлется только ключ. давай по-дружески перестанем меряться членами. извини уж за такую грубость.
Наличие на машине tripwire и иже с ним говорит взломщику не только о том, что надо искать базу хешей, но и о том, что надо удалиться ничего не трогая, в случае необнаружения этой базы. Задумайся над этим и пойми, что этого достаточно.
А этого мало? Или нет, не так. Почему этого тебе мало?
Если ты относишься к моим постам, как к попытке меряться членами, то, пожалуйста, оставайся и дальше со своими заблуждениями… И по поводу своего знания ssh тоже.
да нет, просто чёткого понимания не наблюдается, для чего это вообще нужно. или, наоборот. когда этого всего делать не нужно..
как только понимание оного появляется, то тогда и вопросы как-то сами собой отваливаются….
что вообще случается редко, правда…
не самый лёгкий вопрос в данном случае — это невозможность совместить удобство и защищённость. потому как для собственного удобству лучше же, конечно, вообще ходить без ввода пароля, заходить сразу с привилегиями суперпользователя,… что является прямым нарушением безопасности. а как только усиливается безопасность — так наоборот, становится неудобно пользоваться даже самому, не говоря уже о ком-то другом (впрочем, когда этот самый «кто-то другой» — хакер, то ничего плохого в этом нет…)
ps: а меряться достоинствами — это обычно сопровождается некоторыми выкладками в цифрах. их что-то, циферок, тут не видно :D
Fly, ну тебе не надоело? если сам не понимаешь, скажу еще раз. Даже если ты не найдешь базы, то можно переписать сам tripwire на десятистрочную программу, которая будет говорить, что все просто супер и никакие файлы вообще не сменились. который раз тут это пишу уже не знаю.
Который раз тебе тут пишут про загрузку с LiveCD… Hint: на LiveCD может быть совсем нормальная версия tripwire.
Ответ #8
Это ты намекаешь на то, что «Сервер должен работать все время. иначе это не дело.»? Ну, дык, к серверу и взломщиков подпускать не надо. «иначе это не дело».
В теории, да, идеально, если сервер работает не перегружаясь (ровно, как и идеально, если сервер не доступен взломщику). Однако на практике сервера всё-таки перезагружаются и это вполне даже «дело». Это раз.
Второе, ну попробуй воспользоваться какой-нибудь «виртуальной машиной» (по типу vmware). <font size=«-2»>(если уж, прям, так не хочется перезагружать сервер)</font>, загрузись в VM на твоём сервере с LiveCD, подцепи по сети <font size=«-2»>(сеть можеду гостевой и родительской ОС)</font> ресурс с проверяемыми файлами и, вуаля, — проверяй их целостность инструментами с LiveCD.
«Кто не хочет делать, тот ищет отговорки, кто хочет — ищет способы» (с)
P.S. кстати, если организовывать сервер с использованием виртуальной машины, можно вобще много с чем наиграться. Например, поднять сервер в виртуальной машине на виртуальном диске («гостевая» ОС), и выставить этот сервер в интернет. Взломщику никакой root не поможет подменить системные бинарные файлы, если в «родительской» ОС запретить запись на виртуальный раздел с бинарниками гостевой ОС <font size=«-2»>(путём тривиального выставления необходимых прав на файл)</font>.
Да, вм помогла бы, но вот только у меня мощи маловато. я, если честно, не смотрел сколько хочет, например, xen, но мне кажется, что пень100 на 64Мб ему несильно понравится. Да и ресурса у меня нет, с которого бы можно было ресур этот поставить. вот разве что записать cd-rw со всем этим и воспользоваться тем, что сидюк там стоит только читающий.
З.Ы. только что вернулся из похода. вся (почти) Мста за 15 часов.
знаешь, честно говоря, вызывает несколько смешное настроение — потому как на пне-100 ты почувствуешь, что тебя взломали. и там никаких алертов не надо будет.
понятно, что, к примеру, у меня вот домашний шлюз — стоит и каши неделями не просит, я на него попросту не заглядываю. такой же пень, только 133, но это не помеха ;)
ломать его ну никто не будет. нафиг не сдался. ;)
да, был период «параноидальности», когда я по каждому входящему соединению чесался. потом как-то достало.
что-то не пойму, а какая разница, какой там процессор? Об этом вообще только я знаю…
а потом я учусь. учиться в инкубаторе некашерно.
поясни, будь добр.
в общем, расслабься.
если уже взломали — то это либо видно, либо тестированием с этлонного диска это выявляется.
главное, что требуется от тебя, как от дамина — это снизить вероятность удалённого взлома (локально можно и топориком, ага?)
поэтому думай, как прикрыть/отключит ненужное. регулярно обновляй сервисы, торчащие наружу. следи за критичным ПО — ядро, iptables. можешь ещё настроить генерацью отчёта по разним портам на входе шлюза. как только появляется в ежедневной статистике подозрительное — так и разбираешься дальше.
а большее накручивать — это слишком неоправданно.
пароноеей должен страдать каждый системный администратор или пользователь, который не хочет быть взломанным (только мое мнение(с)).
Genie, может для упрощения мониторинга необходимо анализатором логов воспользоваться?
Конечно, кому нужна машина с таким камнем (100 или 133)!?
С нее ни DOS, ни что-то другое вряд ли получиться организовать…
а как хакер может узнать про мощность твоего камня?? гы! элементарон! если у него будут root-права, то, как два пальца об асфальт. можно посоветовать не ставить компиляторы на сервер, ограничить локальный доступ, и выкинуть все, что тебе не нужно, а остальное тебе уже порекомендовали более осведомленные советчики.
паранойя — она несколько того, нездоровая характеристика.
быть настороже — это да, это необходимо.
а вот что-то большее, буквально жить этим — в страхе или чего, что сломается или как… не, это как раз не есть хорошо.
делать тогда полезные вещи попросту будет невозможно. а их и без того столько есть на работе.
впрочем, плановые проверки отменять никто не отменял.
хорошо или нет!??? хм… не знаю. но в этом страхе каждый день живу. работа такая..
если бы я только об этом думал, то.. даже моей головы бв не хватило, чтобы думать так обо всех подконтрольных…
поэтому просто смотрю распределение входящего и исходящего трафика по портам.
каждое же соединение просматривать — это ой. даже почтовое. ой. нафиг. на гигабитном-то коннекте… на каждом сервере…
Под инкубатором имел в виду то, что было бы странно строить защиту из рассчета, что объект защиты никому не нужен.
все советы к сведению принял, спасибо.
Так ведь помимо vmware есть более приемлимые варианты в плане оверхеда, а именно vserver, freevps а сейас еще virtuoozzo открылся. Правда не помнб его требований к железу, но вариантов тем не меннее действительно много.
Привет, вопрос конечно может и не в тему но всеравно…
фишка такая уже пошла вторая неделя как мне снифят ssh, видеть эти
75.64.195.215
216.55.133.53
207.104.44.20
218.104.244.186
213.19.163.35
59.124.47.229
210.87.136.171
219.94.132.52
193.231.226.55
66.34.136.28 этот особенно отлечился)) подбирал по имени Света минут 5
64.213.162.116
ломящиеся адреса по 2 раза в день просто напригает.
есть ли способ бана по IP после 2-3 неудачных авторизаций?
скажи, пожалуйста, зачем ты открыл 22 порт наружу, в интерент?
кто так делает? о какой безопасности может идти речь, когда ты так настроил firewall?
закрыть снаружи 22 порт! пропиши на firewall только доступ для нужных хостов.
потому что надо)) поэтому и открыл. просто на комп захожу с разных точек.
а слушать определенные IP я чет не нашел где это прописывается, хотя искал плохо)))
и еще.. какой посоветуете фаервол чтоб не особо с ним замарачиваться?
мало исходной информации, чтобы давать хоть какие-то ответы.
назови операционню систему, которую будем настраивать.
debian 4.0, из фаервола был криво настроенный iptables которому сейчас снес всю конфигу
воообще есть ли какие нибудь прокси фильтры или какой нибудь скрипт против брутфорсов? например скрипт который увеличивает время между логинами с IP??
Это ты говорил, что в iptables «не силён"? ;). Тогда откуда уверенность, что он был настроен «криво»?
Есть такая штука:
http://denyhosts.sourceforge.net/
Думаю, то, что тебе нужно.