Прокачка debian/ubuntu сервера для маленьких

Всем привет. Недавно появилась необходимость поднятие VPS на debian 7 за скромные деньги.
О плясках с бубенчиком я бы хотел описать тут в подробностях.
Всё в этом посте было собрано на просторах интернета, доработано, разжевано и скинуто в одну статью.


Выбор пал на http://hostink.ru/vps/ из-за низких цен и неплохой стабильности за эти деньги(правда 2 дня были серьезные проблемы с сетью). Был взят VPS за 5 рублей в сутки(или за 150р в месяц) с небольшими конфигурациями ОЗУ 128mb и 10Гб на диске.

В автоматическом режиме был установлен Debian 7.0 x86-64 Wheezy и VPS была готова к работе.
64 битная сиcтема была выбрана лишь для моих личных нужд, а вам же советую, на этом VPS, ставить x86.



Начало


После создание сервера вам на e-mail, прописанный при регистрации, должно прийти письмо вида:
Добрый день!

Виртуальный сервер: vps3456
Конфигурация: 1xAMD-Opteron/128Mb/10Gb/1xIPv4@100
Операционная система: Debian 7.0 x86-64 Wheezy

Доступ к серверу по протоколу ssh2:
IP: 93.189.xx.xx
порт: 22
пользователь: root
пароль: xxxxxxxxxxx

Используйте программу putty для подключения к серверу
по протоколу ssh2 http://hostink.ru/wiki/ssh2_putty/

С уважением,
техническая поддержка

Если у вас windows, смиренно слушаемся указаний в письме и переходим по ссылке http://hostink.ru/wiki/ssh2_putty/ за дальнейшими инструкциями, если же у вас Linux(Debian/Ubuntu и др.) подключаемся к серверу так:
$ ssh root@93.189.xx.xx -p 22

на что получаем диалог системы безопасности ключей:
The authenticity of host '[93.189.xx.xx]:22 ([93.189.xx.xx]:22)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?

Соглашаемся и пишем yes.
Поздравляю, вы в системе.
Давайте обновимся:
# apt-get update && apt-get dist-upgrade -y


Не сидим под root-ом!


По умолчанию нам предлагается сидеть под root-ом, что не очень хорошо по соображениям безопасности.

1. создаем пользователя под которым будем работать(самый простой способ):
# adduser user

где user — имя пользователя
Далее мы увидим диалог что-то вроде:
Добавляется пользователь «user» ...
Добавляется новая группа «user» (1001) ...
Добавляется новый пользователь «user» (1001) в группу «user» ...
Создаётся домашний каталог «/home/user» ...
Копирование файлов из «/etc/skel» ...
Введите новый пароль UNIX:
Повторите ввод нового пароля UNIX:
passwd: пароль успешно обновлён
Изменение информации о пользователе user
Введите новое значение или нажмите ENTER для выбора значения по умолчанию
Полное имя []:
Номер комнаты []:
Рабочий телефон []:
Домашний телефон []:
Другое []:
Данная информация корректна? [Y/n] Y

Пишем сложный пароль(который вы не забудете!) и заполняем данные которые считаем нужными, или просто нажимаем enter.

2. Разрешаем user выполнение sudo
Добавляем user в специальную группу sudo:
# usermod -a -G sudo user

где собственно user — имя пользователя.
Всё, можем выходить и логинится под user
$ ssh user@93.189.xx.xx -p 22

и в дальнейшем уже использовать sudo если нужны привилегии root-а

Немного обезопасим SSH


Практически сразу после запуска сервера заметил подозрительную активность в ану.. на порту 22. По всей видимости китайские порно-сканеры разнюхали и начали брутить пароли.
Самый простой выход — сменить порт ssh с 22 на любой другой.
1. Для этого откроем файл конфигурации ssh сервера:
$ sudo nano /etc/ssh/sshd_config

Ищем строку «Port 22» и заменяем её на «Port 354» где 354 любое число в пределах от 1 до 65535
На всякий случай посмотрим открытые порты:
netstat -tupln | grep LISTEN

и выберем любой не из этого списка.
Скажу сразу, порты 80, 443, 3306, 22, 21, 8080 — советую не использовать.
2. Дальше, ограничим тип адресов для подключения(IPv6 либо IPv4). Если у вас на сервере не используется IPv6, то дописываем файл /etc/ssh/sshd_config:
AddressFamily inet

3. Запретим авторизацию под root, ищем в файле PermitRootLogin и выставляем no. Если данного параметра нет, дописываем:
PermitRootLogin no

4. Разрешаем подключение только по определенным логинам, дописываем файл /etc/ssh/sshd_config:
AllowUsers user

где список пользователей пишется через пробел.

5. Запрещаем попытку входа с пустым паролем. Ищем PermitEmptyPasswords и выставляем no
PermitEmptyPasswords no

6. Сохраняем и перезапускаем ssh демон:
$ sudo /etc/init.d/ssh restart

Для начала всё, можем перелогиниваться с новыми параметрами($ ssh user@93.189.xx.xx -p 354), далее в статье мы еще вернемся к вопросу безопасности.

Установка SWAP


Как оказалось в автоматическом режиме не был выставлен swap, а при таком объеме памяти — это критично.
Внимание! Это мой конкретный случай, проверить есть ли swap можно так:
$ sudo swapon -s


