Subnets.ru blog

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Итак, вы в качестве пограничного маршрутизатора своей AS выбрали маршрутизатор Juniper.

Поздравляю вас ! Вы сделали отличный выбор ! 😉

В этой статье я постараюсь рассказать как настроить протокол BGP на оборудовании этого производителя.

Это не how-to на все случаи в жизни, а пример, с которого можно хоть как-то начать постигать замечательное железо от Juniper.

В качестве примера буду использовать:

Наша автономная система: AS100

Наш префикс: 1.1.0.0/20

Схема подключения:

Два апстрима: AS200 (2.2.2.1/30) и AS300 (3.3.3.1/30)

И один прямой пиринг с AS400 (4.4.4.1/30)

Будем подразумевать, что соответствующие IP интерфейсы на маршрутизаторе вы уже настроили. Пример настройки интерфейсов можно посмотреть в этой статье и сделать по аналогии.

Настройка протокола BGP начинается с секции protocols.

Войдем в режим конфигурации:

root@juniper> configure

перейдем в раздел protocols bgp

[edit]
root@juniper# edit protocols bgp

Начнем с того, что укажем номер своей автономной системы:

[edit protocols bgp]
root@juniper# set local-as 100

Зададим логирование изменений состояния «соседей» (peer):

[edit protocols bgp]
root@juniper# set log-updown

Воспользуемся следующей опцией, чтобы оглашать лучший маршрут даже если в таблице маршрутизации он не является активным маршрутом:

[edit protocols bgp]
root@juniper# set advertise-inactive

Зададим route flap damping (так называемые «хлопающие» маршруты):

Т.к. это пограничный маршрутизатор, а значит «серые» сети не должны выходить за его пределы, выполним следущее (discard):

[edit routing-options]
root@juniper# set route 10.0.0.0/8 discard

[edit routing-options]
root@juniper# set route 172.16.0.0/12 discard

[edit routing-options]
root@juniper# set route 192.168.0.0/16 discard

Не будем «насиловать» лишними маршрутами своих апстримов и будем им оглашать весь блок /20 целиком. Для этого сделаем агрегирование:

[edit routing-options]
root@juniper# set aggregate route 1.1.0.0/20 discard

Посмотрим что получилось в этой секции:

[edit routing-options]
root@juniper# show

Настало время создать маршрутные карты. Начнем с per-flow-load-balancing.

Перейдем в другую секцию:

[edit routing-options]
root@juniper# top

[edit]
root@juniper# edit policy-options

Создадим для per-flow-load-balancing:

[edit policy-options]
root@juniper# set policy-statement per-flow-load-balancing term balance then load-balance per-packet

Приступим к дефолтным маршрутным картам для соседей.

Для начала bogus-reject:

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 127.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 10.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 172.16.0.0/12 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 192.168.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 169.254.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 224.0.0.0/4 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 240.0.0.0/4 orlonger

Так мы задали список маршрутов, теперь укажем что мы с ними хотим сделать, в т.ч., и не принимать такие маршруты:

[edit policy-options]
root@juniper# set policy-statement bogus-reject then reject

Создадим default-route-reject для запрета приема default gateway по протоколу BGP:

[edit policy-options]
root@juniper# set policy-statement default-route-reject from route-filter 0.0.0.0/0 exact

[edit policy-options]
root@juniper# set policy-statement default-route-reject then reject

Создадим bogus-ases для запрета приема «серых» (private) номеров AS:

[edit policy-options]
root@juniper# set policy-statement bogus-ases from as-path grey-as

[edit policy-options]
root@juniper# set policy-statement bogus-ases then reject

[edit policy-options]
root@juniper# set policy-statement as-path grey-as 64512-65535

Пришло время для карт для соседей. В маршрутных картах на in (input) вы можете «играться» с теми или иными маршрутами приходящими от соседей. Фильтровать что-то, поднимать local-prefence и т.п. Для примера покажу как поднять local-prefence на маршрутах, для которых ваш апстрим является origin (т.е. те маршруты, которые принадлежат его AS).

Итак Prov-1-in:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as from as-path prov-1-as

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then local-preference 200

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then accept

Теперь создадим as-path:

[edit policy-options]
root@juniper# set as-path prov-1-as «.*200»

Т.к. orign AS для маршрута всегда находится в конце as-path, то я и задал регулярное выражение которое ищет AS200 в конце as-path. Подробнее о регулярных выражениях читайте в технической документации по вашей версии JUNOS. Вы можете использовать не только as-path, но и префиксы которые принадлежат данному апстриму. Это на ваш выбор. Я выбрал as-path потому, что бы каждый раз не лазать и не изменять конфиг когда у этого апстрима появится новый блок IP-адресов.

Теперь зададим последний этап обработки приходящих от этого апстрима маршутов и действий с ними. Т.к. у нас full-view, то логично, что мы разрешим все остальное:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then accept

Тут же вы можете выставить default local-preference для этого апстрима:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then local-preference 100

Проделайте тоже самое и для Prov-2-in подставив туда его значения создав policy-statement Prov-2-in и as-path с AS300.

Для примера для нашего прямого пира AS400 мы создадим маршрутку с его префиксами, а не с as-path:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix from prefix-list-filter peer-1-prefix exact

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then accept

