К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

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

Гость
0 - 16.02.2014 - 19:14
В продолжение темы Арендовал клауд-сервер с системой ubuntu 10. Что с ним делать дальше?

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



Гость
1 - 16.02.2014 - 22:05
"в безопасности кода"
исходного кода ядра системы?
исходного кода веб-сервера? sql-сервера? php-модулей?
текстовой составляющей конфиг-файлов этого всего?
php/perl кода сайтов?
чего изволите то?
Гость
2 - 16.02.2014 - 22:08
спереть можно, подключившись по каким-либо технологиям, позволяющим передачу файлов (ftpd/sshd к примеру).
HTML-составляющую сайтов можно "спереть" через "сохранить страницу как".
SQL-данные можно спереть, если к субд разрешен коннект извне, кроме localhost. Либо если есть установленная утилита администрирования и в нее можно попасть, например, phpmyadmin для mysql.
Гость
3 - 16.02.2014 - 22:08
Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
"в безопасности кода" исходного кода ядра системы?
любого. В т.ч. и тех, что вы перечислили.

И заодно иимеются в виду и несанкцилонированные установки софта, вирусов и прочего неполезного.
Гость
4 - 16.02.2014 - 22:10
Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
Либо если есть установленная утилита администрирования и в нее можно попасть, например, phpmyadmin для mysql.
есть такая.
только вопрос, можно ли через нее влезть, кроме брутфорса.
Гость
5 - 16.02.2014 - 23:17
Автор, в вашем конкретном случае - да. возможно спереть все.
как защититься от этого? - ну можно заплатить специальным людям.

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

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

аффтар жирный троль
Гость
6 - 16.02.2014 - 23:44
Цитата:
Сообщение от wladuha Посмотреть сообщение
Под каждый продукт рано или поздно находят эксплоит. Защита от этого - целая наука
это понятно.

Цитата:
Сообщение от wladuha Посмотреть сообщение
В реальной же жизни - ваша площадка никому на не нужна
ну допустим там лежит база кадастра всей страны со всеми фио.

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

PS
я не тролль. Обижаете.
Гость
7 - 17.02.2014 - 08:31
Цитата:
Сообщение от Протезофф Посмотреть сообщение
ну допустим там лежит база кадастра всей страны со всеми фио.
Ну тогда еще и рекомендую почитать УК, фз 152.
ps троль
Гость
8 - 17.02.2014 - 08:56
Цитата:
Сообщение от petrovichr Посмотреть сообщение
ну допустим там лежит база кадастра всей страны со всеми фио.
В таком случае вам к наркологу
Гость
9 - 17.02.2014 - 09:47
Цитата:
Сообщение от Протезофф Посмотреть сообщение
любого. В т.ч. и тех, что вы перечислили. И заодно иимеются в виду и несанкцилонированные установки софта, вирусов и прочего неполезного.
1) не лезть туда, куда не стоит
2) сложные пароли на сервисы, которые должны быть доступны снаружи. Возможно, список разрешенных ip
3) сервисы, доступные только "изнутри", ограничить локалхостом
4) Чужие CMS изучать по отзывам
5) Свои авторизационные блоки писать профессионально
Гость
10 - 17.02.2014 - 09:50
О, кадастр. VPN с шифрованием и доступ только "оттуда".
Никаких ftpd. Лучше ssh.
Гость
11 - 17.02.2014 - 17:35
4-Протезофф >не заметил вопроса сразу. Если это phpmyadmin, нужно смотреть настройки. Ну и свеженьким держать. Следить за багтреккером.
Гость
12 - 17.02.2014 - 19:26
9-Фанат NASCAR >10-Фанат NASCAR >11-Фанат NASCAR >
понял, спс.

Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
Если это phpmyadmin, нужно смотреть настройки
если вы про пароли в конфиге, то пароли там не пишу.
Только при входе.
(там если не прописать паролей, то есть авторизация)
Конечно же, через https

Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
VPN с шифрованием и доступ только "оттуда".
Это, я так понял, открытые/закрытые ключи и т.п.
Наверное, придется озаботится.
Только вот будет весело, если что-то не то сделаю и не смогу зайти на сервер. )))

Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
Чужие CMS изучать по отзывам
вообще не пользуюсь.
Только свой код.

Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
Свои авторизационные блоки писать профессионально
ну тут хз. Я, конечно же, любитель, но например, пароли храню не под md5(), а под for(1000 раз)md5()
)))
Не знаю, достаточно ли, но имхо это надежней, чем просто md5