Создаем, с помощью dd, файл необходимого размера для swap области, где /swap — это имя и путь файла, а count=1024K его размер, в данном случае — 512 Мб
(обычная формула swap = озу * 1.5, но это не наш случай):
$ sudo dd if=/dev/zero of=/swap bs=1024 count=512K


Далее производим запись в начало файла системную информацию, которая будет использоваться ядром системы для работы с файлом подкачки:
$ sudo mkswap /swap


После окончания операции на экране появится что-то вроде:
Устанавливается пространство для свопинга версии 1, размер = 536868 кБ
без метки, UUID=54c60583-e61a-483a-a15c-2f1be966db85


Следующим шагом активируем только что созданный SWAP файл:
$ sudo swapon /swap


Далее нужно подредактировать файл fstab для подключения swap при следующей загрузке системы:
$ sudo echo "/swap swap swap defaults 0 0" | sudo tee -a /etc/fstab

Вот и всё, своп готов.
Проверяем командой:
$ free

и получить должны:
          total       used       free     shared    buffers     cached
Mem:        510116     502320       7796       4380       1212     452548
-/+ buffers/cache:      48560     461556
Swap:       524284          0     524284


Установка и расширенная настройка NGINX


В качестве frontend-а(Фронтэнд) мы будем использовать всеми известный nginx.
Если вы не будете использовать сервер для web-приложений — эту часть можно пропустить.

В стандартном репозитории конечно есть уже nginx, но хотелось бы версию посвежее и без плясок.
1. Изменяем файл /etc/apt/sources.list:
$ sudo nano /etc/apt/sources.list

и дописываем в самый низ:
deb http://nginx.org/packages/debian/ wheezy nginx
deb-src http://nginx.org/packages/debian/ wheezy nginx

В случае если у вас debian отличный от 7, то вместо wheezy пишем его кодовое имя.

2. Обновляем источники пакетов и устанавливаем nginx:
$ sudo apt-get update && sudo apt-get install nginx

3. Добавляем в начало файла nginx.conf новые параметры
timer_resolution 100ms; #Уменьшает разрешение таймеров времени в рабочих процессах, за счёт чего уменьшается число системных вызовов 
worker_rlimit_nofile 8192; #Изменяет ограничение на максимальное число открытых файлов (RLIMIT_NOFILE) для рабочих процессов
worker_priority -5;# Выставляем более высокий приоритет процессу воркера

4. Ищем worker_processes и выставляем количество по количеству ядер процессора, в нашем случае 1.
worker_processes  1;

5. Ищем директиву events и приводим к виду:
events {
    worker_connections  2048;
    use epoll;
}

6. Редактируем директиву http, модифицируя или дописывая следующие параметры:
sendfile        on; # экономия ресурсов при отдаче файлов
#настройка сжатия контента при отдаче
gzip on;
gzip_min_length 1100;
gzip_buffers 64 8k;
gzip_comp_level 3;
gzip_http_version 1.1;
gzip_proxied any;
gzip_types text/plain application/xml application/x-javascript text/css;
# Таймаут при чтении тела запроса клиента
client_body_timeout 10;
# Таймаут при чтении заголовка запроса клиента
client_header_timeout 10;
# Таймаут, по истечению которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 5 5;
# Таймаут при передаче ответа клиенту
send_timeout 10;

7. Редактируем /etc/nginx/conf.d/sitename.conf или же (ubuntu) /etc/nginx/sites-available/sitename.conf где sitename будет имя вашего сайта:
$ sudo nano /etc/nginx/conf.d/sitename.conf 

Приводим к такому виду:
#выделяем память на адреса клиентов
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;
server {
    listen       80;
    #пишем адреса нашего сайта
    server_name  sitename.net www.sitename.net;
    # Максимальный размер буфера для хранения тела запроса клиента
    client_body_buffer_size 1K;
    # Максимальный размер буфера для хранения заголовков запроса клиента
    client_header_buffer_size 1k;
    # Максимальный размер тела запроса клиента, прописанный в поле Content-Length заголовка. Если сервер должен поддерживать загрузку         файлов, это значение необходимо увеличить
    client_max_body_size 1k;
    # Количество и размер буферов для чтения большого заголовка запроса клиента
    large_client_header_buffers 2 1k;
    #отсеиваем неиспользуемые типы запросов
    if ($request_method !~ ^(GET|HEAD|POST)$ ) {
    return 444;
    }
    #логируем посетителей
    access_log  /var/log/nginx/sitename.access.log  main;
    #и конечно же ошибки
    error_log  /var/log/nginx/sitename.error.log  main;
    #выставляем принудительно кодировку всех документов
    charset utf-8;
    location / {
        # Описываем зону (slimits), в которой будут храниться состояния сессий. Зона размером 1 Мб может хранить около 32000 состояний, мы устанавливаем ее размер равным 5 Мб
        limit_conn perip 10;
        limit_conn perserver 100;
        # Блокируем менеджеры загрузки и некоторые типы ботов
        # Внимательно проверяем  и запоминаем(на будущее) список запрещенных ботов!
        if ($http_user_agent ~* LWP::Simple|BBBike|wget|curl|msnbot|scrapbot) {
            return 403;
        }
        # Блокируем referer спам. (не позволяем переход с гнусных сайтов) Список можно дополнить на своё усмотрение
        if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen|pron|money|free|jwh|speed|test|cash|xxx) )
    {
            return 403;
        }
        #ДАЛЕЕ ИДУТ ВАШИ НАСТРОЙКИ ДЛЯ location / вашего сайта
    }
}

