Системный администратор
Профиль: GNU \ Linux

Достижения

Все достижения (4)

Наибольший вклад в теги

Все теги (40)

Лучшие ответы пользователя

Все ответы (49)
  • Как грамотно настроить автоматические обновления на боевом Ubuntu Server?

    1. По опыту скажу что на production-серверах обновление лучше делать вручную, если нету зеркального сервера для тестов. Периодичность обновления советую раз в 15-20 дней. Разумеется, в случае экстренных проблем с безопасностью типа heartbleed, как ты упомянул, обновлять надо сразу, при выпуске заплаток.
    2. Если не осиливаешь пока chef и puppet почитай про Ansible. У него порог вхождения существенно ниже чем у вышеупомянутых и поддерживать его в дальнейшем намного проще, а по функционалу, если честно, он не уступает.
    3. Общие советы.
    1. Отключи не используемые службы (rpcbind, nfscommon) к примеру
    2. Заблокируй не используемых пользователей, проверь не имеют ли системные пользователи паролей (в /etc/shadow наличие хеша во втором поле, если имеют а доступ им не нужен ставь '!')
    3. Желательно включить ssh авторизацию только по ключам, включить опцию AllowUsers со списком пользователей которым авторизироваться разрешено. Отключить авторизацию по ssh root и создать системного пользователя с оболочкой sh, без всяких привилегий. Его занести в AllowUsers, при логине выполнять /bin/su - с полным путем.
    4. По возможности все используемые службы контролировать TCP Wrappers (/etc/hosts.{allow,deny})
    5. Установить библиотеку snoopy (snoopy logger) - очень подробное логирование запускаемых процессов.
    6. Соответственно настроить rsyslog/syslog-ng и перенаправлять логи желательно на сторонний сервер. Для логов есть различные веб-морды с различными отчетами и сортировками.
    7. Для контроля версий конфигурационных файлов советую использовать git в /etc либо выносить под различные службы в отдельные репозитарии и, конечно, настроить правильно .gitignore. Тут же присмотрись к подсистеме событий файловой системе inotify и отличному демону incron. Он пригодиться может не только в этом пункте, с ним можно много интересных вещей контролировать.
    8. По возможности настраивай все службы и сервисы в chroot окружении.
    9. Iptables. Можно на нем, а можно к примеру на ipset настраивать правила. Тут все просто. Лучше сначала создай скрипт на тестовой машине. Политики по умолчанию - deny all, а дальше разрешаешь что нужно. Конкретно что то посоветовать не имеет смысла если ты как обезьянка начнешь копировать без понимания. Есть отличная литература по iptables. А дальше ищи в интернете iptables tips, примеры настройки iptables и вникай что там делают и для чего. Но не перемудри. Понимай что пакеты пробегают по всем цепочкам правил. Это нагрузно. Задумайся об использовании ipset.
      Всякие fail2ban-ы советовать не буду. Слишком спорно и не нужно если ты правильно отстроишь любой сервис работающий поверх netfilter. Так же многие хостинги из коробки имеют защиту от DDOS и брута на уровне своего железа типа ASA-к и тд.
      Периодически делай срезы tcpdump-ом (особенно в подозрительных ситуациях) и анализируй wireshark-ом.
    10. Постоянные бэкапы, хоть rsync, fsbackup, unison, bacula и тд - выбор большой


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

    Для этого могу посоветовать 4 системы (это лично мои приоритеты, но их оочень много).
    Zabbix, Nagios, Sensu, Cacti

    Хорошим вариантом будет установка zabbix_agent-а не сервер и удаленный мониторинг с другого сервера. Настроишь свои скрипты + анализ логов syslog и вот уже залог достаточно устойчивой и на мой взгляд хорошо защищенной системы.
    Ответ написан
  • Существуют ли SSH-proxy для логирования?

    Попробуйте ELF библиотеку snoopy (snoopy logger). Есть готовые пакеты под большинство rpm/deb-систем.
    Логирует все исполняемые консольные команды, все запускаемые скрипты и тд. Обойти можно только отключив прелоад библиотеки (собственно надо иметь права суперпользователя).
    Вывод в логах крайне подробный и информативный. Пример:
    Aug 10 06:30:01 ctrx snoopy[15967]: [uid:0 sid:15967 tty: cwd:/root filename:/usr/bin/scp]: scp www-data@***********:/home/www-data/downld02.txt /var/www/ctrx.com/collect/downld02.txt
    Aug 10 06:30:01 ctrx snoopy[15968]: [uid:0 sid:15968 tty: cwd:/root filename:/srv/www/forum.ctrx.com/bin/collect-stats]: /srv/www/forum.ctrx.com/bin/collect-stats
    Aug 10 06:30:01 ctrx snoopy[15966]: [uid:0 sid:15966 tty: cwd:/root filename:/srv/www/www.ctrx.com/bin/process-collect-data]: /srv/www/www.ctrx.com/bin/process-collect-data
    Aug 10 06:30:01 ctrx snoopy[15969]: [uid:0 sid:15969 tty: cwd:/root filename:/usr/bin/sync-video]: /usr/bin/sync-video
    Aug 10 06:30:01 ctrx snoopy[15971]: [uid:0 sid:15969 tty: cwd:/root filename:/usr/bin/basename]: basename /usr/bin/sync-video
    Aug 10 06:30:01 ctrx snoopy[15973]: [uid:0 sid:15969 tty: cwd:/root filename:/usr/bin/flock]: flock -n 9
    Aug 10 06:30:01 ctrx snoopy[15974]: [uid:0 sid:15969 tty: cwd:/root filename:/usr/bin/rsync]: rsync -a -L --log-file=/var/log/sync.log www-data@**********:/srv/video /var/www/ctrx.com/alias.ctrx.com/docs/projects/ctrx.com/
    Aug 10 06:30:02 ctrx CRON[15963]: pam_unix(cron:session): session closed for user root
    Aug 10 06:30:02 ctrx snoopy[15977]: [uid:106 sid:44096 tty: cwd:/ filename:/bin/cat]: cat /proc/diskstats


    Как видно логируется точная дата, хост, uid, sid, терминал, pwd, команда

    Далее можете уже на хосте настроить syslog-ng/rsyslog что бы отделять логи snoopy (по умолчанию летит все в auth.log) и если есть необходимость пересылать по tcp/udp на коллектор логов для дальнейшего анализа и хранения

    Лично я пытаюсь его совместить со стандартным auth, authpriv и разделять по host/user что бы видеть кто когда логинился и что выполнял, а так же отсеять мусор от служебных пользователей типа zabbix (от zabbix-agentd), который выполняет кучу команд и в принципе не нужен в логах

    P.S. Кстати благодаря этой библиотеке многое узнал о процессах протекающих в разных системах (Debian 6,7, Arch, RH5, Ubuntu Server 12.04/14.04) без моего ведома, о их "скрытой жизни". Особенно поразила Ubuntu Server в плохом смысле.
    Еще был найден баг в Debian 6 в скриптах bash_completion. В Wheezy уже починили.
    Ответ написан
  • Совместимы ли будут две планки оперативки?

    А спецификации к материнской плате читать не пробовали?
    www.asus.com/Motherboards/Intel_Socket_775/P5Q/#MSL

    Первое с чего начинать надо — именно с этого.
    Ответ написан
  • Две версии python (2.7 и 3.3) на Uuntu 12.04. Какие проблемы могут возникнуть?

    Что в virtualenv сложного? Так же устанавливаешь virtualenv на сервер той версии какой нужен python. Дальше все очень тривиально и просто.
    # Убедись что он 2ой версии
    apt-cache show python-virtualenv
    # Устанавливаешь virtualenv  
    apt-get install python-virtualenv  
    # Создаешь новый проект, установленные в системы либы не тянешь
    virtualenv --no-site-packages project
    # Активируешь виртуальное окружение
    # Все. Теперь команда pip будет устанавливать все пакеты в твое окружение а не системное
    . ./project/bin/activate
    # Устанавливаешь Django   
    pip install django


    Если же по каким то причинам не хочешь виртуального окружения, то поставь версию pip-а в систему под питон нужный тебе:
    $ apt-cache search virtualenv
    python-pip - alternative Python package installer
    python3-pip - alternative Python package installer - Python 3 version of the package

    И обращаться к нему уже будешь pip, pip3

    Как дополнение: в Debian и Ubuntu есть механизм выбора приоритетов. Все что он делает - переключает ссылку на нужные версии софта.
    Делается это по средством команды update-alternatives
    Ответ написан