Поднимем local-preference для этих маршрутов выше, чем все остальное:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then local-preference 210

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

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term final-reject then reject

Ну и осталось создать peer-1-prefix который мы прописали выше и указать в нем префиксы, которые принадлежат AS400, допустим это будут префиксы:

• 195.128.0.0/16
• 77.87.224.0/21

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 195.128.0.0/16

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 77.87.224.0/21

Итак с приемом маршрутов разобрались, приступим к оглашению наших. Эта задача состоит из двух частей:

• оглашение агрегированного маршрута для апстримов
• оглашение разделенного блока /20 для прямого пира

При прописывании всех наших соседей мы использовали разные маршрутные карты для того, что бы у нас была возможность управлять анонсами для каждого соседа по разному. Это вам пригодится для управления входящим в вашу AS трафиком, например prepend`ом.

Начнем с AS200 (первый апстрим) и как мы условились апстримам мы оглашаем агрегированный маршрут:

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from protocol aggregate

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from policy our-CIDR-blocks-aggregated

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix then accept

Создадим сам фильтр policy our-CIDR-blocks-aggregated:

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix from route-filter 1.1.0.0/20 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix then accept

Т.к. на данном этапе мы всем апстримам оглашаем одно и тоже, то создайте Prov-2-out сами.

Теперь нужно сделать out для нашего прямого пира и оглашать мы ему будем две сети /21:

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from protocol static

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from policy our-CIDR-blocks

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix then accept

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term final-reject then reject

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.0.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.8.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes then accept

Ну вот вроде на первый взляд и все. Проверим все ли в порядке:

[edit policy-options]
root@juniper# commit check

Если в ответ вы получили сообщение:

configuration check succeeds

значит ошибок в конфигурации нет и вы можете применять её на маршрутизаторе. Сделаем это и добавим комментарий к этому конфигу:

[edit policy-options]
root@juniper# commit comment «My first configuration»

Juniper может хранить до 50-ти «закомиченных» конфигураций и вы всегда можете откатываться к любой их них, поэтому я рекомендую всегда добавлять комментарий к конфигу, чтобы потом различать их 🙂

Посмотреть состояние всех соседей можно командой:

[edit policy-options]
root@juniper# run show bgp summary

Т.к. мы все ещё находимся в режиме конфигурирования нам приходится добавлять ключевое слово run чтобы команда show отработала не на конфигурации.

Если мы выйдем из режима конфигурирования:

[edit policy-options]
root@juniper# exit

то тут слово run добавлять уже не нужно:

root@juniper> show bgp summary

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

Мануал, по всем командам, вы можете прочитать в технической документации по вашей версии Junos на сайте производителя: www.juniper.net

Рекомендую полистать книгу:

JUNOS Cookbook

By Aviva Garrett

………………………………………..

Publisher: O’Reilly

Pub Date: April 2006

Print ISBN-10: 0-596-10014-0

Print ISBN-13: 978-0-59-610014-8

Pages: 682

Заранее прошу прощения за оЧепЯтки и неточности. По мере нахождения багов и замечаний статья будет изменяться.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Policy-based routing — это более гибкий механизм маршрутизации пакетов, чем обычная адресная маршрутизация (destination routing).

Его главная особенность состоит в том, что перед маршрутизацией все пакеты проходят через
маршрутную карту (route-map), которая определяет, какие пакеты маршрутизировать и какой роутер будет следующим исходя из IP-адреса источника (source — source routing). Вы можете включить policy-based routing если хотите, чтобы некоторые пакеты были направлены по пути, отличному от очевидно самого короткого пути (the obvious shortest path), то есть пути взятого из таблицы маршрутизации.

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

Допустим что:
У нас имеется cisco catalyst 3560G c IOS advanced ip services
интерфейс для стыка с провайдером «пров-1» vlan 10, IP-адресация 1.1.1.0/30
выделенная подсеть для раздачи под юзеров 192.168.241.0/26
IP-адрес 192.168.241.1 висит на vlan 20

интерфейс для стыка с провайдером «пров-2» vlan 11, IP-адресация 2.2.2.0/30
выделенная подсеть для раздачи под юзеров 10.0.18.0/26
IP-адрес 10.0.18.1 висит на vlan 21

при этом роутинг по умолчанию на cisco указан на «пров-1»

ip route 0.0.0.0 0.0.0.0 1.1.1.1

Соответственно получаем ситуацию когда подсеть выделенная от пров-2 будет улетать в канал от пров-1 и работать не будет. В этой ситуации нам и поможет policy-based routing

Как разрешить эту проблему используя policy-based routing:
Switch> enable
Switch# configure terminal
Switch(config)# ip routing
Switch(config)# sdm prefer routing
Switch(config)# exit
Switch# wri
Switch# reload

После того как cisco перезагрузится:

Создаем standart access-list (например номер 11) где описываем подсеть выделенную пров-2:
Switch> enable
Switch# configure terminal
Switch(config)# ip access-list standard 11
Switch(config-std-nacl)# permit 10.0.18.0 0.0.0.63
Switch(config-std-nacl)# exit

Далее создаем маршрутную карту указывая в ней созданный access-list как то что нужно матчить (match):

Switch(config)# route-map TEST permit 10
Switch(config-route-map)# matсh ip address 11
Switch(config-route-map)# set ip next-hop 2.2.2.1
Switch(config-route-map)# exit

Так мы создали маршрутную карту route-map с именем TEST, которая матчит IP-адреса из подсети пров-2 и выставляет как next-hop IP-адрес пров-2, теперь осталось её применить.

Заходим на интерфейс cisco на котором висит IP-адрес 10.0.18.1, который будет выступать в качестве default gateway для пользователей в этой подсети:

Switch(config)# int vlan 21
Switch(config-if)# ip policy route-map TEST
Switch(config-if)# exit
Switch(config-if)# exit
Switch# wri

Вот и все. Таким образом все пакеты приходящие от подсети 10.0.18.0/26 на интерфейс vlan 21 будут «улетать» в правильный канал, а именно канал от пров-2.

Командой Switch# debug ip policy вы можете включить режим, который поможет вам
определить, что делает policy-based routing — попадают ли пакеты под
соответствующие правила и информацию о маршрутизации пакета.

---

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

---

Посмотреть содержание маршрутной карты можно командой:
Switch# show route-map TEST

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Jabber ( болтовня, трёп) — система для быстрого обмена сообщениями и информацией о присутствии (в контакт-листе) между любыми двумя пользователями Интернета на основе открытого протокола XMPP.
В наше время, стал очень распространён протокол обмена сообщениями — Jabber. Сейчас я расскажу, как установить собственный Jabber-сервер на FreeBSD при помощи OpenFire.

Итак, поехали…

1. Для начала устанавливаем из портов сервер OpenFire:

cd /usr/ports/net-im/openfire
make install clean

Если в процессе инсталляции программа установки попросит Вас загрузить дополнительное ПО — загрузите, иначе, программа может начать работать неправильно или не будет работать вообще.

2. Подготовка:

Если инсталляция прошла успешно (а она должна пройти успешно), смело приступайте к запуску сервера:
Для начала нужно добавить следующую строку в /etc/rc.conf:

openfire_enable=”YES”

3. Запускаем:

/usr/local/etc/rc.d/wildfire start

Затем проверяем, загрузился ли он:

/usr/local/etc/rc.d/wildfire status
The daemon is running.

Если всё нормально, открывайте браузер и соединяйтесь с сервером (если он не локальный, на его внешний IP-адрес) на порт 9090, или подключаемся 127.0.0.1:9090 (если он локальный).
Находим строку «Domain» и вводим имя домена, на котором будет располагаться Jabber-сервер (можно ввести IP-адрес вашего сервера)
В качестве СУБД выбираем «Embedded DataBase» (хотя можно установить и выбрать другую СУБД)
Раз всё закончено жмём «Continue» и вводим пароль администратора Jabber-сервера.

4. Добавляем пользователей:

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

Для начала переходим по ссылке «Registration & Login», тут нужно выбрать могут или нет пользователи самостоятельно создавать аккаунты. Для добавления пользователей переходим в раздел «Users/Group». Для создания нового пользователя щёлкаем по «Create New User». Для создания новой группы щёлкаем по «Create New Group».

Ну думаю всё основное уже ясно. Удачи.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: souriz

Вступление

Как известно, в ОС FreeBSD бывают пользователи двух типов: суперпользователи (администраторы) и обычные. Обычные пользователи могут выполнять команды, у которых установлен соответствующий бит исполнения. Но могут возникнуть ситуации, когда нужно пользователю дать право на выполнение только определенных команд (в нашем примере — должна быть доступна только команда ifconfig без аргументов), исключив выполнение всех остальных.

Решение

Как обычно, решение достаточно простое: в качестве оболочки пользователю задается bash в режиме ограничения и используется команда sudo для выполнения разрешенных команд.

1. Ставим из дерева портов sudo:

cd /usr/ports/security/sudo

make install clean

Правим конфигурационный файл /usr/local/etc/sudoers:

root ALL=(ALL) ALL # означает что все команды будут выполняться от пользователя root.

#Далее создается набор команд под названием TP: следует перечисление через запятую сначала

#всех запрещенных каталогов и программ, а затем всех допустимых комманд с полным путем.

#Если команда написана как /usr/local/bin/nmap, то это означает что ее разрешено запускать c любыми

#аргументами. Если же после команды стоят символы «», то это означает что команду не разрешено

#запускать с аргументами. /sbin/ifconfig tun[0-9]* * — разрешает запускать команду ifconfig с

#аргументами tunX, где X любое число от 0 до бесконечности, плюс любой аргумент после.

#/usr/bin/tail -[fFn] /var/log/* — также разрешает запускать tail с любым из аргументов, указанных в скобках

#и указать файл из каталога /var/log/.

Cmnd_Alias TP=!/bin/,!/sbin/,!/usr/bin/,!/usr/sbin/,!/usr/local/bin/,!/usr/local/sbin/,/sbin/ifconfig «»

user ALL=(ALL) NOPASSWD: TP # разрешает выполнять комманды из списка TP только пользователю с именем user,

# без ввода пароля root’а

2. Ставим из дерева портов bash:

cd /usr/ports/shells/bash

make install clean

3. Создаем домашний каталог для пользователя user:

mkdir -p /usr/home/user

4. Настраиваем bash:

Создаем в домашнем каталоге пользователя user профайл bash с именем .bash_profile следущего содержания:

PATH=/usr/home/user; export PATH #Оставляем в путях только каталог пользователя user
alias ifconfig=»sudo /sbin/ifconfig» #Здесь делаем доступные команды для user «прозрачными»

5. Создаем в домашнем каталоге пользователя user файл с названием bash следущего содержания:

#!/bin/sh /usr/local/bin/bash —rcfile /usr/home/user/.bash_profile -r # Запускать bash в ограниченном режиме

#(ключ -r) c указанием файла с начальными настроками (—rcfile /usr/home/user/.bash_profile)

6. Создаем пользователя с именем user:

pw adduser user -g nogroup -d /usr/home/user -s /usr/home/user/bash

7. Задаем ему пароль:

passwd user

8. Безопасность. Действия совершаются во избежание записи чего-либо пользователем user в свой каталог (для дальнейшего возможного повышения привелегий :)) :

Меняем владельца/группу каталога пользователя user на user:nobody:

chown -R user:nogroup /usr/home/user

Профайл bash оставляем за root’ом:

chown root:wheel /usr/home/user/.bash_profile

Выставляем права:

сhmod -R 400 /usr/home/user #устанавливаем на всё права «только чтение только для владельца»

сhmod 500 /usr/home/user #устанавливаем на каталог бит «х» для возможности владельцу войти в него

сhmod 500 /usr/home/user/bash #для запуска нашего «модифицированного» баша

Профайл bash доступен для чтения всем:

chmod 444 /usr/home/user/.bash_profile

9. Делаем символическую ссылку на sudo в домашнем каталоге пользователя user:

ln -s /usr/local/bin/sudo /usr/home/user

Листинг домашнего каталога пользователя user выглядит, примерно, так:
-r—r—r— 1 root wheel 122 Sep 2 22:42 .bash_profile
-r-x—— 1 user nogroup 73 Sep 2 22:39 bash
lrwxr-xr-x 1 root nogroup19 Sep 2 22:42 sudo -> /usr/local/bin/sudo

Все, пользователь user ограничен в действиях: ему доступна только команда ifconfig и без параметров.

При попытке запуска других исполняемых файлов, пользователь user получит следующее сообщение:

ls
bash: ls: command not found
/bin/ls
bash: /bin/ls: restricted: cannot specify `/’ in command names
sudo /bin/ls
Sorry, user user is not allowed to execute ‘/bin/ls’ as root on subnets.ru.

