Стены конечно же были в ужастном состоянии...

Но, все всегда можно исправить...

Привезли фальшпол... Хороший и качественный немецкий... Фальшпол обошелся в много тысяч евро...

А Вы знали, что каждая плита может выдержать до 1000 килограм нагрузки?

Первый коридор собрали...

Второй коридор собирают...

Привезли лотки для кабеля (питание отдельно, сеть отдельно по схеме креста)...

И начали их мерять...

И ставить...

Тут приехали мастера по установке контроля доступа, и системе входа по отпечатку пальца...

Тем временем кондиционерщики били огромные дырки под воздуховоды...

Забор теплого воздуха...

Мощность системы свыше 160кВт...

По моей идее мы начали делать воздуховоды под фальшполом (чтобы охлаждение было точечным)...

И красиво ведь выходит...

Включили щит учета...

Счетчика нет, потому что питаемся от основной гермозоны (мощность ввода 160кВт на каждый ввод)... Данный ввод рассчитан на 120кВт мощности...

Вся электроника компании MHost IDC построена на АВВ...

Приехали пожарники...

Поставили мифические штуки...

Контроль доступа собрали...

Включили...

Вы знаете, я лично ругался что бы прекратили испытывать другие пальцы...

Электрики собрали щиток учета и даже помыли его...

Начали ставить клиентов...

Разных и красивых...

Читать продолжение на официальном блоге Mhost

Запретный плод сладок

Хороший бот никогда не полезет туда, где ему запрещено через robots.txt. Этим можно воспользоваться.
Создаем директорию, которую закрываем через robots.txt и делаем невидимую ссылку или ссылку через прозрачную картинку 1×1 пиксель на какую-то страницу в эту директорию.
Человек туда не попадет, а хорошие роботы запрет не нарушат,а плохие — пополнят наш список.

Заполните эту форму

Хороший бот никогда не станет заполнят форму и нажимать кнопку. А вот плохим ботам, типа XRumer, только дай поспамить. А ведь это отличная идея!
Давайте возьмем и поместим на сайт форму-обманку для регистрации или отправки комментария? А выше нее поставим картинку в которой напишем — это ловушка для ботов, если вы отправите эту форму — мы вас забаним.
Таким образом можно отсечь спамботов. И неграмотных, невнимательных посетителей.

Может печеньку?

Хороший бот игнорирует кукисы. Неплохим вариантом будет предложить кукис в запрещенной для ботов директории. Если он ее примет, то на основе этой куки можно попробовать ему подсунуть сайт-ловушку, в которой структура бесконечно вложена и посмотреть — он поймет это или нет.
Если поймет — то осторожно, это умный и хитрый бот. А если не понимает — его можно смело банить на 100-й попытке зайти вглубь сайта.

Хорошие боты javascript не трогают!

Вот черт, получается что Гуглбот — плохой, злой? Ведь он умеет ходить по таким ссылкам и его можно случайно забанить. Нет, это недопустимо! Лучше сделать так — в директорию, запрещенную для роботов, добавим ссылку или даже редирект на javascript. Если бот выполнит и совершит переход/редирект — то это точно очень плохой и злой бот.

Дополнительные меры защиты

Прозрачная картинка на весь экран? Белые буквы на белом фоне? Скрытые поля формы?
Все это поможет определить кто же у нас на сайте — человек или бот. Возможно капча на флеше? Буду рад если предложите свои варианты.

Заключение

Создаем директорию, которая будет закрыта для ботов через robots.txt.
Сделаем две скрытые ссылки на две страницы внутри этой директории, одну обычную и вторую через javascript. Подсовываем кукис.
На страницах мы предложим заполнить форму для регистрации. С сообщением о том, что это приведет к бану. И скрытым полем, лучше всего если это поле для ввода URL сайта.
Если не смотря на все эти меры, форма отправлена и кука присутствует — поздравляю, вы нашли злого, умного и плохого бота!

А еще я советую сразу блокировать все диапазоны разных ЦОД от посещений вашего сайта. Все равно через их IP, выделяемые под арендованные сервера, нормальный посетитель ходить не будет, и эта мера срезает сразу 80% спама через формы.

На самой странице-заглушке можно написать нечто вроде «Извините, сайт под DDOS, включите кукисы в браузере и нажмите на ссылку для перехода».
Когда посетитель откроет такую страницу, то при следующем запросе он передаст эту «печеньку», на основе которой можно направить трафик к спрятанному веб-серверу:
<b>iptables -t nat -A PREROUTING -p tcp --dport 80 -m string --string "this-is-not-bot" --algo kmp -j REDIRECT --to-ports 8080</b>

