Какие-то серъёзные уязвимости и информация по их эксплуатации могут продаваться и покупаться в разных тематических сообществах (в том числе - закрытых). Те же, что, скорее всего, необходимы вам - в свободной доступности. Кроме того, есть огромный выбор инструментария для penetration testing'a. Пользователей maultalk'a, в частности, может заинтересовать Nessus (бесплатен для домашнего использования) или его свободный форк - OpenVAS. Справедливости ради замечу, что один лишь этот инструмент - не панацея, хотя и ценная вещь.

Какая-то АТМТА.

Базовый принцип информационной безопасности - CIA (confidentiality, integrity, availability / конфиденциальность, целостность, доступность). D(DOS) - это как раз о доступности.
И атака отказа в обслуживании, кстати, может быть вызвана / существенно облегчена уязвимостями.

Хостер должен предоставить хостинг / VPS / VDS / сервер / whatsoever. На этом его обязанности заканчиваются.

Как же.

Это называется Security through obscurity. Надо заметить, не лучшая практика.

На хостинге стоит nginx в качестве проксирующего сервера. На VDS была такая же конфигурация? Сейчас для размещения ресурса используется хостинг, верно? По прежнему есть, что оптимизировать (данные по домашней странице):
1. Слишком много http запросов: 5 JS файлов, 6 stylesheet файлов и 9 background картинок. Можно, скажем, скомбинировать часть файлов, для картинок использовать CSS спрайты и т.д.
2. 64 статических файла без expires заголовка. А это значит, они будут скачиваться при каждом посещении.
3. Используйте gzip. У вас 8 компонентов, которые могли бы быть сжаты: CSS стили и JS скрипты.
4. По возможности, вынесите скрипты из хедера в нижнюю часть страницы.
5. Минимизировать (uglify / minify) JS и CSS.
6. На главной - 33 картинки, которые масштабируются с помощью html. Если бы это происходило на серверной части / картинки были предварительно отмасштабированы, браузеру не пришлось бы скачивать картинки большие по размеру, чем необходимо.
7. Не использовать стили и JS внутри html в случае, если они общие для всех страниц. Тем самым, браузер сможет их закешировать.

Поддерживаю, true way для качественных проектов. На вскидку список экшенов, которые нужно будет разработать:
Регистрация
Подтверждение по e-mail
Запрос восстановления пароля
Переход по ссылке восстановления / ввод нового пароля
Иерархия пользователей (юзер, админ)
Новый заказ
Список заказов пользователя
Список всех заказов (админ)
Изменить статус заказа (админ)
Изменить статус оплаты заказа (админ)
Уведомление о новом сообщении / заказе
Новое сообщение
Список сообщений
Просмотр сообщения
Просмотр профиля пользователя
Изменить данные в профиле
...
ЛС должен быть привязан к заказам каким-либо образом (подобно кнопке "пожаловаться" на форуме, что при отправке жалобы фиксирует тему и сообщение, на которое пожаловались), я полагаю.
Нехилый портальчик в итоге должен получиться. Времени займёт не пол часа. Вы готовы помочь ТС'у в реализации? Пусть и имея мотивирующий фактор - возможность продавать потом получившееся решение.

Appfog без всякого бартера. Бесплатный тарифный план для нетребовательных по ресурсам сайтов. Java, Node, Ruby, Python, PHP. 2GB RAM, 100MB storage per MySQL or PostgreSQL instance, 5GB data transfer per month, 100 requests per second. Бессрочно.

webpavilion, тут, пожалуй, речь не про "осиляторство". Насколько я понял, г-н zek24 хочет поднять ресурс своими силами. Я не берусь судить об уровне квалификации ТС, но судя по тому, что мне удалось нагуглить, разработкой вплотную автор топика не занимается. А без опыта разработки, да сразу в продакшн писать, вы понимаете какой будет результат с точки зрения безопасности. Поэтому в данном случае предпочтительно обойтись полностью готовыми плагинами.
Судя по требуемому функционалу, задачу можно решить используя любую CMS + тикет систему (для большинства CMS уже есть такой плагин). Возможно, потребуется переименовать название каких-то полей (зависит от того, что конкретно нужно). Либо обратиться к исполнителю. Например, к webpavilion.