При запуске разрешенных команд идет логирование в /var/log/messages:

Sep 8 16:53:37 subnets.ru sudo: user : TTY=ttyp3 ; PWD=/usr/home/user ; USER=root ; COMMAND=/sbin/ifconfig

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Авторы: TheFeaR, ace, Панфилов Алексей (lehis (at) subnets.ru)

З.Ы.Ы.  Хорошая статейка на тему sudo:

Как обойтись без прав root.

Майкл Лукас (перевод Станислава Лапшанского)
Оригинал статьи находится по адресу: http://www.onlamp.com/pub/a/bsd/2002/08/29/Big_Scary_Daemons.html

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

Утилита sudo является программой-посредником с установленным битом setuid, выполняющейся с привилегиями суперпользователя. Она позволяет установить гибкие правила доступа к программам, для запуска которых требуются административные полномочия. sudo получает от пользователя команду, затем сравнивает ее с внутренним списков разрешенных команд. Если пользователь имеет право на исполнение поданной команды, sudo немедленно ее выполняет. Поскольку суперпользователь может запускать программы от имени любого пользователя, sudo так же может выполнять команды от имени какого угодно наперед заданного пользователя.

При соответствующей настройке, системный администратор может позволить любому пользователю выполнять любые программы от имени любого другого пользователя. sudo очень мощная утилита, с ее помощью можно разрешить или запретить практически любой набор команд. Как результат такой гибкости, документация sudo, отпугивает новичков своей сложностью. Мы займемся конфигурированием sudo, на уровне, которого вполне должно хватить для большинства пользователей, однако вам следует помнить, что существует большое количество различных дополнительных параметров конфигурирования, которые описаны в руководстве sudo (8) и sudoers (5).