Далее в статье мы вернемся к этим настройкам.

Ковыряем системные переменные, защищаемся от некоторых видов атак


Данные параметры дают некоторую масло-масленность и в некоторых случаях повышают нагрузку.
Редактируем /etc/sysctl.conf
$ sudo nano /etc/sysctl.conf

Дописываем в конец
# Защита от smurf-атак
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Защита от неправильных ICMP-сообщений
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Защита от SYN-флуда
net.ipv4.tcp_syncookies = 1
# Запрещаем маршрутизацию от источника
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Защита от спуфинга
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Мы не маршрутизатор, если конечно это так
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Включаем ExecShield при атаках направленных на переполнение буфера или срыв стэка
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Расширяем диапазон доступных портов
net.ipv4.ip_local_port_range = 2000 65000
# Увеличиваем максимальный размер TCP-буферов
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

#ускоряем высвобождение памяти(см. "Ускоряем общую работу системы")
vm.swappiness=10

Теперь можно перезагрузится

Ускоряем общую работу системы


Prelink и Preload. Prelink для создание статичных адресов библиотек, Preload это небольшое приложение, которое следит за файлами наиболее часто используемых приложений, и загружает их в память, когда система простаивает.
1. Установка Prelink:
$ sudo apt-get -y install prelink

Редактируем файл /etc/default/prelink:
$ sudo nano /etc/default/prelink

Измените строку с PRELINKING=unknown на PRELINKING=yes
Запускаем:
$ sudo /etc/cron.daily/prelink

2. Установка Preload:
$ sudo apt-get -y install preload

Все, больше ничего не требуется

Настраиваем брандмауэр(фаерволл)


Далее будут очень сомнительные конфигурации. Настраиваем число подключений с одного IP адреса.
Спасает при некоторых видах DOS атак и брутфорса.

Выполняем:
$ sudo iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --set

далее:
$ sudo iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --update \
--seconds 15 --hitcount 20 -j DROP

Данное правило ограничивает больше 20-ти подключение к 80 порту(web) за 15 секунд с 1 ip адреса.
(кстати, подобное правило уже установлено на уровне nginx, но сжирает огромное количество ресурсов)

$ sudo iptables -A INPUT -p tcp --dport 354 -i eth0 \
-m state --state NEW -m recent --set


$ sudo iptables -A INPUT -p tcp --dport 354 -i eth0 \
-m state --state NEW -m recent --update \
--seconds 60 --hitcount 4 -j DROP

Где 354 порт вашего ssh сервера. Правило ограничивает количество подключений, не более 4-х подключений за 1 минуту. На деле у меня не получалось авторизовать более 1 раза за минуту.
Далее это правило вы дальше можете адаптировать под себя и другие сервисы.

После рестарта системы все правила обнулятся, по этому делаем следующее:
создаем и редактируем файл /etc/network/if-up.d/00-iptables
$ sudo nano -w /etc/network/if-up.d/00-iptables

Пишем в него:
#!/bin/sh
iptables-restore < /etc/firewall.conf

сохраняем и делаем файл исполняемым:
$ sudo chmod +x /etc/network/if-up.d/00-iptables

Сохраняем правила в файл:
$ sudo iptables-save | sudo tee /etc/firewall.conf

Всё, правила настроены и сохранятся после перезагрузки системы.

На этом первая часть заканчивается, вышло свободное время.

В следующей части расскажу проксирование nginx до node.js, установку и настройку node.js, установка и подключение php-fpm к nginx. + некоторые советы по скорости и безопасности без лишних плясок.

P.S. Это мой первый пост на Хабре и один из первых опытов расширенной настройки debian. Буду рад выслушать критику и исправления.