Перечитал все посты. Обнаружил, что имеет место мнение: "Популярные коробочные решения подвержены взломам в силу наличия готовых эксплоитов. Самописные же безопасны, ибо никто не знает об их структуре". Итак, несколько слов из своего опыта...
Что делает black hat "аудитор безопасности"? Во первых, отмечу тот факт, что подходы могут быть разные. Пересекался с одним господином - основателем и CEO своей infosec компании в Канаде. Так вот он в этих ваших языках программирования - ни в зуб ногой. Компания с явным уклоном на безопасность сетей и инфраструктуры. Поставь они перед собой задачу сломать сайт, стали бы смотреть в сторону проблем с конфигурацией вашего сервера, наличия открытых портов и эксплоитов на ОС / php / mysql / etc. При отсутствии всего перечисленного, как сей господин неоднократно шутил, нужно было бы "переспать с системным администратором компании с целью заполучить пароли".

Однако, я в этих ваших сетях и инфраструктурах не преуспел. Поэтому использую несколько иной подход, основанный на поиске самого слабого звена цепи (то бишь, в высокоуровневой прослойке):

1. Прежде всего, делается предположение относительно системы, на которой функционирует ресурс;
2. Если это "самопис" и совершенно очевидно, что фреймворк не использовался, в ~90% случаев это означает наличие sql инъекций и кучу других уязвимостей. Хотя необходимость искать другие вектора атаки, как правило, отсутствует ибо sql инъекция - достаточна для заливки шелла и последующих манипуляций с информацией на сервере;
3. Если это ресурс на базе CMS... На самом деле, вероятность найти в популярном контент менеджере что-то настолько эпичное, как sql injection - стремится к нулю. А вот в основе плагинов может быть "самопис" с большой буквы "С". Поэтому внимание уделяется таким вот плагинам. Если они написаны на заказ (с закрытым исходным кодом), вероятность эпических уязвимостей опять очень и очень велика. Ещё очень часто "разработчики" не осиливают освоение архитектуры CMS и пишут рядом с CMS свой велосипед. А это опять "самопис".
И лишь не обнаружив "самописа", глядим на версию системы и доступные в паблике эксплоиты. Расшибать головой стену и искать что-то хитрое, как правило, не требуется. Поэтому, если эксплоитов не найдено, лучше продолжить поиски других векторов.
4. Если это фреймворк, возможность эпических уязвимостей с большой долей вероятности отсутствует. Тут нужно искать ошибки в логике, пробовать ввод непредусмотренных данных. Вот такой пример подслушанный мной у Самуэля Тыну, специалиста по безопасности, была такая дырка у одного банка... Форма отправки денег. Вводим сумму, адресат. Нажимаем отправить, адресат получает средства. Ввести сумму больше 8 символов нельзя, она обрезалась на серверной стороне, а затем приводилась к int. Тогда тестировщик ввёл сумму в научной нотации. Коротко и много. По длине строка на серверной части прошла, а затем переполнила интовую переменную и получилась отрицательная величина вроде -1000000$. Система проверила, больше ли у пользователя на балансе, чем минус миллион. Да. Далее, провела такую операцию Баланс_тестировщика = Баланс_тестировщика - (-1000000$). Т.е. тот пополнил свой баланс на один миллион. При этом с баланса получателя списался этот миллион. Эпично.

Мораль сей басни. "Ресурс с нуля" (без фреймворка) в абсолютном большинстве случаев говорит о низкой квалификации разработчиков. Security by obscurity, на который разработчики самописных решений так расчитывают - не тот путь, что ведёт к безопасности. Админка, которую все наровят спрятать, легко находится даже если она находится по адресу http://site.ru/has62t23gdgsiADMIN. Кроме того, в арсенале взломщика есть куча полезных инструментов, которые и просканируют и найдут и сделают это с наименьшим шумом в логах.

И таки да. При желании, и на фреймворке можно "самопис" сделать. Но только зачем тогда фреймворк? Там ведь код какой-то лишний. А у нас синдром NIH (Not invented here). Лучше уж тогда с нуля.

