ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архив за Сентябрь, 2008

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

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)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 4,33 из 5)
Загрузка...
Отправить на почту Отправить на почту

CARP — Common Address Redundancy Protocol

Другими словами это протокол избыточности, который позволяет двум или более компьютерам в одной подсети иметь одновременно один и тот же IP адрес, при этом возможна настройка этой группы компьютеров как взаимозаменяемые (главный компьютер отключился/сломался — вместо него сразу же принимается за работу другой, у которого приоритет выше) и так по кругу. Максимально количество компьютеров в группе — 256, в сети между ними не должно быть роутеров.

Также возможна конфигурация данной группы как некий кластер, который будет обрабатывать приходящие пакеты по кругу( 1-2-3-4-5…..256-1-2-3-4), то есть распределяя нагрузку на сервис.

Вариант первый. Резервирование.

1) Необходимо на всех компьютерах группы включить в ядро опцию

device carp

Пересобрать его и установить.

cd /usr/src
make buildkernel KERNCONF=PARANOID #PARANOID — мое название конфигурации ядра.
make installkernel KERNCONF=PARANOID

2) Выставить на каждом компьютере группы опцию sysctl

sysctl net.inet.carp.preempt=1

и добавить в /etc/sysctl.conf # Чтоб при следующей загрузке данный параметр автоматически выставился в 1.

net.inet.carp.preempt=1

Данная опция включает в CARP функцию резервирования.

3) Настроить сетевые карты каждого из группы компьютеров на ОТДЕЛЬНЫЙ ip адрес из одной подсети. ВАЖНО ! Так как можно запутаться и писать на интерфейс сразу у всей группы один и тот-же адрес, что вызовет конфликт адресов.

Например:

PC1 — 10.100.0.1/24
PC2 — 10.100.0.2/24
PC3 — 10.100.0.3/24

4) Создать интерфейс carp, прописать ему ip (именно на этом IP будет висеть ваш сервис), VHID (Идентификатор CRAP группы), и выдать каждому CARP интефейсу на каждом из компьютеров группы свой УНИКАЛЬНЫЙ advskew (приоритет сервера) чем он ниже — тем раньше, в случае сбоя, этот сервер присвоит себе IP и будет обрабатывать запросы, и пароль группы pass (Также должен быть одинаковый в одной группе)

PC1

ifconfig carp0 create

ifconfig carp0 vhid 1 pass VeRySeCrEtPaSsWoRd 10.100.0.4/24 advskew 0

PC2

ifconfig carp0 create

ifconfig carp0 vhid 1 pass VeRySeCrEtPaSsWoRd 10.100.0.4/24 advskew 1

PC3

ifconfig carp0 create

ifconfig carp0 vhid 1 pass VeRySeCrEtPaSsWoRd 10.100.0.4/24 advskew 2

Таким образом получается что если ломается PC1, то тут-же за него начинает работать PC2, если и он ломается, и при этом PC1 все еще не восстановлен, то в работу включается PC3.

Синхронизировать сервера можно по физическим интерфейсам с IP 10.100.0.1-3, но своими силами.

Вариант второй. Распределение нагрузки.

Ядро так-же собираем с поддержкой CARP но в sysctl выставляем значение уже arpbalance в 1

sysctl net.inet.carp.arpbalance=1

и соотвественно в /etc/sysctl.conf

net.inet.carp.arpbalance=1

Как видно из названия обьекта, балансировка происходит на основании MAC-адреса клиентского компьютера, соответственно, роутеров между сервером и клиентом не должно быть.

Затем на каждом из серверов группы надо настроить 2 CARP интерфейса и 1 физический (vlan-ы тоже поддерживаются) с разными vhid (Если на одном РС у этого VHID advskew=100, то на другом РС на этом-же VHID должен быть advskew=0).

PC1

ifconfig em0 10.100.0.1/24

ifconfig carp0 create

ifconfig carp0 vhid 1 pass SeCrEt 10.100.0.2/24 advskew 0

ifconfig carp1 create

ifconfig carp1 vhid 2 pass AnoTheRSeCrEt 10.100.0.2/24 advskew 100

PC2

ifconfig em0 10.100.0.3/24

ifconfig carp0 create

ifconfig carp0 vhid 1 pass SeCrEt 10.100.0.2/24 advskew 100

ifconfig carp1 create

ifconfig carp1 vhid 2 pass AnoTheRSeCrEt 10.100.0.2/24 advskew 0

Теперь при обращении к IP 10.100.0.2 для каждого отдельного физического устройства сервера будут отзываться по очереди. В случае падения одного из серверов отвечать на запросы будет оставшиеся.

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

Автор: Куликов Кирилл (TheFeaR)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 8, среднее: 4,13 из 5)
Загрузка...
Отправить на почту Отправить на почту

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
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 4,33 из 5)
Загрузка...
Отправить на почту Отправить на почту

Вступление

Как известно, в ОС 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/

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 4,33 из 5)
Загрузка...
Отправить на почту Отправить на почту
Уважаемые участники MSK-IX,

MSK-IX планирует провести модернизацию оборудования и программного
обеспечения действующей в сети MSK-IX службы Route Server (RS),
предназначенной для организации пирингового взаимодействия между
участниками MSK-IX http://www.msk-ix.ru/network/routeserver.html.

В результате модернизации RS станет "прозрачным", т.е. участники MSK-IX,
использующие RS, будут получать BGP-анонсы от RS с теми же значениями BGP
атрибутов AS_PATH, Next-Hop и MED, как и при прямом пиринге между собой. В
частности, это означает, что RS не будет удлинять список AS в атрибуте
AS_PATH за счет добавления собственной AS8631.

Если Вы используете службу RS, просим до 10 сентября 2008 года проверить,
что конфигурация Вашего оборудования готова к модернизации.  Проверка
состоит из трех этапов:

1. Удостоверьтесь, что в настройки Вашей пиринговой сессии с RS (AS8631),
внесена команда (для оборудования Cisco, Juniper, Quagga, Zebra и др.)

no bgp enforce-first-as

Данная команда совместима с текущей версией RS.

Если данная команда не поддерживается программным обеспечением Вашего
оборудования, то как правило, никаких изменений не требуется. Обратитесь к
документации для Вашего оборудования, см. например
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_befasp.html.

2. Удостоверьтесь, что пиринговая сессия с AS8631 с Вашей стороны
установлена с обоими роут-серверами сети MSK-IX
http://www.msk-ix.ru/network/routeserver.html.

3. Рекомендуем также проверить загрузку порта в MSK-IX и в случае
необходимости оформить заявку на увеличение пропускной способности.
Сокращение числа AS в атрибуте AS_PATH может привести к росту трафика на
сети, анонсируемые через RS.

Изменения в конфигурации Вашего оборудования рекомендуем произвести *КА�
МОЖНО РАНЬШЕ*. О точной дате и времени модернизации роут-серверов MSK-IX
мы сообщим отдельным письмом.

Контактная информация MSK-IX для вопросов и пожеланий.
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту