Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #68, ИЮЛЬ 2006 г.

железобетонный сервер

_MIF_ (ROOT@SECURITYLAB.CO.IL)

Спецвыпуск: Хакер, номер #068, стр. 068-052-2


В данном случае машины A, B, и C являются веб-серверами. На них бегают только веб и фтп-демоны. D - почтовый сервер, обслуживающий наших клиентов. Сервер E представляет из себя кластер БД, а F - бэкапный сервер. Как видно на схеме, все сервера хостинга соединены между собой в локалку, причем таким образом, что сервер E и F не имеют доступа в Инет. Эта схема имеет довольно серьезные преимущества в плане безопасности – все запросы внутри локальной сети происходят в одностороннем порядке, а значит ситуацию уже намного легче контролировать. Разумеется, и у такой схемы есть недостатки – например, время запроса к MySQL возрастает, так как запрос выполняется через TCP, а не через (локальный) unix socket.

Таких вариантов построения хостинга - сотни, и каждый из них имеет свои преимущества и недостатки. Систему, описанную выше, использует, например, весьма солидный хостинг ipowerweb.com, о взломе которого я уже рассказывал полтора года назад. Тогда мне помогла лишь полная беспечность админа, оставившего суидный скрипт после инсталляции какого-то софта. Скажу честно: если бы не эта неосторожность с его стороны – я врядли бы достиг цели. Поэтому помни: на систему надейся, а сам не плошай!

[System.]

Теперь попробуем реализовать на практике вышеописанные теоретические доводы. Первым делом мы займемся системой. Рассмотрим простой пример – пользователь купил у нас хостинг и запустил мега-движок на PHP, который написал ему приятель-школьник за 100 рублей. Кроме основного действия скрипта функция N зацикливается, попутно вычисляя некое сложное действие. Как результат – высокая загрузка процессора. Это очень типичная ситуация для хостинга. Чтобы предотвратить подобные ненамеренные (и намеренные) атаки, необходимо ограничивать юзера в плане ресурсов. У *BSD для таких целей существует система профилей пользователей. Это значит, что мы можем легко ограничить ресурсы каждого пользователя в отдельности. Открываем /etc/login.conf:

Листинг файла /etc/login.conf

# Имя профиля

hosting:\

:copyright=/etc/COPYRIGHT:\

:welcome=/etc/motd:\

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\

:path=~/bin /bin /usr/bin /usr/local/bin:\

:manpath=/usr/share/man /usr/local/man:\

:nologin=/var/run/nologin:\

# Максимальное время использования процессора

:cputime=1h30m:\

# Максимальное кол-во памяти, выделяемой программе под данные

# Сам код программы и стэк не учитываются

:datasize=10M:\

# Сколько выделяем для стека программы

:stacksize=3M:\

# Максимальный размер физической памяти, выделяемой процессу

:memoryuse=16M:\

# Максимальный размер файла

:filesize=50M:\

# Максимальный размер core файлов

:coredumpsize=1M:\

# Сколько файлов может открывать каждый процесс

:openfiles=128:\

Назад на стр. 068-052-1  Содержание  Вперед на стр. 068-052-3