P.S.: В общем, я за использование CMS, если функционал и организация системы вас устраивает (кому Джумлу ставить "не солидно", как здесь тоже прозвучало, ставьте "Zotonic CMS" на Erlang; говорите, что у вас самая отказоустойчивая система из всех существующих на рынке / ещё что-нибудь, что "солидно"). Проект - не типичный ресурс вида новости-статьи-фото-smth? Тогда пилим своё на фреймворке. Кстати, рекомендую книгу Getting Real тем, кто соберется работать над своим продуктом. Оченнама интересная и полезная книга.

Фрагмент кода системы, на разработку которой выделено $0.5 ляма:
Сей "самопис" как-бы намекает нам на следующие вещи:
1. Хоть автор и не школьник по возрасту (в футере странички - шильдик со ссылкой на сайт разработчика), но как работает "return" ещё не разобрался;
2. Кто-то нехило "попилил" на этом проекте.
Из этого же проекта:

Это просто WIN!!! Кстати, этот фрагмент и сделал возможным для нас с вами просмотр исходного кода.

Не буду вдаваться в дальнейшие подробности относительно кода сего "самописа", приведу список "лучших" практик от его разработчиков:
1. Создайте пользователя "webuser" для доступа к БД и дайте ему все те же привилегии, что имеет root. Особенно не забудьте "FILE" и "DROP"! Используйте этого юзера для всех БД.
2. Создавайте побольше каталогов и файлов с доступом на запись.
3. Не солите хэши. Храните их в обычном md5 (в идеале - в виде plain text).
4. При разработке админки, не забудьте написать файловый менеджер, позволяющий загружать любые типы файлов.
5. Входящие данные не проверяйте. Если проверяете, не используйте подход с белым списком. Это ведь неудобно!
6. Установите на сервер, где запускаете проект, python, gcc, perl, golang, etc. Чтобы из PHP шелла можно было заливать любой другой.
7. Не забудьте написать "систему безопасности", фиксирующую IP адреса / хосты всех посетителей и сохраняющую эту информацию в общую БД.
8. Настройте sudo, чтобы работал со всеми пользователями и без запроса пароля.
9. Не обновляйте ОС и сторонние скрипты хотя бы по году. Патчи к критическим уязвимостям уверенно игнорируйте.
10. Выставляйте chmod 777 на все логи в системе.
11. В конфиг файле храните побольше паролей и ключей: LDAP, RADIUS, WSDL...
12. Используйте один и тот же пароль для разных серверов / аккаунтов / интернет-банкингов.
13. Если вам сообщают об уязвимостях, катите бочку на такого "информатора", угрожайте ему.
14. Если вы попильщик и получаете сообщение с обеспокоенностью по поводу качества работы, игнорируйте послание.


Другой пример. Учебное заведение, Нью Йорк, стоимость обучения $200k / 4 года с рыла. Весь софт - готовый: WP, интернет-магазин контента (лицензия - много бачей зелени в месяц), куча других CMS'ок. И лишь несколько страничек "самописа" дают возможность злоумышлиннику получить доступ к УУУУЙМЕ конфиденциальной информации по студентам и сотрудникам. Что называется, почуствуй себя сотрудником ЦРУ. Кроме того, возможность менять размер "поддержки" aka "скидки на обучение" студентам.
[attachment=18730:phishing.png]
SQLMap в действии.
Самое забавное - уведомление на сайте, типа "Уважаемый пользователь! Если считаешь, что твой аккаунт скомпрометирован, тысамдурак. Больше не заходи на фишинговые сайты и не суй свой пароль во все дыры. С уважением".


Информационное агенство. "Самопис". 3 разработчика на постоянке. Фрагмент:
А пацаны то и не в курсе, что юзер агент - тоже пользовательская информация и требует предварительной обработки. Как и не в курсе о том, что файлы прямо на сервере редактировать плохо. Ещё хуже, если после этого остаются бэкапы.


Все три проекта размещены в своих "типа ДЦ". Представляют собой связку большого или оочень большоооооооого количества серверов. Могут стать частью БОТнета. Или уже стали?


Собственно, к чему я всё это.
1. Худший вариант - "самопис". При любом раскладе.
2. Если готовая CMS обладает необходимым вам функционалом и отвечает всем необходимым требованиям / вы стеснены в средствах, CMS - это ваш выбор.
3. В остальных случаях - писать на базе фреймворка. На нём даже эпичный мудак столь критических уязвимостей не сделает.

MyBB - Message Board. Пруф: http://notebookclub.org/forum/admin/index.php.