Разумеется, что для нормальной работы сайта не следует забывать передавать в кукисах эту заветную строчку.

Ожидали чего-то более сложного? Извините...

P.S. Поисковые боты не принимают кукисы, так что будет вполне разумно сделать для них заблаговременное исключение.

Корень проблемы: UDP

Прежде чем описать очередную возможную интернет атаку со стороны конкурентов, я бы хотел сначала немного углубится в UDP, а точнее в его проблемную область: информация об IP адресе отправителя в UDP может быть легко подделана!
Я небуду рассказывать всех нюансов, но это точно такая же проблема, как и заголовок From в email, они существуют и им нельзя доверять.

Проблема была бы легко решена, если бы каждый провайдер перед отправлением UDP «в мир» отсекал все поддельные (спуфленные) UDP на маршрутеризаторе. Причем технически это сделать не сложнее, чем настроить в почтовом сервере запрет отправки email с поддельным адресом отправителя. Увы, ISP в нашем мире далеки от идеала.

Говорят, что в Парижской Палате Мер и Весов где-то есть Идеальный Провайдер. Он дает канал на 1Gbps на 1 год за 1 рубль. Он хранится под стеклом и его нельзя трогать руками.

Так вот, для своей работы DNS использует TCP и UDP. Причем, если размер информации будет меньше 512 байт, то она будет отправлена по UDP. Все бы хорошо, DNS будут работать быстро, для UDP можно выделить отдельную полосу, так как он легче TCP.

Но есть один момент. Если отправить специально сформированный запрос размером в 17 байт к DNS серверу и подставить IP жертвы, то жертва в ответ получит ответ в 500 байт! Причем, что самое печальное, в интернете масса DNS серверов с открытой рекурсией, что позволяет использовать их для атаки!
Я не шучу, таких серверов действительно очень много. Обычно популярные панели для управления хостингом, такие как WHM, Plesk, DirectAdmin и ISPManager устанавливают DNS и оставлют открытым рекурсивные запросы. А таких хостингов в интернете много, очень много!

Атака на DNS: как это бывает

Итак, у Вас есть некий сайт, к нему положен домен, а к доменам — DNS сервера. Обычно хостер дает свои DNS сервера и вы просто прописываете их в домене. Предположим, хостер выдал 2 DNS: dns1.hoster.ru и dns2.hoster.ru.

Злоумышленник смотрит, на каких IP стоят эти DNS серверы и намечает их в качестве жертвы.
После этого он при помощи поисковых систем ищет хостинги с панелями, которые устанавливает DNS с открытой рекурсией и собирает базу.
Затем покупает самый дешевый хостинг за 1$ с открытыми сокетами и начинает рассылать фальшивые DNS запросы в которых установлен IP адрес жертвы.

К чему это приводит? Подсчитать очень просто. Предположим, скрипт рассылает запросы со скоростью 2Mbps. Так как серверы обычно подключены к 100Mbps порту, то хостеры просто ничего не замечают. Несложно посчитать, что при соотношении 17:500 сила выхлопа информационного мусора составит примерно 58Mbps.

А если злоумышленник накупит таких хостингов в числе 10 штук? Это уже примерно под 500Mbps!
Канал хостера к DNS будет физически забит столь большим трафиком, что DNS сервера перестанут получать запросы от легальных пользователей и отвечать на них. Сайт перестанет работать. И стоимость такой атаки составит всего десять долларов!

Как защитить свой домен от DNS атак

Самый простой совет — используйте DNS сервера своего регистратора домена. И действительно, если на обычном хостинге как правило под DNS используется один или два физических сервера, то у регистраторов для это устанавливается надежная отказоустойчивая система с балансировкой нагрузки, причем вместо обычных серверов отвечают специализированные аппаратно-программные комплексы. И разумеется, у регистраторов есть специальные средства фильтрации подобных атак.

Как правило регистратор, у которого вы приобрели домен предоставляет возможность использовать его DNS сервера бесплатно или за небольшую сумму денег. Но как именно самому настроить свой домен на DNS регистратора?

Нет ничего проще. Сначала вам нужно узнать на каком адресе находится сайт и почта. Для этого используйте команду host:

<strong>$host habrahabr.ru</strong>

