Всё обсуждаемое будет касаться классического варианта — Apache2+PHP5+MySQL5.
Вебинар пройдёт 25 ноября, в 19-00 по московскому времени. Запланированное время проведения — 2 часа. Каждый может поучаствовать в нём абсолютно бесплатно. Для этого нужно в назначенное время зайти на http://www.gvolive.com/conference,web-hosting-security и указать своё имя.
Для всех кому данная тема интересна, но нет возможности присутствовать на вебинаре, я выложу его запись в своём блоге и данной теме в течение двух дней после проведения.
Если у вас есть какие-то вопросы, рад буду на них ответить.
Спустя 6 минут, 18 секунд (21.11.2011 - 11:11) Игорь_Vasinsky написал(а):
так нужно перейти по ссылке или дождаться когда выложешь? сдесь ссыль на видео продублируешь?
Спустя 11 минут, 38 секунд (21.11.2011 - 11:23) Семён написал(а):
Обязательно буду.
Спустя 3 минуты, 46 секунд (21.11.2011 - 11:26) Белый Тигр написал(а):
Видео не будет, только звук + текстовый чат. По ссылке нужно пройти для участия в вебинаре 25 числа в 19-00. Можете пройти сейчас, там будет пустая комната для вебинара 
Спустя 3 минуты, 31 секунда (21.11.2011 - 11:30) Игорь_Vasinsky написал(а):
понял. спасиб. постараюсь принять участие (хотябы молча)))
Спустя 2 минуты, 9 секунд (21.11.2011 - 11:32) m4a1fox написал(а):
Так-с, ставлю себе напоминание. Буду 100%. Если в 19:00 то на Украине будет только 17:00. Так же? Просто уточняю что бы время начала не прогавить?!
Спустя 2 часа, 36 минут, 7 секунд (21.11.2011 - 14:08) Белый Тигр написал(а):
| Цитата |
| Так-с, ставлю себе напоминание. Буду 100%. Если в 19:00 то на Украине будет только 17:00. Так же? Просто уточняю что бы время начала не прогавить?! |
Да, после перевода часов разница с Москвой, по крайней мере у Киева, стала в 2 часа. В Киеве в это время будет 17:00.
Спустя 20 минут, 32 секунды (21.11.2011 - 14:29) m4a1fox написал(а):
Белый Тигр
Вообще здорово. Будет наверно интересно!
Вообще здорово. Будет наверно интересно!
Спустя 19 минут, 24 секунды (21.11.2011 - 14:48) TranceIT написал(а):
Обалденно! Буду обязательно!
Спустя 4 дня, 8 минут, 15 секунд (25.11.2011 - 14:56) Белый Тигр написал(а):
Напоминаю что до начала вебинара осталось 3 часа
Спустя 2 часа, 6 минут, 52 секунды (25.11.2011 - 17:03) vital написал(а):
Собственно вот
Как починить то?
Как починить то?
Спустя 4 минуты, 59 секунд (25.11.2011 - 17:08) Michael написал(а):
тоже жду вебинара. У меня кириллица нормально отображается.
Спустя 32 секунды (25.11.2011 - 17:09) Winston написал(а):
И у меня нормально.
Спустя 31 секунда (25.11.2011 - 17:09) zeromind написал(а):
+1 всё нормально,
говорят вебинар будет без видео потока ?
говорят вебинар будет без видео потока ?
Спустя 11 секунд (25.11.2011 - 17:09) vital написал(а):
то не кириллица. ТО вообще любые символы. Во блин, я избранный. Ча ребут вроде.
Спустя 50 секунд (25.11.2011 - 17:10) Белый Тигр написал(а):
| Цитата |
| говорят вебинар будет без видео потока ? |
Да. Аудио+текст.
Спустя 3 минуты, 35 секунд (25.11.2011 - 17:14) Invis1ble написал(а):
А у меня раскладка на кириллицу переключаться не хочет в чате 
Спустя 8 минут, 23 секунды (25.11.2011 - 17:22) zeromind написал(а):
| Цитата (Белый Тигр @ 25.11.2011 - 17:10) | ||
Да. Аудио+текст. |
радует что аудио поток будет
можно было бы и скайп конфу организвать)
Спустя 4 минуты, 50 секунд (25.11.2011 - 17:27) vital написал(а):
Кстати да. Го скайп. Там хоть все без проблем работае.
Спустя 2 часа, 35 минут, 20 секунд (25.11.2011 - 20:02) redreem написал(а):
вебинар закончился. вот мой коспект - кому нужно:
Ошибочные мнения:
1. бесплатный хостинг хуже защищен
2. не стоит брать хостинг у компаний у которых это не профильная деятельность.
3. ошибочное мнение - что у новых контор не стоить хоститься
при выборе хостинга:
1. поиск случаев о взломе хостера (в яше, гугле)
2. зайти на форум поддержки - поискать темы о взломе.
3. если есть случаи, когда хостер открещивается от взлома и грешит на скрипт - нахх его.
4. если взлом массовый - то 100% виноват хостер.
Наличие системы обнаружения вторжений (IDS, snort, waf).
делятся на виды:
1. просто отражают отаку и ничего не делают. со стороны взломщика - сервер просто не отвечает (чаще всего такое встречается).
2. реже: оповещает клиента
3. бывает что атакующему блокируется доступ на 10 минут.
Штука нужная.
Уязвимости нулевого дня - уязвимость найдена, а заплатки еще нет.
Средства борьбы с подбором пароля.
Раньше были у всех хостеров.
Сейчас из 12-ти опрошеных только у 2-х.
Логи по IDS дают не все.
Часто антивирусом проверятеся только почта.
Бывает антивирус не упоминается в тарифах, надо спрашивать хостера о наличии.
Услуга проверки сайтов клиентов на уязвимости (xSpider) - может быть автоматом, может быть по требованию.
Человека не заменит, но самое банальное - найдет.
Все фишки надо переспрашивать у хостера, порой они сами не знаю что у них есть.
Ограничение по ip - очень эффективная вещь!!!
Доступ к mySql - в основном доступ только с самого сервака, но встречаются хостеры, у которых доступ открыт извне.
Некоторые включают по просьбе.
SSH-туннель для MySQL - это хорошо.
Панели управления хостингов - по идее серъезеые продукты за большие бабки.
Если дают единый логин/пароль на все виды доступа - то хостер лажает. Если нельзя сделать разные пароли - то лучше не брать такой хостинг.
Проблема прав доступа:
1. Стоит узнать - запрещено ли обращение к скриптам и папкам из вне у которых права 777. Из 12 всего у одной.
2. Изоляция пользователей. Самый лучший вариант. Если хостер такого не может - то лучше с ними не связываться.
3. Массовые взломы в основном основаны на проблеме разграничения прав.
Если Apache, то скрипт выполняется для всех от владельца.
Если suPHP или FastCGA, то права дифференцируются.
Ограничивать по максимуму выполнение скриптов, там где это не нужно.
Логи.
Важно к каким лога есть доступ и какое время они хранятся.
10 дней - это мало.
месяц - нормально.
Чем больше - тем лучше.
Если нет каких-то логов, то мы не можем до конца выяснить откуда был доступ.
SFTP лучше чем FTP.
http://php.net/manual/ru/ini.list.php - все опции php
http://www.php.net/manual/ru/configuration.changes.modes.php - где и что можно менять
Важные настройки - все меняются через htaccess, кроме disable_functions или в httpd.conf, apache2.conf, php.ini для каждого сайта - лучше, или ini_set()
1. Список отключенных функций: disable_functions (exeс,system...). Нужно запретить в php.ini все функции для работы с операционкой. Запрещаем все, что не нужно движку.
2. Подключать удаленные файлы: allow_url_include.
3. Отображение ошибок: display_errors - на рабочем сервере - обязательно!
4. Вывод ошибок: error_reporting.
5. Логирование ошибок: log_errors - нужно логировать. Лог в отдельную директорию с deny from all
6. magic_quotes_gpc - через ini_set() они не доступны. Все входящие данные (гет, пост, куки) - экранируются все опасные символы. Лучше на нее не надеяться, а самому обрабатывать данные.
7. Указывает директорию, за которую php не выходит: open_basedir.
8. register_globals - опасная вещь.
9. safe_mode - либо в php.ini либо конфигурации веб-сервера. кандидат на удаление. - накладывает кучу ограничений. скрипты могут неработать.
10. session.cookie_httponly флаг для кукиес-сессий - очень желательно включить! куки становятся доступны только по http. такие куки не видны для JS.
11. session.save_path - сохранение сессий - на большинстве хостеров - одна папка (/tmp). Лучше всего указать свой каталог.
DDOS
Хостер не дает нормальной защиты от ddos, только самое простое.
Нужно знать что будет делать хостер:
1. Поднимать ресурс.
2. Блокировать.
Серъезно делать защиту можно только на своем отдельном сервере, а не на виртуальном.
Резервное копирование.
Узнать у хостера:
1. регулярность
2. что архивируется
3. длительность хранения
4. какой к ним доступ
5. как происходит восстановление
По статистике взломщик в панель биллинга не проникает. Чаще - FTP.
Идеальный вариант - резервные копии доступны только в панели и нет возможности скачивания. Только восстановление.
Если копии лежат на FTP, то создать отдельный FTP для них, максимально отделить их от папки сайта.
Модули, встроенные в веб-сервер:
mod_security на хостерах стараются не ставить, потому что он зачастую срабатывает на белых данных. Модуль обнаружает различные атаки (инъекции и т.п.).
Случай взлома.
Что сделает техподдержка?
Смена паролей, логи, восстановление с резерва.
Схема восстановления доступа.
Все хостеры: для физ. нужен скан паспорта, для юр. - оф. письмо.
http://anton-kuzmin.blogspot.com
Ошибочные мнения:
1. бесплатный хостинг хуже защищен
2. не стоит брать хостинг у компаний у которых это не профильная деятельность.
3. ошибочное мнение - что у новых контор не стоить хоститься
при выборе хостинга:
1. поиск случаев о взломе хостера (в яше, гугле)
2. зайти на форум поддержки - поискать темы о взломе.
3. если есть случаи, когда хостер открещивается от взлома и грешит на скрипт - нахх его.
4. если взлом массовый - то 100% виноват хостер.
Наличие системы обнаружения вторжений (IDS, snort, waf).
делятся на виды:
1. просто отражают отаку и ничего не делают. со стороны взломщика - сервер просто не отвечает (чаще всего такое встречается).
2. реже: оповещает клиента
3. бывает что атакующему блокируется доступ на 10 минут.
Штука нужная.
Уязвимости нулевого дня - уязвимость найдена, а заплатки еще нет.
Средства борьбы с подбором пароля.
Раньше были у всех хостеров.
Сейчас из 12-ти опрошеных только у 2-х.
Логи по IDS дают не все.
Часто антивирусом проверятеся только почта.
Бывает антивирус не упоминается в тарифах, надо спрашивать хостера о наличии.
Услуга проверки сайтов клиентов на уязвимости (xSpider) - может быть автоматом, может быть по требованию.
Человека не заменит, но самое банальное - найдет.
Все фишки надо переспрашивать у хостера, порой они сами не знаю что у них есть.
Ограничение по ip - очень эффективная вещь!!!
Доступ к mySql - в основном доступ только с самого сервака, но встречаются хостеры, у которых доступ открыт извне.
Некоторые включают по просьбе.
SSH-туннель для MySQL - это хорошо.
Панели управления хостингов - по идее серъезеые продукты за большие бабки.
Если дают единый логин/пароль на все виды доступа - то хостер лажает. Если нельзя сделать разные пароли - то лучше не брать такой хостинг.
Проблема прав доступа:
1. Стоит узнать - запрещено ли обращение к скриптам и папкам из вне у которых права 777. Из 12 всего у одной.
2. Изоляция пользователей. Самый лучший вариант. Если хостер такого не может - то лучше с ними не связываться.
3. Массовые взломы в основном основаны на проблеме разграничения прав.
Если Apache, то скрипт выполняется для всех от владельца.
Если suPHP или FastCGA, то права дифференцируются.
Ограничивать по максимуму выполнение скриптов, там где это не нужно.
Логи.
Важно к каким лога есть доступ и какое время они хранятся.
10 дней - это мало.
месяц - нормально.
Чем больше - тем лучше.
Если нет каких-то логов, то мы не можем до конца выяснить откуда был доступ.
SFTP лучше чем FTP.
http://php.net/manual/ru/ini.list.php - все опции php
http://www.php.net/manual/ru/configuration.changes.modes.php - где и что можно менять
Важные настройки - все меняются через htaccess, кроме disable_functions или в httpd.conf, apache2.conf, php.ini для каждого сайта - лучше, или ini_set()
1. Список отключенных функций: disable_functions (exeс,system...). Нужно запретить в php.ini все функции для работы с операционкой. Запрещаем все, что не нужно движку.
2. Подключать удаленные файлы: allow_url_include.
3. Отображение ошибок: display_errors - на рабочем сервере - обязательно!
4. Вывод ошибок: error_reporting.
5. Логирование ошибок: log_errors - нужно логировать. Лог в отдельную директорию с deny from all
6. magic_quotes_gpc - через ini_set() они не доступны. Все входящие данные (гет, пост, куки) - экранируются все опасные символы. Лучше на нее не надеяться, а самому обрабатывать данные.
7. Указывает директорию, за которую php не выходит: open_basedir.
8. register_globals - опасная вещь.
9. safe_mode - либо в php.ini либо конфигурации веб-сервера. кандидат на удаление. - накладывает кучу ограничений. скрипты могут неработать.
10. session.cookie_httponly флаг для кукиес-сессий - очень желательно включить! куки становятся доступны только по http. такие куки не видны для JS.
11. session.save_path - сохранение сессий - на большинстве хостеров - одна папка (/tmp). Лучше всего указать свой каталог.
DDOS
Хостер не дает нормальной защиты от ddos, только самое простое.
Нужно знать что будет делать хостер:
1. Поднимать ресурс.
2. Блокировать.
Серъезно делать защиту можно только на своем отдельном сервере, а не на виртуальном.
Резервное копирование.
Узнать у хостера:
1. регулярность
2. что архивируется
3. длительность хранения
4. какой к ним доступ
5. как происходит восстановление
По статистике взломщик в панель биллинга не проникает. Чаще - FTP.
Идеальный вариант - резервные копии доступны только в панели и нет возможности скачивания. Только восстановление.
Если копии лежат на FTP, то создать отдельный FTP для них, максимально отделить их от папки сайта.
Модули, встроенные в веб-сервер:
mod_security на хостерах стараются не ставить, потому что он зачастую срабатывает на белых данных. Модуль обнаружает различные атаки (инъекции и т.п.).
Случай взлома.
Что сделает техподдержка?
Смена паролей, логи, восстановление с резерва.
Схема восстановления доступа.
Все хостеры: для физ. нужен скан паспорта, для юр. - оф. письмо.
http://anton-kuzmin.blogspot.com
Спустя 5 минут, 55 секунд (25.11.2011 - 20:08) TranceIT написал(а):
Отличный вебинар, особенно было интересно про настройку сервера. Автору +
Буду ждать новых докладов!
Буду ждать новых докладов!
Спустя 3 минуты, 20 секунд (25.11.2011 - 20:12) m4a1fox написал(а):
redreem
Спс! А вообще ничего так получилось! Интересней было бы про частности...а не в общем! Но и так здорово было! И интересно. Первый раз все таки!
Спс! А вообще ничего так получилось! Интересней было бы про частности...а не в общем! Но и так здорово было! И интересно. Первый раз все таки!
Спустя 8 минут, 42 секунды (25.11.2011 - 20:20) vital написал(а):
ТОже понравилось. Жду следующий 
Спустя 8 минут, 31 секунда (25.11.2011 - 20:29) fire написал(а):
Было достаточно интересно. Почерпнул кое что интересное для себ
Спустя 1 минута, 3 секунды (25.11.2011 - 20:30) redreem написал(а):
дописок к конспекту:
RemoveHandler - указать все расширения для скриптов RemoveHandler .php - прописать
все расширения, доступные у хостера
AddType application/x-httpd-php-source .php - как сервер обрабатывает файлы.
Если тип серверу неизвестен он будет отдавать файл на закачку.
Тесты на нагрузку.
http://anton-kuzmin.blogspot.com/2011/01/siege-web.html
http://anton-kuzmin.blogspot.com/2011/01/ab-apache.html
+xdebug для профилирования.
Есть еще http://jmeter.apache.org/ - близкая к реальности имитация пользователя.
RemoveHandler - указать все расширения для скриптов RemoveHandler .php - прописать
все расширения, доступные у хостера
AddType application/x-httpd-php-source .php - как сервер обрабатывает файлы.
Если тип серверу неизвестен он будет отдавать файл на закачку.
Тесты на нагрузку.
http://anton-kuzmin.blogspot.com/2011/01/siege-web.html
http://anton-kuzmin.blogspot.com/2011/01/ab-apache.html
+xdebug для профилирования.
Есть еще http://jmeter.apache.org/ - близкая к реальности имитация пользователя.
Спустя 2 минуты, 10 секунд (25.11.2011 - 20:32) Michael написал(а):
Мне тоже очень понравилось. Все нужное.
Спустя 9 минут, 45 секунд (25.11.2011 - 20:42) vital написал(а):
Недостаток - что не было слайдов каких-нить, и приходилось нек-е вещи автору пастить в чат. + в начале надо было дать общий обзор-план, что будет рассмотрено.
+ ЭТА БУБОГАЯ ФЛЕШ АПЛИКУХА В КОТОРОЙ ВЕСЬ ТЕКСТ В КВАДРАТИКАХ.
А автор, молодец в остальном)
+ ЭТА БУБОГАЯ ФЛЕШ АПЛИКУХА В КОТОРОЙ ВЕСЬ ТЕКСТ В КВАДРАТИКАХ.
А автор, молодец в остальном)
Спустя 6 минут, 45 секунд (25.11.2011 - 20:49) Invis1ble написал(а):
Автору респект, ждем еще интересную и полезную инфу.
Спустя 10 минут, 19 секунд (25.11.2011 - 20:59) Семён написал(а):
Ага мне тоже всё понравилось.
Спустя 9 часов, 43 минуты, 28 секунд (26.11.2011 - 06:42) Белый Тигр написал(а):
Всем спасибо за отзывы. Несколько поправок:
| Цитата |
| 4. если взлом массовый - то 100% виноват хостер. |
Тут, если память не изменяет, я не досказал. Бывают случаи когда в популярном движке находят уязвимость (тот же пример с 0day) и идёт массовый взлом пользователей именно этого движка. Если вы видите что такое имеет место быть, и все пострадавшие пользуются одними скриптами, то хостинг тут может быть и не виновен.
| Цитата |
| Серъезно делать защиту можно только на своем отдельном сервере, а не на виртуальном. |
Такого я не помню чтоб говорил, возможно что-то из моих слов было не верно интерпритировано. Про VDS/VPS/Dedicated я говорил лишь то, что о них бытует ошибочное мнение, будто если хочешь хорошую защиту - переходи на них. Это не так т.к. не каждый веб-мастер может самостоятельно администрировать выделенный сервер на должном уровне.
Спустя 44 минуты, 17 секунд (26.11.2011 - 07:27) Rand написал(а):
Надо записать видео для потомков в следующий раз. Кто-то ведь не смог поучаствовать
Спустя 4 часа, 28 минут, 5 секунд (26.11.2011 - 11:55) inpost написал(а):
Вообщем, ты писал про 2-3 дня. Я не смог поприсутствовать, но будет очень интересно послушать.
Спустя 1 день, 5 часов, 12 секунд (27.11.2011 - 16:55) Белый Тигр написал(а):
Запись вебинара можно забрать здесь: Запись
Там же ответ на один из вопросов.
Там же ответ на один из вопросов.
Спустя 21 день, 5 часов, 18 минут, 43 секунды (18.12.2011 - 22:14) Белый Тигр написал(а):
Спустя 2 дня, 7 часов, 24 минуты, 3 секунды (21.12.2011 - 05:38) Белый Тигр написал(а):
В течение последних 12 часов ссылки на материалы вебинара были не рабочие. Сейчас всё налажено. Приношу свои извинения.
Спустя 3 часа, 41 секунда (21.12.2011 - 08:38) redreem написал(а):
ADOBE READER X и Foxit PDF Reader отказались открывать пдфку.
Спустя 17 минут, 9 секунд (21.12.2011 - 08:56) Белый Тигр написал(а):
Очень странно, никогда ранее такого не встречалось. А какая ошибка?
Спустя 2 часа, 41 минута, 14 секунд (21.12.2011 - 11:37) redreem написал(а):
перезакачал файл - открылся.
ошибка была: "Adobe Reader не может открыть 'konspect-web-hosting-webinar.pdf', т.к. формат файла не поддерживается, или файл был поврежден (например, отправлен по e-mail как вложение и не декодирован правильно)."
ошибка была: "Adobe Reader не может открыть 'konspect-web-hosting-webinar.pdf', т.к. формат файла не поддерживается, или файл был поврежден (например, отправлен по e-mail как вложение и не декодирован правильно)."