среда, 13 декабря 2017 г.

СЕМЬ "СМЕРТЕЛЬНЫХ" ОШИБОК СИСАДМИНА


Работа системного администратора включает в себя огромный спектр возможных задач, особенно если специалист в единственном числе в компании. В потоке дел сложно выстроить работу идеально. Часто лучшие побуждения ИТ-специалистов: переход на новые программные продукты, обновления информационной системы, серверов – приводят к простоям в работе, жалобам пользователей и разнообразным авариям. Еще более губителен для любой системы застой и отсутствие изменений. Использование Windows XP (в 2017 году!) во многих корпоративных сетях поставило их под угрозу весной во время эпидемии шифровальщика WannaCry. Проверить себя поможет наш рейтинг самых популярных и опасных ошибок сисадминов.

1. ПЛОСКАЯ ОРГАНИЗАЦИЯ СЕТИ

Особенно характерна для небольших организаций, когда все используемые сетевые адреса компьютеров легко помещаются в 24-ую сетевую маску и кажется, что нет необходимости в сегментации и использовании VLAN-ов. Для простоты организации подключающиеся к Wi-Fi точкам доступа устройства могут получать адреса из этой же сети. Broadcast storm, ARP-spoofing, атаки компьютерных вирусов с легкостью могут "положить" всю сеть организации, включая критическую серверную и финансовую инфраструктуру, и заставить системного администратора вздрагивать в следующий раз при звонках телефона.


Решение: сегментирование сети и использование VLAN-ов. Подобно кораблю, разбитому на герметичные отсеки, сеть станет более устойчивой к пробоинам.

2. БЛОКИРОВКА ICMP

Устаревшие лет на 15 руководства по безопасности часто предлагают заблокировать протокол ICMP на шлюзах, веб-серверах, рабочих станциях. Но атаки типа Ping of death уже очень давно не актуальны, а документы RFC прямо указывают на необходимость отвечать на ICMP-запросы для всех сетевых хостов. Запретив ICMP, администратор лишь существенно усложняет себе и другим анализ сетевых проблем и увеличивает время их решения, ничуть не способствуя повышению безопасности сети.


Решение: не блокировать ICMP.

3. ОДНОРОДНОЕ СИСТЕМНОЕ ПО

Подход, который, к сожалению, вошел в некоторые корпоративные и ведомственные стандарты: когда на всех серверах и рабочих станциях, для всех служб и сервисов применяется одинаковое ПО (чаще всего речь идет об ОС Windows разных версий). Такая организация сети приводит к ее чрезвычайной уязвимости к вирусным атакам (подтверждением является массовое распространение по сетям вирусов WannaCry, NotPetya, BadRabbit). На сегодняшний день нет никаких (кроме одобренного N лет назад "регламента") причин не использовать альтернативные операционные системы хотя бы в серверной инфраструктуре. Сервер 1С, базы данных, гипервизоры, файловое хранилище быстрее, проще и дешевле развернуть на базе одного из дистрибутивов Linux. Как минимум на часть рабочих мест также можно установить Linux, если там есть необходимость только в стандартном офисном ПО. Многие компании готовы выделять огромные средства на средства защиты информации, антивирусы и другое ПО, но не рассматривают или отвергают этот недорогой способ, значительно снижающий векторы атак злоумышленников.


Решение: использование альтернативных ОС в серверной и офисной инфраструктуре, где это возможно.

4. ОТСУТСТВИЕ ПЛАНИРОВАНИЯ

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


Решение: составление долгосрочных, среднесрочных и оперативных планов задач. План Б на случай больших сбоев.


5. ИСПОЛЬЗОВАНИЕ УСТАРЕВШИХ СРЕДСТВ ЗАЩИТЫ

Многие до сих пор привыкли полагаться лишь на антивирусное ПО для защиты конечных рабочих станций. Злоумышленники же перед выходом "релизов" троянов и шифровальщиков тестируют их на большом количестве антивирусного ПО (часто используя сервис virustotal.com, что доступно даже школьнику), поэтому не только сигнатурный, но и эвристический анализ файлов антивирусами зачастую бессилен против них. Меньшее внимание администраторы уделяют средствам защиты сетевого периметра, проверке внутрисегментного и локального трафика. В качестве интернет-шлюза часто используется обычный межсетевой экран, либо устаревшее уязвимое ПО: Microsoft TMG, другое ПО на ОС Windows. Таким образом сеть оказывается беззащитной для современного типа атак.