habrahabr.ru has address 62.213.122.2
habrahabr.ru mail is handled by 10 aspmx4.googlemail.com.
habrahabr.ru mail is handled by 10 aspmx5.googlemail.com.
habrahabr.ru mail is handled by 1 aspmx.l.google.com.
habrahabr.ru mail is handled by 5 alt1.aspmx.l.google.com.
habrahabr.ru mail is handled by 5 alt2.aspmx.l.google.com.
habrahabr.ru mail is handled by 10 aspmx2.googlemail.com.
habrahabr.ru mail is handled by 10 aspmx3.googlemail.com.

В ответе мы получили адрес сайта и адреса почтовых серверов домена. Теперь укажите в DNS wildcard запись A (она еще может называться @) на адрес сайта (в этом примере — 62.213.122.2), и создайте почтовые записи MX, куда пропишите почтовые сервера (в этом примере — почта на Google).

Теперь ваш сайт станет более надежным к подобного рода атакам. Однако есть еще один совет, который поможет сделать ваш домен практически 100% надежным к подобного рода атакам.

«Одна голова хорошо — а три лучше» © Змей Горыныч

Для этой защиты нам потребуются два дополнительных домена, причем заказанных у разных регистраторов.

Между прочим, правилом хорошего тона является регистрация домена в популярных зонах — RU, COM, NET, ORG. Посмотрите как это делает Google.

Например, основной домен для своего проекта вы выбрали в зоне COM у европейского регистратора. Пусть это будет domain.com.

Теперь зарегистрируйте еще domain.ru например у nic.ru и domain.net у какого-то западного регистратора, например — directi. В доменных записях domain.ru и domain.net создайте набор DNS записей по тому же принципу что и выше, а потом обязательно зарегистрируйте эти домены в качестве DNS серверов. Некоторые регистраторы делают это сами, у других это делается через панель, а третьим надо писать в техподдержку.
А теперь, внимание, никакого мошенничества — только ловкость рук, смените DNS сервера у домена domain.com на domain.ru и domain.net!

Проверьте, что при запросе NS серверов действительно выдаются нужные нам домены:

<strong>$host -t ns domain.com</strong>

domain.com name server domain.ru.
domain.com name server domain.net.

Отлично! Теперь DNS поддерживают сразу два независимых регистратора. С такой защитой вашему домену вряд-ли будет грозить какая-то неприятность. Ну а если вы хотите, то можете продолжить систему — зарегистрировать еще больше доменов в разных зонах и у разных регистраторов. А потом установить их всех в качестве DNS для вашего основного домена.

Надеюсь, что мой совет поможет вам сделать свой домен более защищенным от DNS атак.

Но сначала я хочу немного рассказать про один из способов, которым спаммеры собирают себе базы ящиков для спама.
Спаммеры бывают разные, и базы у них тоже разные. Некоторые собирают их по сайтам с помощью самописных краулеров. Другие — методом перебора вычисляют существующие почтовые ящики. А третьи, назовем их элитными, хотя это слово для спаммеров не примлемо, собирают базу реальных, живых людей, которые получают и читают спам.

Сначала спаммер выбирает несколько доменов-жертв, как правило, сервисов бесплатной почты локальных интернет-провайдеров, многие из которых имеют недостаточные средства для фильтрации спама. Причем выбирают как правило по регионам, чтоб сразу получить региональную базу потенциальных жертв.
Затем, пользуясь особенностью провайдеров, которые так или иначе «засвечивают» логины своих клиентов, генерирует список email-адресов вида логин@почтовый.сервер.isp.

Как именно ISP могут подсказать спаммеру логины своих клиентов?
Например, многие создают бесплатный хостинг для своих клиентов в виде логин.сервер.isp или сервер.isp/~логин. У многих логины на форуме ISP совпадают с их реальными логинами почтовых ящиков. И наконец, если ISP выдает реальный IP, то он очень часто имеет реверсивную запись DNS PTR в виде логин.сервер.isp

Итак, сначала спаммер находит недорогие хостинги, на которых открыты исходящие соединения от скриптов на 25-й порт удаленных серверов и c помощью скрипта dm.cgiначинает рассылку писем, причем каждое письмо снабжается уникальной ссылкой, по которой надо кликнуть, якобы для отписки от рассылки.
Нечего и говорить, что кликая по таким ссылкам, человек подтверждает то, что у него этот ящик рабочий и более того — на нем не фильтруется спам. Следовательно, такой человек будет получать и читать спам-письма, особенно если их содержимое как-то причастно к его региону.

