Защита выделенного сервера (в частности защита данных и кода сайтов)
 

В продолжение темы [url]http://forums.kuban.ru/f1029/arendoval_klaud-server_s_sistemoj_ubuntu_10_chto_s_nim_delat-_dal-she-5367149.html[/url]

После запуска возникли опасения в безопасности кода.
Подскажите, насколько реально, что могут ломануть сервер и спереть код сайтов?
И, если это реально, то подскажите, как обезопаситься от этого.

"в безопасности кода"
исходного кода ядра системы?
исходного кода веб-сервера? sql-сервера? php-модулей?
текстовой составляющей конфиг-файлов этого всего?
php/perl кода сайтов?
чего изволите то?

спереть можно, подключившись по каким-либо технологиям, позволяющим передачу файлов (ftpd/sshd к примеру).
HTML-составляющую сайтов можно "спереть" через "сохранить страницу как".
SQL-данные можно спереть, если к субд разрешен коннект извне, кроме localhost. Либо если есть установленная утилита администрирования и в нее можно попасть, например, phpmyadmin для mysql.

[quote=Фанат NASCAR;34174513]"в безопасности кода" исходного кода ядра системы?[/quote]
любого. В т.ч. и тех, что вы перечислили.

И заодно иимеются в виду и несанкцилонированные установки софта, вирусов и прочего неполезного.

[quote=Фанат NASCAR;34174550]Либо если есть установленная утилита администрирования и в нее можно попасть, например, phpmyadmin для mysql.[/quote]
есть такая.
только вопрос, можно ли через нее влезть, кроме брутфорса.

Автор, в вашем конкретном случае - да. возможно спереть все.
как защититься от этого? - ну можно заплатить специальным людям.

Под каждый продукт рано или поздно находят эксплоит. Защита от этого - целая наука, Этому обучают в институтах.

В реальной же жизни - ваша площадка никому на не нужна. Ну если вы конечно нигде не оставили соблазнительные дыры, типа
root\my_passw0rd

аффтар жирный троль

[quote=wladuha;34175210]Под каждый продукт рано или поздно находят эксплоит. Защита от этого - целая наука[/quote]
это понятно.

[quote=wladuha;34175210]В реальной же жизни - ваша площадка никому на не нужна[/quote]
ну допустим там лежит база кадастра всей страны со всеми фио.

Можно ли быть уверенным, что ее не сопрут?
PS
пароль сложный и >15 знаков + нигде не хранится (используется только в шеллах).

PS
я не тролль. Обижаете.

[quote=Протезофф;34175405]ну допустим там лежит база кадастра всей страны со всеми фио.[/quote]
Ну тогда еще и рекомендую почитать УК, фз 152.
ps троль

[quote=petrovichr;34176686]ну допустим там лежит база кадастра всей страны со всеми фио.[/quote]

В таком случае вам к наркологу

[quote=Протезофф;34174564]любого. В т.ч. и тех, что вы перечислили. И заодно иимеются в виду и несанкцилонированные установки софта, вирусов и прочего неполезного.[/quote]
1) не лезть туда, куда не стоит
2) сложные пароли на сервисы, которые должны быть доступны снаружи. Возможно, список разрешенных ip
3) сервисы, доступные только "изнутри", ограничить локалхостом
4) Чужие CMS изучать по отзывам
5) Свои авторизационные блоки писать профессионально

О, кадастр. VPN с шифрованием и доступ только "оттуда".
Никаких ftpd. Лучше ssh.

4-Протезофф >не заметил вопроса сразу. Если это phpmyadmin, нужно смотреть настройки. Ну и свеженьким держать. Следить за багтреккером.

9-Фанат NASCAR >10-Фанат NASCAR >11-Фанат NASCAR >
понял, спс.

[quote=Фанат NASCAR;34185142]Если это phpmyadmin, нужно смотреть настройки[/quote]
если вы про пароли в конфиге, то пароли там не пишу.
Только при входе.
(там если не прописать паролей, то есть авторизация)
Конечно же, через https

[quote=Фанат NASCAR;34177738]VPN с шифрованием и доступ только "оттуда".[/quote]
Это, я так понял, открытые/закрытые ключи и т.п.
Наверное, придется озаботится.
Только вот будет весело, если что-то не то сделаю и не смогу зайти на сервер. )))

[quote=Фанат NASCAR;34177704]Чужие CMS изучать по отзывам[/quote]
вообще не пользуюсь.
Только свой код.

[quote=Фанат NASCAR;34177704]Свои авторизационные блоки писать профессионально[/quote]
ну тут хз. Я, конечно же, любитель, но например, пароли храню не под md5(), а под for(1000 раз)md5()
)))
Не знаю, достаточно ли, но имхо это надежней, чем просто md5

PS
и это, пароли (при логине) шифруются еще на стороне клиента. ))