Преимущества от использования sudo не ограничиваются предоставлением четкой системы разграничения доступа. Одним из важнейших преимуществ является журналирование выполняемых пользователями команд. Каждая команда выполняемая sudo, записывается в журнал, что чрезвычайно упрощает выяснение того, кто, что и когда изменял. Кроме того, когда вы корректно настроите sudo, вы наконец сможете поменять суперпользовательский пароль и никогда больше никому его не давать. Более того, если вы все правильно настроите, то суперпользовательский пароль вообще никому не потребуется. Сокращение количества людей, знающих пароль суперпользователя ведет к увеличению защищенности вашей системы. И наконец, один и тот же конфигурационный файл программы sudo может применяться на всех ваших серверах, тем самым значительно сокращая временные затраты на администрирование системы.

Наиболее серьезным недостатком sudo является, чрезвычайно негативное отношение к ней пользователей и младших администраторов. Так как люди традиционно пользовались суперпользовательским паролем для выполнения своих действий, они подозревают, что при установке в систему sudo они потеряют некоторые прежде доступные им возможности. Для преодоления такого отношения к sudo, вы, в первую очередь должны будете удостовериться, что пользователи с ее помощью смогут выполнять свою работу в полном объеме. Если пользователи уверяют вас, что им требуется суперпользовательский пароль для выполнения других задач, то вы должны просто разобраться кто и за что отвечает. Вероятно такие пользователи брали на себя решение несвойственных им задач, вместо того, что бы озаботить ими вас.

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