Однако, как обычно, любая элитная технология, попавшая в руки школьников малограмотных спаммеров, спаммеров, становится большой проблемой.

Вместо того, чтоб тратить время и трафик на сбор базы логинов, малограмотный спаммер просто берет домены провайдеров и генерит списоквероятных ящиков по словарю. Один словарь спаммера может содержать в среднем 50 000 часто встречающихся логинов.

Рассылка по подобным базам приводит к тому, что в среднем на каждые 100 писем, только одно доходит до адресата, а остальные будут несуществующими. И это приводит к тому, что все эти письма начинают возвращаться отправителю. И тут происходит самое интересное!

Адрес отправителя можно указать какой угодно, в том числе и адрес и поток оповещений о недоставленных письмах хлынет лавиной в тысячи мусорных писем, забивающих ящик и перегружающий почтовый сервер. Не каждый хостер сможет выдержать подобную атаку и скорее всего заблокирует на время прием почты, а в худшем случае — вообще временно отключит сайт, так как поток Mail Bounce может достигать 100Mbps и полностью забивать канал к серверу.

Самое печальное, что несмотря на кажущуюся сложность, такой вариант будет в результате очень дешев и эффективен для конкурента:

• Скрипт рассылки спама dm.cgi тысячами копий лежит на файлообменниках и скачать его не составит никакого труда
• Множество дешевых хостингов, использующих популярные системы управления хостингом, таких как: cPanel/WHM,Plesk,DirectAdmin,ISPManager — по умолчанию позволяют подобным скриптам расслыку спама напрямую через сокеты, и наспамить по 50 000 адресов c такого хостинга можно меньше чем за 1$
• Многие почтовые сервера ISP игнорируют SPF и DomainKeys

Что же делать, чтоб избежать или хотя-бы смягчить последствия Mail Bounce DDOS?

Ну и наконец я могу предложить абсолютно бесплатно перенести почту кGoogle Mail, хотя это принесет ряд ограничений — например, число ящиков не более 50, есть лимит на отправку сообщений. Зато Google Mail отлично фильтрует подобного рода атаки. А если вдруг ограничения не устроят, то за 50$ в год вы получите надежную почтовую систему.

cd /usr/

wget ftp://mirror.mcs.anl.gov/pub/gentoo/snapshots/portage-latest.tar.bz2

tar xjf portage-latest.tar.bz2

rm portage-latest.tar.bz2

emerge screen

Все дальнейшие команды лучше запускать в screen. Для того чтоб отсоеденить его надо нажать control+a потом d, а чтоб вернуть — выполнить screen -r
Для максимального облегчения я оформил все команды в виде скрипта. Создайте файл, заполните его содержимым а потом запустите: sh файл. И можете пойти выпить чашечку кофе, так как сборка займет время.
Но прежде надо раскрыть возможность поставить необходимый софт, который замаскирован, иначе ничего не выйдет. Выполните:
nano /etc/portage/package.keywords и введите:

www-servers/mongrel_cluster ~amd64

dev-ruby/ruby-debug ~amd64

dev-ruby/ruby-openid ~amd64

dev-ruby/ruby-yadis ~amd64

dev-ruby/ruby-debug-base ~amd64

dev-ruby/columnize ~amd64

dev-ruby/linecache ~amd6

После ввода жмем control+x потом y потом enter. Ну а теперь скрипт:

#!/bin/sh

USE="-ssl -perl" emerge dev-db/mysql

USE="server" emerge dev-ruby/rubygems

emerge dev-lang/ruby dev-ruby/mysql-ruby dev-ruby/rubygems dev-ruby/ruby-termios

echo "dev-ruby/rmagick lcms gif imagemagick jbig jpeg jpeg2k pdf png svg tiff truetype unicode wmf xml xpm pcre" >> /etc/portage/package.use

ehho "media-gfx/imagemagick lcms gif imagemagick jbig jpeg jpeg2k pdf png svg tiff truetype unicode wmf xml xpm pcre" >> /etc/portage/package.use

USE="-perl" emerge media-gfx/imagemagick dev-ruby/rmagick

USE="mysql" emerge dev-ruby/rails

emerge dev-ruby/rake dev-ruby/capistrano dev-ruby/daemons dev-ruby/gem_plugin www-servers/mongrel www-servers/mongrel_cluster dev-ruby/rmagick dev-ruby/bluecloth dev-ruby/redcloth dev-ruby/ruby-debug dev-ruby/ruby-termios dev-ruby/ruby-openid dev-ruby/ruby-yadis