Решение: использовать современные средства защиты – UTM и NGFW решения. Например, шлюз безопасности Ideco ICS.

6. ОТСУТСТВИЕ ДОКУМЕНТАЦИИ

Все мы слишком часто полагаемся на свою память или память коллег из IT-отдела. Поднятый через неделю-другую тюнинга веб-сервер или сервер базы данных, возможно, через несколько лет придется поднимать повторно. Без документирования даже у одного и того же специалиста это может занять столько же или даже больше времени.

Решение: не лениться документировать изменения настроек всех серверов, сервисов и сетевых устройств.

7. ДОВЕРЯТЬ СИСТЕМЕ АВТОМАТИЧЕСКОГО РЕЗЕРВНОГО КОПИРОВАНИЯ

Без ручной проверки восстановления из бэкапов. В самый неподходящий момент может оказаться, что в бэкапы не включены ценные данные (папка "Работа" на рабочем столе генерального директора), либо из них невозможно восстановить информацию, или еще хуже - они давно не создаются из-за какой-нибудь ошибки или аппаратного сбоя.


Решение: регламентированная (хотя бы раз в месяц) ручная проверка бэкапов.

Стабильного коннекта и большого аптайма вашим сервисам!

Ссылка

четверг, 13 июля 2017 г.


ProxMox — уменьшаем диск в LXC.




Задача : после переноса данных в другой mount_point, капитальной расчистки внутри LXC-контейнера или ошибочного задания слишком большого размера файла диска требуется этот диск ресайзнуть в меньшую сторону.

Веб-интерфейс такого не предоставляет (там можно только увеличить размер), поэтому переведу одну рекомендацию с форума проксмокса (https://forum.proxmox.com/threads/shrink-disk-size.24808/#post-124343), чтобы не потерялась.

Для примера, у нас будет LXC-контейнер № 366, проксмокс 4.2, надо уменьшить размер диска с 8 Гб до 2 Гб, пути стандартные.

По шагам, поехали:

1). Останавливаем контейнер.

2). Делаем бэкап.
3). Проверяем, что бэкап есть.

4). Дополнительно копируем файл с дисковым образом ( /var/lib/vz/images/366/vm-366-disk-1.raw ) в другой каталог, если что-нибудь пойдёт не так. Такой образ закопировать назад поверх битого может быть в ряде случаев быстрее, чем разжать из бэкапа.

5). Заходим в каталог с образом диска:
# cd /var/lib/vz/images/366

6). Проверяем файловую систему:
# e2fsck -f vm-366-disk-1.raw
Видим вот такое:

e2fsck: MMP: fsck being run while checking MMP block
MMP check failed: If you are sure the filesystem is not in use on any node, run:
‘tune2fs -f -E clear_mmp {device}’

7). Делаем исправление:
# tune2fs -f -E clear_mmp vm-366-disk-1.raw

8). Снова проверяем, что файловая система внутри теперь в норме:
# e2fsck -f vm-366-disk-1.raw
Должен быть примерно такой вывод:


e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
vm-366-disk-1.raw: 21325/524288 files (0.4% non-contiguous), 240360/2097152 blocks

9). Уменьшаем размер самой структуры файловой системы внутри дискового образа:
# resize2fs -M vm-366-disk-1.raw 2G
Размер ФС будет сильно уменьшен:


resize2fs 1.42.12 (29-Aug-2014)
Resizing the filesystem on vm-366-disk-1.raw to 318585 (4k) blocks.
The filesystem on vm-366-disk-1.raw is now 318585 (4k) blocks long.

Обратите внимание на число блоков — 318585 !

10). Обрежем лишнюю часть файла до размера 2 Гб:
# truncate -s 2G vm-366-disk-1.raw

11). Расширим размер структуры файловой сисемы до нового размера файла-образа:
# resize2fs vm-366-disk-1.raw
Это нужно, чтобы внутри файла выделенное пространство полностью было задействовано файловой системой.


resize2fs 1.42.12 (29-Aug-2014)
Resizing the filesystem on vm-366-disk-1.raw to 524288 (4k) blocks.
The filesystem on vm-366-disk-1.raw is now 524288 (4k) blocks long.

Обратите внимание на число блоков — 524288 !

12). Исправим размер образа в конфиге контейнера:
# vi /etc/pve/nodes/vps3/lxc/366.conf
Если vi вызывает у вас аллергию — используйте любой другой редактор, их много. Правим параметр size в свойствах диска:

rootfs: local:366/vm-366-disk-1.raw,size=2G