Система sudo состоит из трех частей. Во-первых, это сама программа sudo (8) – программа-посредник с установленным setuid-битом, с которой непосредственно взаимодействуют пользователи. Во-вторых это конфигурационный файл sudo /etc/sudoers. Этот файл содержит таблицу прав доступа, в которой указывается кому и какие команды позволено запускать от имени какого пользователя. Его структура полностью описана в руководстве man 5 sudoers. И наконец команда visudo, которая позволяет администраторам редактировать файл sudoers без риска заблокировать себе вход в систему. Мы рассмотрим каждый компонент по очереди: visudo, sudoers и sudo.

Если файл sudoers имеет неправильный синтаксис, sudo просто не запустится. Если вы понадеетесь на sudo (имеется в виду случай, когда вы полностью отказались от использования суперпользовательского аккаунта забыв его пароль – прим. переводчика), предоставите через него доступ к файлу sudoers и при этом это файл испортите, то вы тем самым заблокируете доступ к любым действиям требующим прав суперпользователя и, к тому же, не сможете ничего исправить. Это плохо. Программа visudo (8) призвана обеспечить определенную защиту от подобных ситуаций.

Подобно утилите vipw (8), visudo (8) блокирует редактируемый файл для того чтобы в один момент времени его мог редактировать только одни человек. visudo открывает конфигурационный файл sudoers в редакторе (по умолчанию это редактор vi (1), однако такое поведение системы можно изменить, поменяв содержимое переменной $EDITOR). Когда вы покидаете редактор, visudo проверяет отредактированный файл на наличие синтаксических ошибок, о которых сообщает пользователю. Разумеется такая проверка не дает гарантии того, что конфигурационный файл будет таким как вы хотите, она просто подтверждает его синтаксическую корректность. Например утилита visudo (8) не моргнув глазом примет конфигурационный файл, в котором никто при помощи sudo сможет сделать ничего, если этот файл имеет правильный синтаксис.

Если программа visudo найдет в отредактированном файле ошибку, она выдаст на терминал номер строки в которой встретилась ошибка и спросит вас, что теперь делать:
# visudo
>>> sudoers file: syntax error, line 44 <<<
What now?

В данном случае в 44 строке мы допустили ошибку. Есть три варианта действий: вернуться к редактированию, выйти не сохраняя сделанных изменений или заставить visudo сохранить файл sudoers, несмотря на найденные ошибки.

При нажатии клавиши e, visudo вернет вас в режим редактирования, где вы сможете попытаться исправить обнаруженную ошибку.

Если нажать на x, visudo завершится и возвратит конфигурационный файл в состояние, в котором он был до начала редактирования. Сделанные вами изменения будут потеряны, но возможно это именно то, что нужно в такой ситуации, поскольку лучше иметь старую, но работающую конфигурацию, чем новую, но неработоспособную.

Клавиша Q заставит visudo принять сделанные изменения, несмотря на найденную ошибку. Не забывайте, что если конфигурационный файл содержит ошибку, sudo не запустится. Делая это, вы, в сущности, на некоторое время выключаете sudo, до тех пор, пока вы не отредактируете конфигурацию под аккаунтом суперпользователя. В подавляющем большинстве случаев это не то что вам нужно.

Файл sudoers сообщает sudo, кто может выполнять какие команды и от какого пользователя. OpenBSD хранит файл sudoers в каталоге /etc, а FreeBSD в каталоге /usr/local/etc. Никогда не редактируйте этот файл напрямую, даже если вы уверены, что точно знаете, что именно вы хотите изменить. Всегда используйте visudo.

При первом конфигурировании sudo вам может быть вам непонятен синтаксис таблицы прав доступа. Возможно, что сразу сделать все правильно вам не удастся. Однако как только вы поймете каким образом sudo устанавливает эти правила, все станет легко и просто.

Разнообразные примеры файлов sudoers, которые вы можете легко найти в Интернете, часто бывают слишком сложны и запутаны для понимания, но в них можно увидеть все интересные штучки которые предоставляет пользователю sudo. Однако базовый синтаксис очень прост. Каждая запись правил доступа в файле sudoers имеет следующий формат:
username host = command

Где username это имя пользователя, который может выполнять команду. Параметр host представляет собой имя машины, для которой применимо соответствующее правило. Таким образом есть возможность устанавливать правила для конкретной машины в сети.

В поле command содержится список команд для которых применимо данное правило.

Вы должны указать полный путь для каждой команды, или sudo не будет их распознавать. (Вы ведь не хотите, что бы пользователи могли, просто поменяв переменную $PATH, выполнять совсем другие команды с теми же именами?)

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