PS
и это, пароли (при логине) шифруются еще на стороне клиента. ))
Гость
13 - 20.02.2014 - 11:46
Цитата:
Сообщение от Протезофф Посмотреть сообщение
ну тут хз. Я, конечно же, любитель, но например, пароли храню не под md5(), а под for(1000 раз)md5()
не столько это важно, сколько важно закрыть доступ к БД.
По хешам пары подбираются, кому надо. Сам в юности написал на PHP скрипт, который за час нагенерил базу на 40 гиг с паролями и их хешами различными)

Цитата:
Сообщение от Протезофф Посмотреть сообщение
Только свой код.
Ваш код никто не может проверить на соответствие требованиям безопасности. OpenSource продукты проверяют все, кому не лень)

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

Цитата:
Сообщение от Протезофф Посмотреть сообщение
Только вот будет весело, если что-то не то сделаю и не смогу зайти на сервер. )))
бекап на облако. Сброс сервера в дефолт и восстановление.

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

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

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

Второе - заказная на тебя. Тут все понятно, думаю)
Гость
14 - 20.02.2014 - 11:48
Цитата:
Сообщение от Протезофф Посмотреть сообщение
и это, пароли (при логине) шифруются еще на стороне клиента. ))
жаваскриптом так то? )))
как бы узнать алгоритм шифрования то.. посмотреть исходный код и скачать js что ли?)
Гость
15 - 20.02.2014 - 11:49
Если "клиенты свои десяток", то поднимай OpenVPN с сертификатами и паролями, и все будет хорошо.
Гость
16 - 21.02.2014 - 19:05
Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
жаваскриптом так то? ))) как бы узнать алгоритм шифрования то.. посмотреть исходный код и скачать js что ли?)
так ведь выше уже писал как: for(1000 раз)md5()
Соотв, база хешей не поможет.

Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
бекап на облако. Сброс сервера в дефолт и восстановление.
придется курить еще и бекап.
За наводку спасибо.

Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
случайный обход адресов цодов
без понятия, что это, но наверное что-то типа сканирования портов на наличие ответа с них.
Ну, тут хз конечно, пока что все что заметил, это что пытались один раз законнектиться на ssh порт, который я выбрал сам (не 110-й по умолчанию).
Гость
17 - 21.02.2014 - 23:57
16-Протезофф >ssh 22-й)
Да, я про сканирование портов.
Про хеши - знаете ли вы, что они могут совпадать у р8азных исходных вводных?
Гость
18 - 22.02.2014 - 02:02
Цитата:
Сообщение от Фанат NASCAR Посмотреть сообщение
Про хеши - знаете ли вы, что они могут совпадать у р8азных исходных вводных?
конечно могут.
Но речь идет о 1000 лупов.

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

PS
Да, наверное он был 22-й.
Забыл уже.
Это смтп кажется 110-й
Гость
19 - 22.02.2014 - 02:48
коллизии MD5 пофиг сколько loop'ов - хватит и первого совпадения, остальное будет автоматом таким же =)
Гость
20 - 22.02.2014 - 08:04
19-droidman >в точку
Гость
21 - 24.02.2014 - 19:41
19-droidman >20-Фанат NASCAR >
прикол в том, что в базе хранится не последний из тысячи, а несколько, выбранные в процессе регистрации ))

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

Подделать уже авторизованный запрос, конечно можно, особенно, если нету привязки к айпишнику, но узнать пароль - нереально.
Гость
22 - 24.02.2014 - 19:44
+ к 21

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

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

Насколько это безопасно, не знаю, но думаю, что достаточно безопасно.
Гость
23 - 25.02.2014 - 17:24
22-Протезофф >вы не туда смотрите. Закрывать iptables все и открывать только нужное для удаленки. А с хешами.. Если будет доступ к СУБД - будет все)
Гость
24 - 25.02.2014 - 18:23
Цитата:
The 1st Law of Cryptography: Don’t design your own crypto.
The 2nd Law of Cryptography: Don’t implement your own crypto.
– Rennie deGraaf
как-то так
Гость
25 - 25.02.2014 - 19:43
24-droidman >бгг)))) надо запомнить
Гость
26 - 22.03.2014 - 18:18
Хотел автору объяснить, в чём он не прав, но при формулировании понял, что неправ я. Рандомноую цикличность хеширования атакой на хэш имхо поломать будет трудно. Для этого надо каким-то образом вынуть из БД логин+пароль+число_итераций, после чего набивать словарь с таким-же числом итераций до совпадения хэша. Без этого, если в лоб только подобрать хэш, получаемый однократным хэшированием некой строки, атака не удастся, т. к. сервер будет хешировать присланную ему строку не один раз, а столько, сколько напротив этого логина указано в БД.


К списку вопросов






Copyright ©, Все права защищены