upd: Благодарю за критику, поправки, советы и отзывчивость хабралюдей. Следующую статью дополню вашими советами.
upd 19.04.16: Немного подрадактировал статью, исправил ошибки и кое-где дополнил. Проверил на debian 8.1 — работает. Новая статья откладывается на n-ое время…
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 96
  • +6
    При добавлении пользователя в sudo, зачем редактировать sudoers? Можно же положить файлик в sudoers.d. Лучше так делать, чтобы потом свои конфиги не мержить при апгрейде.
    • +1
      Спасибо за ценный совет, исправил
      • +5
        А можно просто пользователя в группу sudo добавить.
        • –2
          Если несколько пользователей — то да, но в данном примере пользователь 1.
          • +3
            А в чем проблема добавить пользователя в специально созданную для таких целей группу?
            • –2
              Проблем нет, будет больше 1 пользователя с такими потребностями — создадим
              • +5
                Ее не надо создавать; она уже создана. И предназначена как раз для того, чтобы не делать user ALL=(ALL) ALL

                Да и, раз уж на то пошлО, согласен с Demosfen-ом из комментария ниже — смысла в отдельном юзере, который администрирует личную VPS через постоянный sudo, лично я так и не понял.
                • 0
                  Поправте если я не прав, я так понимаю что замена root на другого пользователя учетную запись нужна только для того, чтобы отключить возможность удаленного логина на систему под root и бандитам, теперь нужно подбирать не только пароль, но и неизвестное имя?
                  • +2
                    Авторизация по ключу и пусть подбирают до опупения.
                    • +2
                      PermitRootLogin without-password и fail2ban вынудят наших бандитов искать более другую систему.

                      Вообще статья в целом довольно неровная. Видно что автор старался, перелопатил некоторое количество документации, но при этом все еще допускает серьезные ошибки — не понимает назначения sudo; зачем-то ставит 64-битную систему на мизерное количество памяти; героически пишет свои скрипты для работы с iptables вместо того, чтобы использовать штатные средства…
        • +8
          Думаю, что для тех, кто попадёт на этот пост из гугла/яндекса по сабжу, пост будет полезен. Возможно даже очень.
          Но вот для хабровчан… не уверен.
          • +4
            Ну почему, не все же имеют опыт развёртывания МЗЫ по одному SSH. У меня, правда, на другом бесплатном хостинге тоже дали доступ по SSH без SFTP, и на этом дело встало. Тут какие-то тонкие настройки имеются, добавят знаний, хотя SFTP, наверное, у автора есть, поэтому нет обсуждения того, как закачивать файлы только по SSH.
            • +12
              Горе тому хабравчанину, который не умеет пользоваться терминалом.
              • +2
                Как это ни странно, но в IT работают (и хабру читают) не только тех. специалисты, а практика показывает, что прочим ролям нет надобности лезть в терминал.
                Вместе с тем, может появиться желание таки попробовать. Эта статья будет отличным подспорьем.

                Да и кто из нас не был новичком? Невозможно ж сразу всё знать (:
              • –1
                Типа SCP там, все дела?
            • –1
              Пишем сложный пароль(который вы не забудете!)и заполняем данные которые считаем нужными, или просто нажимаем enter.

              Почти ко всем серверам не сохраняю и специально не записываю юзер пароли.
              Перейти к юзеру из рута всегда можно без пароля, ftp/ssh клиенты поддерживают авторизацию по ключам…
              • 0
                В статье рекомендуется не сидеть под root-ом, для этого и был создан user.
                • 0
                  На рабочей станции понятно. Но на сервере то на фига? В статье — создаем юзера и дальше все команды погнали через sudo. А смысл? Все равно на сервер нужно ходить только для его обслуживания, т.е. править конфиги, рестартить службы, обновляться и т.п.
                  Сами создаем себе препятствие и в каждой команде его преодолеваем.
                  • +1
                    Лишнее препятствие препятствует и криворукой невнимательности.
                    Так же неопытный пользователь всегда понимает что используется привилегии супер пользователя и что последствия могут быть серьезными.

                    P.S. Однажды перепутал консоли рабочей станции и сервера, и спасло лишь то что пароли от user были разные.
                    • –1
                      А что обычному юзеру делать на сервере? И что админу делать на сервере с правами обычного юзера — все равно ничего сделать не сможетю
                      Если это разработчик, которому нужен ssh, то даем ему обычный аккаунт без всякого sudo.
                      Во всех доках и так уже приучили к sudo, что это одна петрушка с работой под рутом. Был случай — начинающий горе-админ не задумываясь набрал в корне chown -R user:user . — весело было :)
                      Так что толку особо нет от этого. С файлами проектов работаем под юзером, админские задачи решаем под рутом. Пару раз ошибемся конколью и начнем следить что в ней написано — $ или # :)
                      • 0
                        А что обычному юзеру делать на сервере?
                        netststat
                        iostat
                        top
                        iftop
                        ping
                        du
                        df
                        Да мало ли чего обычный такой юзер может сделать полезного…
                        И это не считая того, что может быть надо просто скрипт подправить…
                        • –1
                          Ну вот собственно для таких случаев обычный аккаунт без всяких sudo и т.п.
                      • 0
                        Для себя решил проблему с определением консолей так:
                        на локальной машине промт цветной (force_color_prompt=yes в .bashrc для ubuntu), а на всех серверах монохромный.
                        Теперь перепутать невозможно.
                        • 0
                          P.S. Однажды перепутал консоли рабочей станции и сервера, и спасло лишь то что пароли от user были разные.

                          Раскрашенное приветствие в .bashrc спасает. Тоже после случайного ребута сервера пришел к такому.
                          • 0
                            ещё больше спасает отображение имени сервера в приветствии.
                      • 0
                        Я правильно понимаю, что использование root с авторизацией только по ключу на нестандартном порте можно считать вполне безопасным?
                        • 0
                          При этом доступ к нестандартному порту открыть только с определенных адресов, либо vpn.
                          Иначе безопасность в этом случае будет определяться рабочей станцией админа. Словили трояна, который стащит закрытый ключ и кейлоггером сцапает пароль к нему и досвидульки сервер.
                          • +2
                            То есть поднять на сервере vpn сервер, сменить порт ssh сервера и разрешить только локальный доступ по закрытым ключам без пароля?
                            Это уже для тру продакшн серверов, а против китайцев — паранойя.
                            • 0
                              VPN в этом случае тоже не выход, троян с тем же успехом сможет вытащить вдобавок и сертификат с ключом. А в целом мысль понял, спасибо!
                              • 0
                                Ну защитится от троянов тоже можно.
                                Не пускать к себе за комп никого,
                                использовать антивирус с последними базами(даже если Linux),
                                использовать Linux,
                                не качать и не запускать всякую непроверенную приблуду с левых ресурсов,
                                почаще делать обновления безопасности.
                                • 0
                                  Ну это естественно :) Разве что основная система в моём случае — OS X. Ситуация с антивирусами для неё на данный момент мне не очень понятна. Большинство ругают таковые продукты за бесполезность и тормознутость. Сам не проверял, ничего сказать по этому поводу не могу.

                                  Остаётся два варианта: USB-токены/смарт-карты и одноразовые пароли. Последнее очень просто осуществимо и хорошо защитит от троянов и кейлоггеров. Статеечка была: habrahabr.ru/post/150271/
                              • 0
                                Если подняли vpn, то не нужен нестандартный порт достаточно перевесить ssh на 127.0.0.1 или локальный адрес из левой сети vpn.
                                Собственно владельцы таких серверов, которые думают, что у них не тру-продакшен сервера, рано или поздно становятся либо частью ботнета, либо спам-шлюзом :( Либо становятся промежуточным хопом для взлома серьезных серверов — потом придется долго дядям в масках рассказывать, что это не вы ломали их сервер :)

                                Вообще vpn это только один вариантов. В принципе достаточно ограничить доступ только с ip своей рабочей машины. Либо port-knocking сделать.
                                В любом случае, при большом желании, в случае смены ip или на случай если забудете последовательность портов, всегда сможете получить доступ к локальной консоли сервера удаленно. Прошли уже времена когда надо было в серверную с клавой или монитором бегать в таких случаях. Сейчас или через гипервизор можно получить консоль, либо в случае железного сервака — через bmc/ilo и т.п.
                                • +1
                                  Вообще vpn это только один вариантов. В принципе достаточно ограничить доступ только с ip своей рабочей машины. Либо port-knocking сделать.

                                  Fail2ban еще удобная штука. Парсит логи попыток авторизации в ssh и банит за неудачные попытки авторизации
                      • 0
                        а пароль для sudo? Или NOPASSWD в sudoers?
                        • 0
                          используется пароль user-а для sudo по дефолту
                          • –1
                            Получается если украдут пароль у пользователя, то сразу получат рута. У нас на сервере так и было ) Больше никаких sudo.
                            • +1
                              Точно так же можно украсть пароль от root-а.
                              И не надо давать всем пользователям sudo, а только тем кому это явно требуется, например администраторам.
                              • +1
                                Ну пароль который надо каждый раз вводить в терминале, сложнее украсть чем сохраненный во всяких ftp/коммандерах. А вот пароль юзера который ходить по фтп угоняеться на раз (достаточно иметь заразного соседа в подсети). sftp кое как решает, но риск всеравно слишком большой.

                                Мое мнение, никаких sudo, никаких паролей по ssh, и su только у админа/хозяина.
                                • 0
                                  А root-а держать без пароля (как на убунте по дефолту). И авторизоваться, если нужно, входя отдельной сессией с авторизацией по ключу.
                        • +4
                          Про оптимальную настройку WSGI под Python для такой скромной конфигурации тоже было бы интересно почитать.
                          • +12
                            За эти деньги можно у digitalocean взять впс на KVM с 512 ОЗУ и дисковой SSD. А тут еще 2а дня проблемы с сетью у Вас были :-)
                            • +2
                              NY? Некоторым могут быть пинги критичны.

                              У меня на hostink.ru тоже виртуальный сервер для внутренних нужд имеется.
                              Выбирался в т.ч. по географическому принципу: там стоит часть системы мониторинга, которая не должна стоять в одном ДЦ с продакшеном.
                              Цена меня устраивает, по качеству: да, с сетью тоже проблемы периодически бывают, сервер иногда зачем-то перезагружается, есть баги в панели управления, лично мне не приходит уведомление о том, что баланс подходит к нулю.

                              Но ИМХО вполне стоит своих денег, саппорт отзывчивый (если через helpdesk, телефон не отвечает) — мне настраивали «персональную конфигурацию» ВМ в xen'е.
                              Вообще, складывается впечатление, что его админит один человек (он же руководитель и т.д.), есть пара человек на первой лини саппорта.

                              Рекламировать для серьёзного продакшена не буду, но для каких-то других нужд не плохо.
                              • +3
                                Амстердам (правда неделю назад новые впс в этой зоне только от 1 гига ОЗУ). Три ВПС+ мониторилка у AWS в Ирландии (раньше и сайты там держал). Кстати за год с AWS проблем с сетью и впс не было ни разу. У DO месяца так за три тоже без проблем.
                                • 0
                                  Уже все нельзя разместить в Амстердаме — «Due to high demand and capacity restrictions we have temporarily disabled droplet creation in this region»
                              • 0
                                За такие деньги можно арендовать только сервер в США.
                                Сервер в США это пинги по 100-150 мс, и у некоторых провайдеров — ограничения по скорости.
                                Т.е. это не всем подходит.
                                • 0
                                  За эти деньги можно у digitalocean взять впс на KVM

                                  Только с одним «но» — с ограничением по трафику, что не для всех приемлимо.
                                  Делал для пауков поисковиков и зарубежных посетителей специальный vps «за бугром» для статики, это кардинально снимает нагрузку по трафику для основного сервера.
                                • +2
                                  Я, может, сейчас ерунду спрошу, но тем не менее — а чем fail2ban плох для защиты от брутфорса?
                                  • –2
                                    В сложности настройки для новичка, данных мер на первое время достаточно. + о fail2ban уже не раз писалось и найти руководство не проблема.
                                    • +1
                                      Так ведь fail2ban как раз для новичка и прост. Установил, в конфиге под себя пару параметров изменил, рестартнул и вуаля — ssh как минимум на 99% от китайского шлака свободен.
                                      • +1
                                        Позволю напомнить, что denyhosts ничуть не хуже.
                                  • 0
                                    Спасибо, хороший туториал для начинающих. Мне было интересно читать, узнал кое-что новое. Жду второй части.
                                    • +1
                                      А почему Вы не используете штатный iptables-persistent из репозитория для сохранения и загрузки правил фаервола, а пишете свой скрипт?
                                      • 0
                                        Очень хотелось бы подобный материал по настройке сервера под задачу парсинга большого количества информации в интернете. Там важен тюнинг сетевых параметров ядра, правильный keep-alive, оптимальное кэширование dns запросов, полезные советы по использованию libcurl (как вот тут, но только посвежее).
                                        • –8
                                          а почему putty, а не xshell, который бесплатен для личного использования и куда стабильнее этой недопрограммы с названием putty
                                          • +9
                                            Сам пользуюсь xshell, но вот так оскорблять putty я бы не стал. А какая собственно не стабильность в putty, не поверите, но за все время, вы первый кто сказал что putty не стабильно. Везде есть свои плюсы и минусы, xshell меня за интересовал, только табами, логированием.
                                          • +4
                                            Полезно создавать пользователей с --disabled-password и заливать ssh key. Это надежнее, чем вход по паролю.
                                            • –2
                                              Это не всегда удобно. Но на вкус и цвет…
                                            • +1
                                              И чем wget провинился?
                                              • 0
                                                да curl тоже. У меня многие вытаскивают rss новости курлом, особенно когда импортят на свой сайт…
                                                Но это конечно зависит от назначения создаваемого сайта.
                                              • 0
                                                В комментарии к конфигурации nginx говорится о настройке slimits, однако самой настройки нет.
                                                limit_zone slimits $binary_remote_addr 5m;
                                                limit_conn slimits 20;
                                                

                                                • +2
                                                  Я считаю, что применение Prelink при таком объеме памяти неразумно. Тем более на веб-сервере, когда все службы уже загружены, а ФС итак делает свое дело.
                                                  • +2
                                                    Мне кажется, для тестовых целей есть vds за $10-15 (за год!). Например (тут, о панели и плюшках тут ).
                                                    Искренне не понимаю почему тут пиарят сильно более дорогой и гораздо более лаговый* DO (глючность вылезает, когда на DO мониторинг ставишь, так они вполне ничего)

                                                    *)если кому-то интересен конкретный аргумент (с логами и т.д), пишите в ЛС. Я принципиально публично не выкладываю такие веши.
                                                    • 0
                                                      Хм. Запрещены ссылки на аудио/видео (правила). Т.е. сайт может быть «закрыт, если один из пользователей разместит на сайте ссылку на пиратский контент»? :)
                                                      Контент, размещенный на сайтах и VDS пользователей (в том числе размещённый посетителями сайта) не должен нарушать законов США и Германии. В частности, запрещены: расизм в любой форме; сайты, имеющие отношение к терроризму, а также другой нелегальный контент (например, контент, защищённый авторскими правами, при отсутствии у пользователя прав на распространение такого контента). Примеры нелегального контента: взломанное программное обеспечение, ключи к программным продуктам, программы «для взлома» или другой незаконной активности, медиа файлы (.mp3, .avi), а также ссылки на подобный контент.
                                                      • 0
                                                        Я тоже спрашивал. Есть категория правообладателей, к нарушению прав которых у ДЦ zero-tolerance (так как видимо есть примеры исков). На остальных в общем-то все решается мирно и неспешно.
                                                        • +1
                                                          DMCA в америке, кстати, так и работает.
                                                          Бывает и хуже, рэкспейс, например, меня постоянно блокирует просто за то, что «аккаунт управляется из России».
                                                          Приходится им звонить и выяснять что за фигня.
                                                        • 0
                                                          Для тестовых целей лучше виртуалку завести, дешевые VPS (их, кстати, навалом) могут вести себя непредсказуемо — банально сложно понять, где-то неправильно настроено, или просто VPS глючит. У меня есть один такой за $19 в год — стоит выключенный потому, что на работающем сервере в любой момент могло отвалиться все что угодно, даже ssh.
                                                        • +1
                                                          Здесь явно не последнюю роль играла цена сервера. Искренне рекомендую пойти к www.digitalocean.com — возьмите самый дешевый вариант ($5, это на всего чуть дороже ваших 150 руб/мес), но Вы получите сумасшедшую общую машины скорость из-за быстрого диска, 512 Мб ОЗУ. При создании укажите ДЦ в Амстердаме — и будет он летать едва ли не быстрее иных московских ДЦ.

                                                          Гайд неплохой. По крайней мере (как все подобные тексты) это очень неплохое начало для сам-себе-админа, дающее возможность почувствовать себя хоть насколько-то полным хозяином на сервере. Спасибо Вам!

                                                          • 0
                                                            Ну ладно, а?
                                                            Только что специально проверил:
                                                            — пинги на любой из моих московских серверов — 17-19ms. При том, что я сейчас не в мск даже.
                                                            — пинги на DO амстердам — 70-75
                                                            — NY — 150 +-
                                                            — SFO — 215+-

                                                            Думаю, разница существенная… То есть, летать быстрее он точно не станет.
                                                            Да, в мск проверял релком и ЦТ. сервера лежат железные, colo.

                                                            Хотя, признаюсь, сначала решил сгонять купить попробовать, что там за такие деньги дают 8-)
                                                            • +2
                                                              Да что «ладно». И в России, и в мире по-разному на VPS бывает… Я видел и такие пинги, как у Вас, а видел и заметно худшие. Иногда, кстати, задержка плавала в сутки так, что, видно, соседние VPS-ки выжирали канал не по-детски. Видел даже региональных операторов, которые пинги пропускали на канале вперед, чтобы пинг до Мск от них был лучше, чем у конкурентов :)

                                                              Железные сервера — своя специфика. Машину к тем же Storedata — и вперед, до любой точки России очень неплохо будет. Но вот как коснешься VPS, надо внимательно смотреть: чтобы ресурсов хватало, чтобы диски тянули, чтобы каналы были с запасом. DO по совокупности показателей — весьма и весьма держатся.

                                                              К кому в России на VPS пойти, чтобы диск не тормозил (т.е. было бы, как у DO) — ума не приложу, честно. За 10-20 тыс в мес отличную машину где взять и куда поставить — это легко, а вот 150 руб/мес и радоваться — с эти тяжко ).
                                                              • 0
                                                                Ага, понял. спасибо за инфо.
                                                                Надо будет купить мелочевку на попробовать.

                                                                Просто я как-то на собственных железных серверах всю жизнь, хоть там и не 20, и даже совсем не 10 в месяц, но все равно, VDS, конечно, значительно дешевле выглядит.
                                                                • 0
                                                                  > я как-то на собственных железных серверах

                                                                  Да та же ерунда )) другой мир у них )

                                                                  Но под мелочевку, правда, лучше брать мелочь вроде VPS. Они уже быстры, железо под ними неплохое — все реже есть смысл арендовать сервер за 4-5 тыс. против машины за 150-450 руб в мес.

                                                                  Попробуйте. Они там вроде даже тест давали (я не пользовался тестом, правда), так что… И снапшоты у них хороши, тоже плюс.
                                                            • 0
                                                              А кто-то насчет — www.transip.eu/vps/pricing-and-purchase/ может что-то сказать?
                                                              • 0
                                                                Я пробовал, киви-карту не приняли, оплатил электронной визой местного банка, через сутки пришло письмо что мои данные подозрительные, пришлите сканы паспорта, отправил им, через 6ть дней впс заблокировали, на вопрос в чем дело — написали что я им не присылал сканы, пришлите таким же способом.
                                                                Каждый ответ техподдержки не менее 50мин ждать. Дискового места дают много, но судя по скорости простые sata-винты. Процессора дают немного больше чем в DO. Систему накатываешь сам через KVM. Последующие месяцы оплата за vps в два раза выше (первый месяц промо), в итоге не особо и дешево, учитывая и цены в Евро. Находятся похоже в Нидерландах.
                                                                Вот такой опыт.
                                                            • –1
                                                              По ссх скажу, что рута закрываю вообще, авторизируюсь только по ключу. Больше ничего не надо пока-что.
                                                              • +3
                                                                ОЗУ 128mb
                                                                Debian 7.0 x86-64

                                                                И сразу вопрос — why?
                                                                32битной системы у хостера не было? В данном случае разница в потреблении памяти будет приличной.
                                                                • 0
                                                                  Если навязывать продумывать свою типовую конфигурацию nginx, то мне кажется необходимо включить в конфиг статьи запреты доступа к .htaccess и .svn
                                                                  • 0
                                                                    Для новичков хорошая статья, да и для себя дабы не забыть тоже! Небольшая поправка:
                                                                    На всякий случай посмотрим открытые порты:
                                                                    netstat -tupln | grep LISTEN

                                                                    думаю | grep LISTEN будет здесь лишним, ибо в man-е сказано:
                                                                    -l, --listening
                                                                    Show only listening sockets.

                                                                    • +3
                                                                      Странное дело, пишете, что это «прокачка» debian, а по факту с первых же строк описываете исправление «кривой» базовой установки ОС вашего хостера. Так и напишите в заголовке, что мол «исправляем косяки установки и подкачиваем Debian у %мой_хостер%».

                                                                      теперь по порядку:
                                                                      1) если уж сразу делаете "# apt-get update && apt-get dist-upgrade", то делайте лучше "# apt-get update && apt-get dist-upgrade && apt-get autoremove && apt-get autoclean"

                                                                      2) зачем вы добавляете явно пользователя в sudoers, когда для этого есть специальная группа. И явно она создана не только для того, чтобы «пусть будет». хотя об этом написали выше.
                                                                      ведь явно проще написать «usermod -a -G sudo username», чем ваши манипуляции с sudoers (в случае с ALL)

                                                                      3) про отключение IPv6. лучше не просто отключить у SSH, но и вырубить целиком. за сим бежим сюда (http://wiki.debian.org/DebianIPv6#How_to_turn_off_IPv6)

                                                                      4) лучше не «перелогиниваться», а не закрывая текущую сессию открыть новую, тем самым проверив что новые настройки пашут и потом уже закрывать старую сессию. а в случае с настройкой firewall вообще настроить «откат» правил по крону «на случай ядерной войны».

                                                                      5) вместо дописывания источников в sources.list, лучше класть их отдельными файлами в sources.list.d — так и включать/выключать проще и искать какие выши репы добавленные, а какие «системные». то же самое с правкой конфига nginx — вместо nginx.conf кладём в conf.d (о чём в самом nginx.conf говорит строчка «include /etc/nginx/conf.d/*.conf;»

                                                                      6) вместо "$ sudo iptables-save >/etc/firewall.conf" пишите '$ sudo su -c «iptables-save > /etc/firewall.conf»', тогда будет хватать прав.
                                                                      • 0
                                                                        6) Ещё так можно sudo iptables-save | sudo tee /etc/firewall.conf
                                                                        • 0
                                                                          согласен — способов решения «задачи» достаточно.

                                                                          ЗЫ: можно, чтобы не «пачкать» консоль лишними данными так: «sudo iptables-save | sudo tee tee.sh > /dev/null»
                                                                          • 0
                                                                            fix: вместо «tee.sh» писать/читать "/etc/firewall.conf"
                                                                          • 0
                                                                            Исправил, спасибо
                                                                          • 0
                                                                            1) При чистой установке обычно чистить нечего, но учту.
                                                                            2) Исправил, спасибо.
                                                                            3) Это под 6-ку, на 7-ой не проканает, в следующей статье я опишу способ.
                                                                            4) TODO fix
                                                                            5) Насчет sources не критично, при чистой установке там всего несколько строк, обычно просто отмечаю комментариями. p.s. для меня лично удобнее нагляднее иметь 1 файл.
                                                                            6) Не проканало
                                                                            $ sudo su -c «iptables-save > /etc/firewall.conf»
                                                                            -bash: /etc/firewall.conf»: Отказано в доступе
                                                                            • 0
                                                                              1) ну вы же делаете на чистой установке dist-upgrade для чего-то) за той же целью и autoremove/autoclean
                                                                              3) буквально на днях ставил 7-ку всё нормально прошло. хотя, вроде бы ещё что-то делал. надо бы проверить…

                                                                              6) кхм. у меня выполняется нормально:
                                                                              — borz@server:~$ sudo su -c "/sbin/iptables-save > /etc/firewall.conf"
                                                                              borz@server:~$ l /etc/firewall.conf
                                                                              /etc/firewall.conf
                                                                          • +2
                                                                            Еще из полезного:

                                                                            Раз заговорили про swap, я бы поставил еще zram.
                                                                            Про безопасность — rkhunter
                                                                            И простой MTA для отправки почты и алертов — sSMTP
                                                                            • 0
                                                                              zram стоит по дефолту в дистрах на последних ядрах
                                                                              • 0
                                                                                Пруф в студию!
                                                                                В ядро, возможно, добавлено, но почему-то в Ubuntu, даже последнюю, везде его надо ставить.

                                                                                Про то, что установлено по умолчанию, нашел только Lubuntu 13.10 , и то, как я понимаю, они еще думают.
                                                                                • 0
                                                                                  У меня стоит Kubuntu 13.04 обновленная с Ubuntu 10.04, у меня почему-то есть zram, но вот я его явно не ставил.
                                                                                  А вот насчет debian ошибся, действительно нет. Спасибо
                                                                            • 0
                                                                              Сразу по пунктвм:
                                                                              1. Для избежания длинного диалога useradd имеет массу параматров. Это позволяет сразу создать пользователя с необходимыми параметрами.
                                                                              2. Про sudo молчу — хозяин-барин. :)
                                                                              3. При настройке SSH в первую очередь нужно перейти на авторизацию по RSA!
                                                                              Это аксиома.
                                                                              4. В Nginx нет необходимости настраивать параметр use. Nginx выбирает его автоматом.
                                                                              5. Iptable так не настраивают, есть более безопасные механизмы — сначала создается файл правил, затем проверяется, и только потом включается. Это так — лирика.
                                                                              5. По поводу swappiness — я, по рекомендации IBM использую
                                                                              vm.swappiness = 0
                                                                              vm.vfs_cache_pressure = 100
                                                                              хотя по этому вопросу сколько админов — столько мнений.
                                                                              • 0
                                                                                swap на OVZ не получится поставить, только на XEN.
                                                                                • 0
                                                                                  а OVZ никто не говорит
                                                                                • 0
                                                                                  Немного подрадактировал статью, исправил ошибки и кое-где дополнил. Проверил на debian 8.1 — работает. Новая статья откладывается на n-ое время…

                                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.