Вы можете использовать ключевое слово ALL в любом из трех полей для указания значения подходящего для всего. Например, предположим, что я полностью доверяю пользователю chris и хочу позволить ему выполнять абсолютно любую команду от имени суперпользователя на любой машине:
chris ALL = ALL

Однако давать младшему администратору полный контроль над одной из моих машин не очень разумно. Как главный администратор, я должен знать, какие команды понадобятся Крису для выполнения его работы. Предположим, что Крис администрирует DNS-сервер. К файлам, описывающим зоны сервера имен, доступ ограничивается при помощи групп, но они не смогут нам помочь, когда понадобится стартовать, перезапустить или остановить сервер. Вот как я дал ему права на запуск программы контролирующей демона DNS-сервера:
chris ALL = /usr/sbin/ndc

Если я распространю этот файл на несколько машин, есть высокая вероятность, что далеко не на всех из них окажется сервер имен. Вот так я ограничиваю круг машин, на которых Крис сможет запускать управляющую программу, одним компьютером с именем dns1:
chris dns1 = /usr/bin/ndc

С другой стороны, Крис является еще и администратором машины почтового сервера mail. Он полностью отвечает за этот сервер, и, поэтому может выполнять на нем любые команды, как ему заблагорассудится. Я могу установить для него совершенно другие права доступа к почтовому серверу и, несмотря на это, использовать один и тот же файл sudoers на обеих машинах:
chris dns1 = /usr/bin/ndc
chris mail = ALL

Для того что бы указать несколько значений в одном поле, их можно разделять запятыми. Вот как можно разрешить Крису монтировать гибкий диск при помощи команды mount (8) и одновременно позволить управление сервером имен:
chris dns1 = /usr/bin/ndc, /bin/mount

В файле sudoers, вы можете указать sudo, что ей необходимо выполнять определенные команды от пользователя отличного от root. Для этого вставьте имя нужного пользователя в скобках перед командой. Допустим, что наш сервер имен выполняется не от имени суперпользователя, а от имени пользователя named и все команды для управления им должны запускаться от имени этого пользователя.
chris dns1 = (named) /usr/bin/ndc

Каждая запись в файле /etc/sudoers должна занимать одну строку. В связи с этим строки могут быть непомерно длинными. В таком случае вы можете перенести строку на другую воспользовавшись символом \ в конце строки:
chris server1 = /sbin/fdisk,/sbin/fsck,/sbin/kldload, \ /sbin/newfs,/sbin/newfs_msdos,/sbin/mount

Теперь, когда вы ознакомились, как задаются правила доступа, давайте поглядим, как использовать sudo. Воспользуйтесь visudo, и разрешите своему аккаунту выполнять любую команду. (Если вы смогли установить sudo, значит вы уже обладаете правами суперпользователя и, поэтому то, что вы дали своему аккаунту неограниченные привилегии, не будет дырой в безопасности).

При запуске sudo, во-первых она спросит вас пароль. Введите пароль своего аккаунта (не пароль суперпользователя). Если вы неправильно введете пароль, sudo оскорбит ваши умственные способности или родословную, и предложит ввести пароль еще раз. После третьего раза, sudo отвяжется от вас. Если вы хотите попытаться еще, запустите sudo снова.

Как только вы введете правильный пароль, sudo засечет время. Если вы попытаетесь запустить sudo в течение следующих пяти минут, она не будет запрашивать пароль. После истечения пяти минут, пароль придется вводить как обычно. Это делает жизнь проще в случае, если вам необходимо выполнить сразу несколько команд при помощи sudo, однако помните, что если вы отлучитесь от компьютера пять минут пройдут достаточно быстро.

Если вы простой пользователь и на вашей машине установлена sudo, то весьма вероятно, что вам будет интересен список команд, которые системный администратор счел допустимыми для выполнения вами при помощи sudo. Для вывода этого списка вам пригодится ключ -l:
$ sudo -l
Password:
User mwlucas may run the following commands on this host:
(root) ALL

Если у вас более серьезные ограничения чем у меня, все они будут выведены на экран.

Для того что бы выполнить команду при помощи sudo, просто поставьте перед ней слово sudo. Например, вот как можно выполнить команду su при помощи sudo:
$ sudo su
Password:

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

При помощи sudo вы, так же можете запускать и более сложные команды передавая им все необходимые аргументы. Например, команда tail -f прекрасно подходит для просмотра последних сообщений в файле журнала, кроме того, новые записи будут появляться на экране по мере их появления в файле журнала. Просмотр некоторых файлов журналов доступен только для суперпользователя. Журнал программы sudo является отличной кандидатурой на такую роль. Наверняка вы хотите иметь возможность просмотра журналов без необходимости входить под аккаунтом суперпользователя.
$ sudo tail -f /var/log/authlog
openbsd/usr/src/usr.bin/sudo;sudo tail -f /var/log/secure
Jul 29 13:24:19 openbsd sudo: mwlucas : TTY=ttyp0 ;
PWD=/home/mwlucas ; USER=root ; COMMAND=list
Jul 29 13:30:03 openbsd sudo: mwlucas : TTY=ttyp0 ;
PWD=/home/mwlucas ; USER=root ;
COMMAND=/usr/bin/tail -f /var/log/authlog
…