USE="-perl fastcgi" emerge www-servers/nginx

ln -s /usr/lib64/ruby/gems/1.8/gems/mongrel_cluster-1.0.5/resources/mongrel_cluster /etc/init.d/mongrel_cluster

chmod +x /etc/init.d/mongrel_cluster

mkdir /etc/mongrel_cluster

После окончания установки задаем пароль MySQL и запускаем:

emerge --config =dev-db/mysql-5.0.84-r1

/etc/init.d/mysql start

Пусть у нас все проекты создаются в /var/www. Создадим тестовый проект /var/www/test, и добавим его в Mongrel с правами nginx (вообще-то рекомендуется делать отдельного пользователя под каждый проект, это просто для упрощения):

mongrel_rails cluster::configure -e production -p 3000 -N 3 -c /var/www/test -a 127.0.0.1 --user nginx --group nginx

Мы поместили проект на 3000 порт. Для каждого проекта надо будет указывать новый порт.
Добавим сгенеренный конфиг в автозапуск:

ln -s /var/www/test/config/mongrel_cluster.yml /etc/mongrel_cluster/test.yml

И стартанем Mongrel:

 /etc/init.d/mongrel_cluster start

Теперь Nginx. Настроем его проксировать все запросы к Mongrel, а статику отдавать напрямую. Конфиг сервера будет таким:

server {

listen 80;

server_name test;

access_log /var/log/nginx/test.access_log main;

error_log /var/log/nginx/test.error_log info;

location / {

proxy_pass <a href="http://localhost/">localhost</a>:3000/;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $remote_addr;

}

location ~* ^.+\.(css|htm|html|js|txt|pdf|jpg|jpeg|gif|png|ico|zip|rar|bz2|gz|tar)$ {

root /var/www/test/public;

}

}

Разумеется, что для каждого проекта надо будет прописывать каждый раз свою секцию server. Теперь запустим nginx.

/etc/init.d/nginx start

Осталось добавить все службы в автозагрузку, чтоб после перезапуска VDS все поднялось само:

rc-update add mysql default

rc-update add nginx default

rc-update add mongrel_cluster default
Источник:http://habrahabr.ru/blogs/linux/76621/

Приступаем:

wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
rpm -ivh rpmforge-release-0.3.6-1.el5.rf.i386.rpm
yum install ffmpeg ffmpeg-devel flvtool2 mplayer mencoder lame libogg libvorbis libtheora swftools amrnb amrwb transcode x264
wget http://downloads.sourceforge.net/sourceforge/ffmpeg-php/ffmpeg-php-0.6.0.tbz2
tar xjf ffmpeg-php-0.6.0.tbz2
cd ffmpeg-php-0.6.0
phpize
./configure && make
make install

Осталось добавить в php.ini

extension=”ffmpeg.so”

Как же быть? Как сохранить свои данные в целости и сохранности? И тут на помощь приходит шифрование файловых систем. Я расскажу только про две из них — LUKS и CryptoFS.

Следует отметить, что LUKS отлично работает на Linux, а CrytopFS — на FreeBSD.

LUKS

dd if=/dev/urandom of=luks.img bs=1M count=100
losetup /dev/loop0 luks.img
cryptsetup luksFormat /dev/loop0
cryptsetup luksOpen /dev/loop0 luks
mkfs.ext3 /dev/mapper/luks
mkdir /luks
mount /dev/mapper/luks /luks

Для последующего включения:

losetup /dev/loop0 luks.img

cryptsetup luksOpen /dev/loop0 luks

mount /dev/mapper/luks /luks

CryptoFS

mkdir /usr/local/cfs /cfs
cp /usr/local/share/doc/cryptofs/cryptofs.conf /usr/local/cfs/.cryptofs
cryptofs -r /usr/local/cfs /cfs

Подключать потом:

cryptofs -r /usr/local/cfs /cfs

Вывод:

LUKS позволяет выбрать тип файловой системы, но использует блочное устройство, а CryptoFS использует текущую файловую систему для шифрования. CryptoFS ощутимо быстрее, а LUKS гибче.

Что именно использовать — решать вам.

И да, самая надежная защита — это репутация вашего системного администратора.

luks.img

—
/boot/loader.conf
net.inet.tcp.tcbhashsize=(значение подставляется опытным путем)
vm.kmem_size=1536m