Сохраняем, обновляем страницу со свойствами контейнера в веб-интерфейсе, убеждаемся, что размер поменялся.

13). Запускаем контейнер.

14). Заходим в него по SSH, проверяем, что всё работает, смотрим на свободное место :
# df -h -t ext4

Filesystem Size Used Avail Use% Mounted on
/dev/loop1 1.9G 677M 1.1G 39% /

1.9 Гб вместо 7.8 Гб места при 677М данных. Это очень позитивно сказывается на скорости переноса контейнера (при отсутствии общего хранилища), времени бэкапа/восстановления и глубине / объёмах бэкапов.

понедельник, 10 июля 2017 г.

Управление автозагрузкой в debian

Скрипты инициализации - это не большие программы на shell, которые обычно управляют сервисами, также известными как демоны. Прочие приложения для скриптов инициализации включают в себя простое управление состоянием чего-нибудь вроде hdparm (управляет временем перехода в спящий режим для жестких дисков), iptables (загрузка правил файрвола в ядро) и setserial (конфигурация последовательного порта). Директория /etc/init.d содержит скрипты исполняемые с помощью init во время загрузки и состоянии инициализации.
Скрипты инициализации также важны во время запуска и останова системы (в *nix системах просто меняется“runlevel”). Если вы посмотрите на список процессов, запущенных на вашей машине (попробуйте команду ps auwx), то есть вероятность, что процесс с наименьшим PID будет называться “init”. Это родительский процесс для всех процессов, это первая программа которую ядро запускает при загрузке. Программа init, которую можно найти по пути /sbin/init, ответственна за в рабочее состояние после того, как загрузится ядро.
Существует три простые утилиты для управления стартовыми и инициализационными скриптами:
Далее мы рассмотрим их все и приведем несколько примеров их использования.

update-rc.d

Устанавливает и удаляет ссылки на скрипты инициализации в System-V стиле. update-rc.d автоматически обновляет ссылки на скрипты инициализации в System-V стиле вида /etc/rcrunlevel.d/NNname на скрипты /etc/init.d/name. Они запускаются с помощью init когда меняется уровень загрузки и обычно используются для запуска или остановки системных сервисов, таких как  демоны. init поддерживает следующие уровни загрузки - 0123456789S и NN - это двухцифренный код используемый init для определения в каком порядке должны запускаться скрипты.
Синтаксис update-rc.d
update-rc.d [-n] [-f] name remove
update-rc.d [-n] name defaults [NN | NN-start NN-stop]
update-rc.d [-n] name start|stop NN runlevel runlevel start|stop NN runlevel runlevel
Когда запускается с опциями defaults, start или stop, update-rc.d создает ссылки /etc/rcrunlevel.d/[SK]NNname указывающие на скрипт /etc/init.d/name. Если какие-либо файлы уже существуют, то update-rc.d ничего не делает. Это объясняется тем, что системный администратор может изменить порядок ссылок, при условии, что как минимум одна ссылка сохранится, без того чтобы конфигурация была перезаписана.
Доступные опции.
-n - ничего не делать, только показать что будет сделано.
-f - заставить удалять символические ссылки  даже если /etc/init.d/name все еще существует.
Примеры использования update-rc.d
Вставить ссылки с использованием defaults:
# update-rc.d samba defaults
Эквивалентная команда с использованием явных наборов аргументов:
# update-rc.d samba start 20 2 3 4 5 . stop 20 0 1 6 .
Если вы хотите удалить скрипт из автозагрузки, то используйте следующую команду:
# update-rc.d -f samba remove
Если вы хотите узнать о команде update-rc.d больше, то прочтите страницу man.

rcconf

Rcconf позволяет управлять тем, какие сервисы будут запускаться когда система загружается или уходит в перезагрузку. Утилита показывает меню, содержащее все сервисы, которые должны быть запущены при загрузке. Те, которые должны запускаться помечены и вы можете включить или выключить отдельные сервисы. Эта утилита конфигурирует системные сервисы во взаимодействии с системными уровнями загрузки (runlevels). Она включает или выключает сервисы с применением скриптов в /etc/init.d/. Rcconf работает с конфигурацией уровней загрузки в стиле System-V. Фактически это TUI(Text User Interface) к команде update-rc.d
Rcconf получает список сервисов от /etc/init.d и просматривает директории /etc/rc?.d чтобы определить запущен сервис или нет.
Если число (NN в /etc/rc?.d/NNname) не равно 20 (по умолчанию), то rcconf сохраняет имя сервиса и число в /var/lib/rcconf/services так что возможно восстановить конфигурацию сервиса в исходном состоянии.
Установка rcconf в Debian.
# aptitude install rcconf
Эта команда выполнит установку. Теперь вы можете использовать утилиту с помощью команды:
# rcconf
Если будет выводится сообщение rcconf needs dialog or whiptail, то необходимо будет установить утилиту dialog:
# aptitude install dialog
Теперь запустив rcconf Вы увидите на экране следующее:
rcconf управление автозагрузкой
Важные файлы:
/var/lib/rcconf/services - файл с данными о номерах процессов.
/var/lib/rcconf/lock - файл блокировки.
/var/lib/rcconf/guide.default - Guide File который генерируется утилитой update-rcconf-guide.
/var/lib/rcconf/guide - Guide File  который может быть определен пользователем (администратором).
Если вы хотите узнать больше об утилите rcconf, то ознакомьтесь со страницей man.