Если вы обладаете достаточными правами, то вы сможете запускать программы не только от имени суперпользователя, но и от имени любого другого пользователя. Предположим, например, что у нас есть сервер баз данных, для работы с которым команды надо отдавать от имени пользователя под которым выполняется этот сервер. Вы можете указать необходимого пользователя в ключе -u. Например оператор базы данных имеет привилегии для выполнения программы dump, используемой для резервного копирования:
$ sudo -u operator dump /dev/sd0s1

Все это замечательно, но как проконтролировать использование sudo?

Сообщения от sudo журналируются в источник LOCAL2. Каждое сообщение содержит время его записи, имя пользователя, каталог, где запускалась sudo и команду, которая была выполнена.
Jul 29 11:21:02 openbsd sudo: chris : TTY=ttyp0 ;
PWD=/home/chris ; USER=root ;
COMMAND=/sbin/mount /dev/fd0 /mnt

При худшем варианте развития событий (если в системе что-то нарушится), вы сможете отследить, что происходило. Например, если одна из моих машин не можеhrкорректно перезагрузиться из-за того, что файл /etc/rc.conf испорчен или отсутствует, я могу проверить журнал sudo на предмет операций с этим файлом:
Jul 29 11:34:56 openbsd sudo: chris : TTY=ttyp0 ;
PWD=/home/chris ; USER=root ;
COMMAND=/bin/rm /etc/rc.conf

Если кто-нибудь для запуска команд, воспользовался бы командой su или даже sudo su вместо sudo, я не смог бы увидеть что привело к сбою системы.

С журналами sudo я всегда могу выяснить кто виноват, как только доберусь до компьютера. Только из-за одного этого sudo стоит установить!

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

Говоря по-русски, псевдоним — это просто группа пользователей, хостов или команд. Если служебные обязанности пользователя меняются, то для придания ему необходимых полномочий, вам следует просто добавить его в описание того или иного псевдонима. Для того что бы ваши системные операторы по прежнему могли делать резервное копирование, но при этом не имея полномочий для восстановления данных, вам придется всего лишь удалить из их псевдонима восстанавливающие команды. Когда вы запустите в эксплуатацию новый сервер, добавление имени этого сервера в соответствующий псевдоним позволит вам незамедлительно дать администраторам системы права, необходимые им для выполнения их работы.

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

Пользовательский псевдоним описывает группу пользователей. Объявление пользовательского псевдонима начинается с метки User_Alias. Как нетрудно догадаться, пользовательский псевдоним содержит в себе список пользователей. Описанный в данном примере пользовательский псевдоним DNSADMINS, содержит двух пользователей mwlucas и chris:
User_Alias DNSADMINS = chris,mwlucas

Псевдоним Runas является специальным псевдонимом. Он определяет список пользователей от имени которых другие пользователи могут запускать свои команды.

Многие серверы имен могут выполняться от имени пользователя named. Очевидно, что администратору DNS-сервера может понадобиться запускать команды от имени этого пользователя, следовательно, вы можете определить для него Runas-псевдоним. Многие приложения в составе серверов баз данных выполняются под своим собственным пользователем. Во многих случаях системный администратор, отвечающий за эксплуатацию приложения захочет иметь возможность выполнять резервное копирование от имени пользователя operator. Вы можете создать один Runas-псевдоним для группы таких команд. Псевдоним Runas начинается с метки Runas_Alias.
Runas_Alias APPADMIN = named,dbuser,operator

«Хостовой» псевдоним является просто списком сетевых хостов. Признаком хостового псевдонима является метка Host_Alias. В списке хостов могут присутствовать DNS-имена машин, IP-адреса и адреса сетей. (Помните, что если вы используете DNS-имена, то ваша sudo-конфигурация будет подвержена уязвимостям связанным с системой DNS). Вот примеры записей со всеми тремя типами адресов:
Host_Alias DNSSERVERS = dns1,dns2,dns3
Host_Alias SECURITYSERVERS = 192.168.1.254,192.168.113.254
Host_Alias COMPANYNETWORK = 192.168.1.0/16

Командный псевдоним состоит из списка команд операционной системы. Он начинается с метки Cmnd_Alias. Запишем псевдоним, который будет объединять команды необходимые для резервного копирования и восстановления данных:
Cmnd_Alias BACKUPS = /bin/mt,/sbin/restore,/sbin/dump

