Веб-программист
0,0
рейтинг
11 июля 2013 в 20:57

Разработка → Прокачка debian/ubuntu сервера для маленьких из песочницы tutorial

Всем привет. Недавно появилась необходимость поднятие 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-ое время…
Gleb Pavlov @winox
карма
23,0
рейтинг 0,0
Веб-программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (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
                Это тоже есть.
              • 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-ое время…

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