file-rc

Этот пакет предоставляет альтернативный механизм для загрузки или остановки системы и смены уровней загрузки. Ссылки /etc/rc?.d/* будут сконвертированы в единый конфигурационный файл /etc/runlevel.conf который легче администрировать, чем символьные ссылки и который более гибок. Пакет автоматически сконвертирует ваши существующие символьные ссылки в файл во время установки и конвертирует файл обратно в символьные ссылки при удалении. Оба механизма совместимы посредством скриптов /etc/init.d/rc, /etc/init.d/rc*, /usr/sbin/update-rc.d и /usr/sbin/invoke-rc.d
Установка file-rc в Debian.
# aptitude install file-rc
В ходе установки в русифицированной версии Debian выводятся следующие сообщения:
Следующие НОВЫЕ пакеты будут установлены:
file-rc
0 пакетов обновлено, 1 установлено новых, 0 пакетов отмечено для удаления, и 42 пакетов не обновлено.
Необходимо получить 39,2 kB архивов. После распаковки 184 kB будет занято.
Следующие пакеты имеют неудовлетворённые зависимости:
sysv-rc: Конфликтует: file-rc но устанавливается 0.8.12.
Следующие действия разрешат зависимости:
    Удалить следующие пакеты:
1)     sysv-rc
Принять данное решение? [Y/n/q/?] y
Следующие НОВЫЕ пакеты будут установлены:
file-rc
Следующие пакеты будут УДАЛЕНЫ:
sysv-rc{a}
0 пакетов обновлено, 1 установлено новых, 1 пакетов отмечено для удаления, и 41 пакетов не обновлено.
Необходимо получить 39,2 kB архивов. После распаковки освободится 123 k байт.
Хотите продолжить? [Y/n/?] y
Получить:1 http://mirror.yandex.ru/debian/ squeeze/main file-rc all 0.8.12 [39,2 kB]
Получено 39,2 kБ в 0с (462 kБ/с)
dpkg: sysv-rc: имеются проблемы с зависимостями, но по вашему указанию
он всё равно будет удалён:
initscripts зависит от sysv-rc | file-rc, однако:
Пакет sysv-rc будет удалён.
Пакет file-rc не установлен.
sysvinit зависит от sysv-rc | file-rc, однако:
Пакет sysv-rc будет удалён.
Пакет file-rc не установлен.
(Чтение базы данных ... на данный момент установлено 36373 файла и каталога.)
Удаляется пакет sysv-rc ...
warning: reverting to legacy boot ordering
Обрабатываются триггеры для man-db ...
Выбор ранее не выбранного пакета file-rc.
(Чтение базы данных ... на данный момент установлено 36346 файлов и каталогов.)
Распаковывается пакет file-rc (из файла .../file-rc_0.8.12_all.deb)...
Обрабатываются триггеры для man-db ...
Настраивается пакет file-rc (0.8.12) ...
Текущее состояние: 41 обновлён [-1].
Конфигурационный файл file-rc расположен в /etc/runlevel.conf. Если вы хотите посмотреть конфигурационный файл по умолчанию, то это можно сделать здесь.
Пример:
#
05 - 0 /etc/init.d/halt
05 - 1 /etc/init.d/single
05 - 6 /etc/init.d/reboot
10 0,1,6 2,3,4,5 /etc/init.d/sysklogd
12 0,1,6 2,3,4,5 /etc/init.d/kerneld
[…]
89 0,1,6 2,3,4,5 /etc/init.d/cron
99 - 2,3,4,5 /etc/init.d/rmnologin
99 0,1,6 2,3,4,5 /etc/init.d/xdm