Вы можете создать псевдоним, который будет объединять все команды в определенном каталоге. Предположим, что у нас есть некое приложение, которое выполняется от имени определенного пользователя, кроме того, все утилиты этого приложения находятся в домашнем каталоге этого пользователя. Вместо того, что бы указывать в псевдониме все эти команды по очереди, мы можем указать только полный путь к каталогу и образец имени файла, подходящий под все содержимое этого каталога:
Cmnd_Alias DBCOMMANDS = /usr/home/dbuser/bin/*

Для того что бы воспользоваться созданным псевдонимом просто подставьте его имя туда, куда вы обычно пишете имя пользователя, машины или команды соответственно. Выше мы определили пользовательский псевдоним DNSADMINS. Пусть пользователи упомянутые в этом псевдониме имеют право выполнять любые команды на любых серверах:
DNSADMINS ALL = ALL

Давайте предположим что пользователь Фил (Phil) управляет приложением, которое выполняется от имени определенного пользователя. Он может выполнить любую команду на сервере от имени этого пользователя. Воспользуемся ранее определенным Runas-псевдоним APPADMIN и командным псевдонимом DBCOMMANDS, включающим в себя необходимые команды.
phil ALL = (APPADMIN)DBCOMMANDS

Филу требуется делать резервное копирование данных его приложения. Мы уже упомянули пользователя operator в псевдониме APPOWNER (судя по всему автор просто забыл вставить абзац с определением псевдонима APPOWNER, однако его нетрудно восстановить: Runas_Alias APPOWNER = dbuser,operator – прим. переводчика), и описали командный псевдоним BACKUPS для осуществления резервного копирования. Скомбинируем их:
phil ALL = (APPOWNER) DBCOMMANDS, (APPOWNER) BACKUPS

Это выглядит куда проще «развернутой» записи, которую пришлось бы писать не будь у sudo конструкции псевдонимов.
phil ALL = (dbuser,operator)/usr/home/dbuser/bin/*,
(dbuser,operator)/bin/mt, (dbuser,operator)/sbin/restore,
(dbuser,operator)/sbin/dump

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

Имеется возможность использовать вложенные псевдонимы. Например вы хотите объединить псевдонимы DBCOMMANDS и BACKUPS в один общий псевдоним. Разумеется объединяемые псевдонимы уже должны быть описаны перед объединением.
Cmnd_Alias DBADMINS = BACKUPS,DBCOMMANDS

sudo умеет брать информацию о группах пользователей определенных в операционной системе и использовать ее в качестве псевдонимов в файле sudoers. Вместо того, что бы определять пользовательский псевдоним вы можете просто взять имя группы пользователей и использовать его, поставив впереди значок процента %, для того, что бы показать, что это именно имя группы.
%wheel ALL = ALL

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

Вы можете использовать имена псевдонимов повторно. Пользовательский псевдоним DBADMINS это совсем не то же самое что командный псевдоним DBADMINS. Это вполне позволяет делать следующие записи в файле sudoers.
Cmnd_Alias DBAPP = /usr/home/dbuser/bin/*
Host_Alias DBAPP = server8,server12,server15
RunasAlias DBAPP = dbuser,operator
User_Alias DBAPP = chris,mwlucas
DBAPP DBAPP = (DBAPP) DBAPP

Это отличный пример «технически возможного, но совершенно аморального» (имеется в виду сакраментальная фраза, характеризующая текущую точку зрения на вопрос клонирования человека – прим. переводчика). Если вы будете пользоваться этой возможностью, то кто-нибудь посторонний, кому придется разбираться в такой конфигурации, обязательно помянет вас кратким обидным словом (более того, если через некоторое время вам придется вернуться к конфигурации sudo, вы сами будете рвать на себе волосы – прим. переводчика). Кроме того, подобные вещи обычно приводят к телефонным звонкам в середине того краткого времени, которое отводит на свой сон главный администратор.

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

Во-первых определим командный псевдоним, в котором будут описаны запрещенные команды. Часто запрещаются оболочки командных интерпретаторов (поскольку если вы можете выполнить оболочку от имени определенного пользователя, то вы можете делать все под именем этого пользователя) и команда su (1). А теперь давайте запретим вашему пользователю использовать команды описанные этим псевдонимом при помощи модификатора !:
Cmnd_Alias SHELLS = /bin/sh,/bin/csh,/usr/local/bin/tcsh
Cmnd_Alias SU = /usr/bin/su
mwlucas ALL = ALL,!SHELLS,!SU

Выглядит замечательно, не правда ли? Поглядим, как это работает:
$ sudo sh
Password:
Sorry, user mwlucas is not allowed
to execute ‘/bin/sh’ as root on openbsd.

Вспомните, sudo использует полные пути для описания команд. Вы позволили пользователю запускать любую требующуюся ему команду, кроме нескольких запрещенных, описанных полными именами. Все что требуется пользователю для запуска запрещенных команд, это сменить путь к их файлам. Простейшим средством для реализации этой затеи будет простое копирование файлов в необходимое место.
$ id
uid=1000(mwlucas) gid=1000(mwlucas) groups=1000(mwlucas), 0(wheel)
$ cp /bin/sh .
$ sudo ./sh
$ id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys),
4(tty), 5(operator), 20(staff), 31(guest)

Привет, root!

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

Если у вас есть пользователи, которым вы не можете доверить неограниченный доступ к системе, не пользуйтесь исключением команд при описании их привилегий. Ограничьтесь списком явно разрешенных для выполнения команд. Исключение команд может пригодиться только в случае доверенных пользователей (работников), в качестве напоминания (крайне спорно, на мой взгляд лучше вообще не пользоваться, что бы не вводить «во искушение» – прим. переводчика). Т.е. когда я зайду на машину и напечатаю sudo su, sudo скажем мне, что мне не стоит выполнять здесь такие команды.

Взято тут:  http://citkit.ru/articles/132/