[quote=Протезофф;34186423]ну тут хз. Я, конечно же, любитель, но например, пароли храню не под md5(), а под for(1000 раз)md5()[/quote]
не столько это важно, сколько важно закрыть доступ к БД.
По хешам пары подбираются, кому надо. Сам в юности написал на PHP скрипт, который за час нагенерил базу на 40 гиг с паролями и их хешами различными)

[quote=Протезофф;34186423]Только свой код.[/quote]

Ваш код никто не может проверить на соответствие требованиям безопасности. OpenSource продукты проверяют все, кому не лень)

Ну, это с одной стороны. С другой - конечно, трудно искать дырки.

[quote=Протезофф;34186423]Только вот будет весело, если что-то не то сделаю и не смогу зайти на сервер. )))[/quote]
бекап на облако. Сброс сервера в дефолт и восстановление.

Ну, я сам не могу считать себя "спецом". Так, "для сэбэ трохи". Просто мысли и чтиво желтых страничек.

Но как правило, атак бывает двух типов.
первый - случайный обход адресов цодов на поиск конкретных известных уязвимостей или глупостей/ленивостей сисадминства. Например, мне в астериск постоянно долбятся с желанием авторизоваться на 101:101@server

Тут главное аккуратно все закрыть, опираясь на чтение и советы в сети, понимая досконально - что ты делаешь.

Второе - заказная на тебя. Тут все понятно, думаю)

[quote=Протезофф;34186423]и это, пароли (при логине) шифруются еще на стороне клиента. ))[/quote]
жаваскриптом так то? )))
как бы узнать алгоритм шифрования то.. посмотреть исходный код и скачать js что ли?)

Если "клиенты свои десяток", то поднимай OpenVPN с сертификатами и паролями, и все будет хорошо.

[quote=Фанат NASCAR;34228467]жаваскриптом так то? ))) как бы узнать алгоритм шифрования то.. посмотреть исходный код и скачать js что ли?)[/quote]
так ведь выше уже писал как: for(1000 раз)md5()
Соотв, база хешей не поможет.

[quote=Фанат NASCAR;34228437]бекап на облако. Сброс сервера в дефолт и восстановление.[/quote]
придется курить еще и бекап.
За наводку спасибо.

[quote=Фанат NASCAR;34228437]случайный обход адресов цодов[/quote]
без понятия, что это, но наверное что-то типа сканирования портов на наличие ответа с них.
Ну, тут хз конечно, пока что все что заметил, это что пытались один раз законнектиться на ssh порт, который я выбрал сам (не 110-й по умолчанию).

16-Протезофф >ssh 22-й)
Да, я про сканирование портов.
Про хеши - знаете ли вы, что они могут совпадать у р8азных исходных вводных?

[quote=Фанат NASCAR;34255970]Про хеши - знаете ли вы, что они могут совпадать у р8азных исходных вводных?[/quote]
конечно могут.
Но речь идет о 1000 лупов.

Ваша база состоит из словаря, где каждая статья тысячелуповая, тогда снимаю шляпу ))

PS
Да, наверное он был 22-й.
Забыл уже.
Это смтп кажется 110-й

коллизии MD5 пофиг сколько loop'ов - хватит и первого совпадения, остальное будет автоматом таким же =)

19-droidman >в точку

19-droidman >20-Фанат NASCAR >
прикол в том, что в базе хранится не последний из тысячи, а несколько, выбранные в процессе регистрации ))

Не все так просто. ))

Подделать уже авторизованный запрос, конечно можно, особенно, если нету привязки к айпишнику, но узнать пароль - нереально.

+ к 21

Если уж говорить точно, то функция примерно такая
for(1000 раз)**
$hash=md5($pass.$hash);
**

Ну а в базе хранится не последний хеш, а выборки:
$stored_hash=$hash_arr[12].$hash_arr[20].$hash_arr[120].$hash_arr[220].$hash_arr[320]......

Насколько это безопасно, не знаю, но думаю, что достаточно безопасно.

22-Протезофф >вы не туда смотрите. Закрывать iptables все и открывать только нужное для удаленки. А с хешами.. Если будет доступ к СУБД - будет все)

[quote]The 1st Law of Cryptography: Don’t design your own crypto.
The 2nd Law of Cryptography: Don’t implement your own crypto.
– Rennie deGraaf[/quote]

как-то так

24-droidman >бгг)))) надо запомнить

Хотел автору объяснить, в чём он не прав, но при формулировании понял, что неправ я. Рандомноую цикличность хеширования атакой на хэш имхо поломать будет трудно. Для этого надо каким-то образом вынуть из БД логин+пароль+число_итераций, после чего набивать словарь с таким-же числом итераций до совпадения хэша. Без этого, если в лоб только подобрать хэш, получаемый однократным хэшированием некой строки, атака не удастся, т. к. сервер будет хешировать присланную ему строку не один раз, а столько, сколько напротив этого логина указано в БД.