Tacacs+ linux autenticando em active directory microsoft

Дополнительные материалы

# cat /etc/tac_plus.conf

key = tackey123

user=user1 {
        default service = permit
        login = des "DWRr6OSzYvMH."
        service = exec {
                priv-lvl = 15
        }
}

user=user2 {
        default service = permit
        login = des "QMN3UmwtTO/GU"
        service = exec {
                priv-lvl = 15
        }
        member = group_restrict
}

acl = acl_restrict {
        permit = 172.16.1.3
        permit = 172.16.1.4
        permit = 172.16.1.5
}

group = group_restrict {
        acl = acl_restrict
}

# cat /usr/local/etc/tac_plus.conf

...
user=user1 {
        default service = permit
        login = des "xxxxxxxxx" 
        service = exec { 
                priv-lvl = 15 
        }
        member=level15
}

group=level15 {
  cmd=enable { permit .* }
  cmd=configure { permit terminal }
#  cmd=cli { permit terminal }
  cmd=radius-server { permit .* }
  cmd=vlan { permit .* }
  cmd=interface { permit .* }
  cmd=ip { permit .* }
  cmd=router { permit .* }
  cmd=network { permit .* }
  cmd=eapol { permit .* }
  cmd=show { permit .* }
  cmd=copy { permit .* }
  cmd=reload { permit .* }
  cmd=end { permit .* }
  cmd=exit { permit .* }
  cmd=logout { permit .* }
  cmd=* { permit .* }
}

# cat /usr/local/etc/tac_plus.conf.example

    # This is example from old version of tac_plus. It will work
    # but config file have new features. I recomend to read
    # /usr/local/share/doc/tac_plus/users_guide

user=fred {
    name = "Fred Flintstone"
    login = des mEX027bHtzTlQ

    # Remember that authorization is also recursive over groups, in
    # the same way that password lookups are recursive. Thus, if you
    # place a user in a group, the daemon will look in the group for
    # authorization parameters if it cannot find them in the user
    # declaration.
    member = admin

    expires = "May 23 2010"

    service = exec {
        # When Fred starts an exec, his connection access list is 5
        acl = 5

        # We require this autocmd to be done at startup
        autocmd = "telnet foo"
    }

    # All commands except telnet 131.108.13.* are denied for Fred
    cmd = telnet {
        # Fred can run the following telnet command
        permit 131\.108\.13\.+

        deny .*
    }

    service = ppp protocol = ip {
        # Fred can run ip over ppp only if he uses one
        # of the following mandatory addresses If he supplies no
        # address, the first one here will be mandated
        addr=131.108.12.11
        addr=131.108.12.12
        addr=131.108.12.13
        addr=131.108.12.14

        # Fred's mandatory input access list number is 101
        inacl=101

        # We will suggest an output access list of 102, but Fred may
        # choose to ignore or override it
        optional outacl=102
    }

    service = slip {
        # Fred can run slip. When he does, he will have to use
        # these mandatory access lists
        inacl=101
        outacl=102
    }

    # set a timeout in the lcp layer of ppp
    service = ppp protocol = lcp {
        timeout = 10
    }
}

user = wilma {
    # Wilma has no password of her own, but she's a group member so
    # she'll use the group password if there is one. Same for her
    # password expiry date
    member = admin
}

group = admin {
    # group members who don't have their own password will be looked
    # up in /etc/passwd
    login = file /etc/passwd

    # group members who have no expiry date set will use this one
    expires = "Jan 1 2038"
}

Permissions

Field Technicians, on the other hand, has a default service = deny parameter which tells the daemon that all other commands except for user EXEC commands are allowed. Having said that, you will need to permit the commands that they’re allowed to use. Service = exec and priv-lvl = 2 allows us to give a higher privilege than an ordinary user. We do not want to give this group a privilege level of 15, meaning the same level as the network engineers. I will not explain all the parameters here since I believe they’re pretty much self-explanatory for an IT professional who knows Cisco IOS.

Managers are given access as well, however, the only privilege EXEC mode allowed is show running-config. Feel free to add more commands necessary for your boss and/or your boss’ boss.

Creating a test user account and the group might be a good idea, so you can test things out that have been added to this configuration. This particular test user will only have a cleartext password.

Configuring TACACS+ in Linux

# rpm -qa | grep tac_plus
tac_plus-F4.0.3.alpha-7
#

Check whether tacacs+ service is running on the linux server;

# service tac_plus status
tac_plus (pid 4367) is running...
#

TACACS uses TCP/UDP on port 49 by default. Check whether the port is on listening state.

# netstat -an | grep :49
tcp        0      0 0.0.0.0:49                  0.0.0.0:*                   LISTEN
#

• Tacacs+ configuration is available in “/etc/tacacs/tac_plus.cfg” file.
• Several debug options are available which can be invoked while re/starting tacacs service.
• Change the “debug” value in startup script file, “/etc/init.d/tac_plus” to any of values from below reference links;
• For example, Using “debug=16” enables all authentication debug messages to store in “/var/log/tac_plus.log” file.

# cat /var/log/tac_plus.log  | grep demo
Sat Aug 28 20:00:44 2010 : login query for 'demo' vty0 from 10.11.131.167 rejected

Task:

Create user named “demo” with password “demo1” in encrypted form. This user should be in enable mode 10 and can execute only “show {ip | privilege | environment}” commands and can ping only to  10.16.x.x network. He should not configure any protocols or execute any other show commands. All commands executed should be accounted. And this user should be timeout after 15 minutes or after 2 minutes idle time-out.

Configurations in tac_plus.cfg file to accomplish above:

key = "sharedpasswd"
# Set up accounting file if enabling accounting on NAS
accounting file = /var/log/tac.log # Accounting information will be in “cat /var/log/tac.log”
user = demo {
        default service = deny
        login = des "vmf2i5weikAFw"   ## created using “tac_pwd –e” command.
        service = exec {
                priv-lvl = 10
                timeout = 15
                idletime = 2
        }
        cmd = show { permit "ip"
                     permit "environment"
                     permit "privilege"
                     deny .* }
        cmd = ping { permit 10\.16\.+\.+
                     deny .* }
 }

Client (Force10 device- in our test) configuration:

Force10#show run aaa  <<  From admin User
!
aaa authentication enable default tacacs+
aaa authentication login default tacacs+
aaa authorization exec default tacacs+
aaa authorization commands 10 default tacacs+
aaa authorization commands 15 default tacacs+
aaa accounting exec default start-stop tacacs+
aaa accounting commands 10 default start-stop tacacs+
aaa accounting commands 15 default start-stop tacacs+

<From ‘demo’ user>

Force10#show chassis

% Error: Command authorization failed.

Force10#show privi

Current privilege level is 10.

Force10#

Accounting information will be saved in “/var/log/tac.log” file:

# cat /var/log/tac.log | tail -1
Sat Aug 28 23:18:35 2010        10.11.131.167   demo    vty0    10.11.131.3     stop    task_id=102     
timezone=UTC  service=shell   priv-lvl=10     cmd=show environment  <cr>
#

References:

Arquivo de configuração do tac_plus.cfg

#!/usr/local/sbin/tac_plusid = spawnd { listen = {port = 49} #…., used by service TACACS spawn = { instances min = 1 instances max = 10 } background = yes}

id = tac_plus { # Broad gull filesaccess log = “>/var/log/tac_plus/access/%Y%m%d.log”accounting log = “>/var/log/tac_plus/acct/%Y%m%d.log”

mavis module = external {setenv LDAP_SERVER_TYPE = “microsoft”setenv LDAP_HOSTS = “ldap://IP_SERVIDOR_AD” setenv LDAP_SCOPE = subsetenv LDAP_BASE = “dc=seu_dominio, dc=local”setenv LDAP_FILTER = “(&(objectclass=user) (sAMAccountName=%s))”setenv LDAP_USER = Usuario_adm@seu_dominio.localsetenv LDAP_PASSWD = XXXXX setenv AD_GROUP_PREFIX = GRUPO-TACACS-setenv REQUIRE_TACACS_GROUP_PREFIX = 1#setenv USE_TLS = 0setenv FLAG_USE_MEMBEROF = 1exec =/usr/local/lib/mavis/mavis_tacplus_ldap.pl}login backend = mavisuser backend = mavispap backend = mavis

host = world { address = 0.0.0.0/0 welcome banner = “” #Crypt password generate by “openssl passwd-1 clear_text_password” enable 15 = crypt CHAVE_DEFINIDA key = “CHAVE_DEFINIDA”}

group = ADMIN {message = “”default service = permitservice = shell {default command = permitdefault attribute = permitset priv-lvl = 15}}

group = OPERACAO {default service = denyservice = shell {set priv-lvl = 15cmd = show {permit .*}cmd = exit {permit .*}cmd = configure {permit terminal}cmd = ip {permit route}cmd = interface {permit .*}cmd = aaa {deny .*}}}}

Configurações de Switch e Roteadores

Switch Catalyst e Roteadores

aaa new-modelaaa group server tacacs+ TACPLUS_GROUPserver IP_SERVIDOR_TACACSaaa authentication login default group TACPLUS_GROUP localaaa authentication login CONSOLE localaaa authentication enable default group TACPLUS_GROUP enableaaa authorization config-commandsaaa authorization exec default group TACPLUS_GROUP localaaa authorization exec CONSOLE localaaa authorization commands 15 default group TACPLUS_GROUP localaaa accounting commands 1 default start-stop group TACPLUS_GROUPaaa accounting commands 15 default start-stop group TACPLUS_GROUPaaa session-id commontacacs-server host IP_SERVIDOR_TACACStacacs-server directed-requesttacacs-server key CHAVE_DEFINIDA_ARQ_CONF

Установка socat в Unix/Linux

socat — инструмент командной строки, который позволяет переадресовывать сокеты c хостовой машины, на клиентскую. Данная утилита устанавливает два потока двунаправленного байта и передает данные между ними.

Утилита socat используется для:

• TCP порт forwarder-а.
• Тестирование безопасности.
• Shell интерфейс для UNIX-сокетов.
• Реле IP6.
• Для перенаправления TCP-ориентированных программ на последовательную линию.
• Логически подключать последовательные линии на разных компьютерах.
• Устанавливает относительно безопасную среду (su и chroot) для запуска bash скриптов клиента или сервера с сетевыми подключениями.

Установка socat в Debian/Ubuntu

Выполняем установку:

# apt-get install socat -y

Для удаления socat используется следующая команда:

# apt-get remove socat

Следующая команда используется для удаления пакета socat вместе со своими зависимостями:

# apt-get remove --auto-remove socat

Это позволит удалить socat и все его зависимые пакеты, которые больше не нужны в системе.

Полностью удалить socat со всеми конфигурационными файлами можно одним из следующих способов:

Следующая команда должна использоваться с осторожностью, поскольку она удаляет все файлы конфигурации и данные:
# apt-get purge socat

или вы также можете использовать следующую команду:
# apt-get purge —auto-remove socat

Выше команда удалит все файлы конфигурации и данные, связанные с пакетом socat. Можно переходить к использованию.

Выполняем установку:

# yum install socat -y

Можно переходить к использованию.

Установка socat в MacOS X

Для начала, у становим homebrew, я описывал процесс в статье — Установка homebrew на Mac OS X и после чего, выполняем поиск пакета:

$ brew search socat

Ну, теперь можно и поставить ПО следующим образом:

$ brew install socat

Можно переходить к использованию.

Ключи запуска

tac_plus

• -C
  имя-конфигурационного-файла
• -t (выдавать журнал на консоль)
• -P (проверить
  правильность
  синтаксиса файла
  конфигурации)
• -g (отладочный режим — без
  порождения подзадач)
• -p tcp-порт (по умолчанию — 49)
• -d
  уровень-отладки (в /var/tmp/tac_plus.log)
• -v (напечатать версию и выйти)
• -s (не отвечать на sendpass — старый менее
  безопасный протокол -, а только sendauth)
• -L (получать имена по DNS)
• -l файл-журнал
• -w
  файл-для-записи-who-журнала (для maxsess, по
  умолчанию — /var/tmp/tac.who_log)
• -u wtmp-файл
  (регистрация
  пользователей с помощью wtmp вместо
  стандартного учетного файла tacacs+)
• -i (запуск через inetd)

Сигналы:

USR1 — перечитать
конфигурационный файл (ошибка в новой
конфигурации убъет демон)

Использует syslog (LOG_LOCAL6).
Отладочная печать в него не
выдается.

Местные особенности (устарело)

Подсчет времени, который затратил каждый
пользователь на PPP

TACACS сервер заносит в свою
базу
данных (при нынешней
конфигурации) запись о каждом конце сеанса PPP
пользователя:

1. время (5 полей);
2. имя
   терминального сервера;
3. имя
   пользователя;
4. номер порта на
   терминальном сервере;
5. async;
6. stop (это и есть признак конца сеанса);
7. ключевые параметры, среди которых есть:
   • service=PPP
   • elapsed_time=
   • количество
     входных/выходных
     байт/пакетов

процедура
извлекает из этой базы данных все записи за
последние 86400 секунд (сутки) и
суммирует
потраченное каждым
пользователем время.

Структура
нашего
конфигурационного файла

наш
конфигурационный файл
изготавливается из
состоит из трех
частей:

1. заголовка, в котором указан ключ
   шифрования, имя
   файла
   статистики и описание
   пользователя bbs из группы telnet с
   паролем bbs (для demo
   пользователей).
2. для каждого платного
   пользователя два имени входа (, -ppp
   ) с паролем, взятым из базы
   пользователей WorldGroup. Первое имя из
   группы telnet, второе из группы ppp.
3. Описание групп:
   telnet
   (автокоманда telnet 194.84.39.28 23 и с
   правами только на эту команду) и
   ppp
   (автокоманда ppp default и
   соответствующие права).

Запуск tacacs
сервера

crontab
пользователя bog содержит строчку, каждый час
запускающую
tacacs_reload.sh,
которая либо запускает tacacs_сервер (если он не был
запущен ранее) с
или извещает
запущенный ранее сервер о
необходимости заново
прочитать
конфигурационный файл.

Учет времени
использования каждого модема.

С помощью
процедуры
из учетной базы данных TACACS сервера
извлекаются данные за
последние сутки,
сортируются и
суммируется траффик (в КБ) и время (в
минутах) по ключу .

Общее

В ААА последняя буква — это accounting. Лучше заранее подумать, куда будем складывать информацию о том, кто, когда и куда получил доступ и какие действия на оборудовании были выполнены. Если разворачиваете новый сервер, то лучше использовать LVM для распределения места на диске, сможете быстро менять размер томов при нехватке места. Вообще, для серверов, которые постоянно создают какие-то данные, лучше держать LVM и предусмотреть ротацию этих данных.

Мы будем складывать данные аккаунтинга на наш локальный сервер (хотя можно, например, в syslog, а можно в базу данных, а затем на мониторинг, но об этом попозже). Используем обычные разделы, выделим и примонтируем отдельный раздел для аккаунтинга и настроим ротацию создаваемых логов:

• Выделим место (например, в вашей vmware)
• Проверим на сервере (далее все команды будем выполнять из по root):

смотрим на строчку, где видим общее кол-во Gb на диске:

(я выделил 16Gb для / и 34Gb для остального)

Создадим из этих 34GB новый primary-раздел и отфоматируем в журналируемую ext4: fdisk /dev/sda (можно использовать более простой cfdisk /dev/sda)

m — вызвать справку по командам fdisk

n — создать новый раздел (создаем sda3 на все 34Gb) Раздел создали, теперь форматируем в ext4:

Отформатировали, теперь примонтируем: создаем директорию для аккаунтинга:

добавляем строчку:

Теперь настроим ротацию с помощью logrotate:

1) установим утилиту:

2) создадем новый конфигурационный файл для ротации в /etc/logrotate.d/. Этот файл уже будет выполняться ежедневно по cron:

Внесем настройки:

— выполнять ротацию ежедневно.

— не выдавать ошибки, если отсутствуют файлы для ротации

— кол-во логов, которые оставляем после каждой ротации

Т.е. будем ежедневно проверять содержимое директорий, оставлять последние 365 файлов, остальные удалять. У Logrotate много параметров, и утилиту можно использовать не только для логов:

Для чего нужен AAA

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

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

Простым языком принцип ААА можно описать так: для совершения какого-либо действия в сети мы должны проследить, кто инициирует это действие (authentication), имеет ли он право на выполнение этого действия (authorization) и что в журнал записаны все действия, которые он совершил (аccounting).

Есть два основных типа AAA для сетей:

• Администрирование сетевых устройств. Осуществляет управление теми, у кого есть доступ для входа в консоль сетевого устройства, Telnet-сессии, Secure Shell (SSH-сессии) или другим способом.
• Доступ к сети. Идентификация пользователя или устройства до того, как ему будет предоставлен доступ к сети.

В современных сетях используют два основных решения для AAA: Remote Authentication Dial-In User Service (RADIUS) и Cisco’s Terminal Access Controller Access-Control System Plus (TACACS+) протоколы. Существует еще и третий AAA-протокол, известный как DIAMETER, но он обычно используется только мобильными операторами. Мы рассмотрим и сравним RADIUS и TACACS+, чтобы помочь вам определить, какой из них лучше подходит для вашей сети.

Authorization AV pairs

The following authorization AV pairs specify which service is
being authorized and are typically accompanied by protocol AV pairs
and other, additional pairs from the lists below. (For a complete
and current list of supported AV pairs and required IOS releases
search http://www.cisco.com/ for «TACACS+ Attribute-Value
Pairs».)

• service=arap

• service=shell

  Used for exec startup, and also for command authorizations.

• service=ppp

• service=slip

• service=system

  Not used

• service=raccess

  Used for managing reverse telnet connections, e.g.:

  user = jim {
  login = clear lab
      service = raccess {
          set port#1 = nasname1/tty2
          set port#2 = nasname2/tty5
      }
  }

  Requires IOS configuration:

  aaa authorization reverse-access default group tacacs+ 

  See the IOS docs for more details.

• protocol=lcp

  The lower layer of PPP, always brought up before IP, IPX, etc.
  is brought up.

• protocol=ip

  Used with service=ppp and service=slip to indicate which protocol layer is
  being authorized.

• protocol=ipx

  Used with service=ppp to indicate which
  protocol layer is being authorized.

• protocol=atalk

  Used with service=ppp or service=arap.

• protocol=vines

  For VINES over PPP.

• protocol=ccp

  Authorization of CCP (Compression Control Protocol). No other
  av-pairs associated with this.

• protocol=cdp

  Authorization of CDP (Cisco Discovery Protocol). No other
  av-pairs associated with this.

• protocol=multilink

  Authorization of multilink PPP. See max-links and load-threshold.

• protocol=unknown

  For undefined/unsupported conditions. Should not occur under
  normal circumstances.

• cmd (EXEC)

  If the value of cmd is NULL e.g. the AV pair is cmd=, then this is an authorization request for
  starting an exec (shell). If cmd is
  non-null, this is a command authorization request, It contains the
  name of the command being authorized, e.g. cmd=telnet.

• cmd-arg (EXEC)

  During command authorization, the name of the command is given
  by an accompanying cmd= AV pair, and each
  command argument is represented by a cmd-arg AV pair e.g.
  cmd-arg=archie.sura.net Note: cmd-arg should never appear in a configuration file.
  It is used internally by the daemon to construct a string which is
  then matched against the regular expressions which appear in a
  cmd clause in the configuration file.

• acl (ARAP, EXEC)

  For ARAP this contains an access-list number. For EXEC
  authorization it contains an access-class number, e.g. acl=2. which is applied to the line as the output
  access class equivalent to the configuration command

  line ...
    access-class 2 out

  An outbound access-class is the best way to restrict outgoing
  telnet connections. Note that a suitable access list (in this case,
  numbered 2) must be predefined on the NAS.

• inacl (PPP/IP/IPX)

  This AV pair contains an IP or IPX input access list number for
  slip or PPP e.g. inacl=2. The access list
  itself must be pre-configured on the Cisco box. Per-user access
  lists do not work with ISDN interfaces unless you also configure a
  virtual interface. After 11.2(5.1)F, you can also use the name of a
  predefined named access list, instead of a number, for the value of
  this attribute. Note: For IPX, inacl
  is only valid after 11.2(4)F.

Ubuntu Tacacs+ Server

Tacacs+ is a TCP based entirely new protocol used for AAA nowadays. This new protocol is not compatible with its previous versions like Tacacs and Xtacacs. With the help of Tacacs+ you can set up much more granular level access for the users, groups, subnets or device type etc.

Tacacs+ is an open-standard protocol compatible across various networking equipment vendor platforms.

Advertisements

Related – TACACS VS TACACS+

If you are one of the guys wanting to test some access restriction with Tacacs+ in a lab but don’t have a licensed product, then we will help you set up a Tacas+ server on your Linux-based Ubuntu machine by editing the tac_plus.conf file.

On the newer version of Ubuntu, you can easily install tacacs+ package from the apt-get repository which will also install libtacacs+1.

Step 1: Run command: sudo apt-get install tacacs+

lab@lab_VM1:~$ sudo apt-get install tacacs+

password for lab:

Reading package lists… Done

Building dependency tree

Reading state information… Done

The following extra packages will be installed:

libtacacs+1

The following NEW packages will be installed

libtacacs+1 tacacs+

lab@lab_VM1:~$ ps -ef | grep tac_plus

root      1220     1  0 12:37 ?        00:00:00 /usr/sbin/tac_plus -C /etc/tacacs+/tac_plus.conf

lab 22730  2682  0 14:55 pts/0    00:00:00 grep –color=auto tac_plus

Step 5: In this step we will edit the tac_plus.conf file at below location.

sudo nano /etc/tacacs+/tac_plus.conf

The tac_plus.conf file looks like below:

lab@lab_VM1:~$ cat /etc/tacacs+/tac_plus.conf

# Created by Henry-Nicolas Tourneur(henry.nicolas@tourneur.be)

# See man(5) tac_plus.conf for more details

# Define where to log accounting data, this is the default.

accounting file = /var/log/tac_plus.acct

# This is the key that clients have to use to access Tacacs+

key = testing123

# We also can define local users and specify a file where data is stored.

# That file may be filled using tac_pwd

#Defining the users, we have two users defined one admin and other ipwithease. Admin will have full access while another user will have limited access.

user= Administrator {

 login = cleartext Cisco

 member = “admin”

}

 user = ipwithease {

 login = cleartext “cisco”

 enable = cleartext “cisco”

 member = readonly

}

 #Defining the groups now to which members have been assigned above. Two groups are created admin and readonly.

group = admin {

 default service = permit

 service = exec {

 default attribute = permit

 priv-lvl = 15

 }

}

 group = readonly {

  default service = deny

  service = exec {

     default attribute = permit

     priv-lvl = 15

    }

}

  cmd = show {

           # permit show commands

           permit .*

  }

       # permit traceroute command

    cmd = traceroute {

               permit .*

    }

       # permit ping command

    cmd = ping {

               permit .*

    }

Hence in the above file, we have created two TACACs+ users.

User Administrator has the complete access and the user ipwithease has limited access and can run only the show commands, traceroute and ping commands.

Once you’re finished with everything you can run service tacacs_plus check to make sure the syntax is correct and if you get any errors you will need to restart the daemon using service tacacs_plus restart.

Advertisements

RADIUS

Протокол RADIUS является IETF-стандартом для AAA. Используется с начала 1990-х годов и первоначально применялся для коммутируемых модемных соединений. Изначально использовался для расширения Layer 2 протокола точка-точка (PPP) между конечным пользователем и сервером доступа к сети (NAS), передавая трафик аутентификации с NAS на AAA-сервер. Сведения от аутентификации и авторизации доставляются одним типом пакетов, а учет обрабатывается отдельным процессом. RADIUS имеет широкое распространение и поддерживается большинством производителей устройств и разработчиков программных продуктов.

Современная реализация RADIUS использует порты 1812 (аутентификация) и 1813 (учет) протокола UDP (также возможно использование портов 1645 и 1646). UDP обладает высокой скоростью, но имеет ряд недостатков, которые необходимо учитывать при его применении. Когда разрабатывали RADIUS, вопросы безопасности не были столь актуальны, как сейчас, поэтому он поддерживает довольно малое число типов аутентификации (Clear text и CHAP), шифрует только поле с паролем и в целом имеет среднюю степень безопасности.

Установка

Версия F4.0.3.alpha. Правим Makefile под gcc и Solaris, USERID и GROUPID
под себя (незачем ему работать под root), PIDFILE в
область журнала.
Расскоментировать MSCHAP (MSCHAP_DES и MSCHAP_MD4_SRC
приводит к ошибке
компиляции — не находит arap_des.h).
Добавить MSCHAP и MSCHAP_DES в CFLAGS
(интересно, как это у
других работает?). В общем, можно
только «ms-chap = cleartext», что
совершенно не интересно. Выключил MSCHAP
совсем.

Правим do_acct.c так, чтобы в учетный журнал не
выдавались пробелы и
непечатные символы (IOS 12.0 начал
выдавать записи о неудачных
попытках соединения, что
позволяет хакерам
вмешиваться в работу учетной системы, вводя
вместо имени
пользователя хитро
составленную строку,
имитирующую строку из учетного
журнала).

Якобы maxsess.c для IOS 12 надо править (finger
выдает имя
пользователя не с 13, а с 15 позиции), но IOS 12.0.5
по-прежнему выдает имя с 13й позиции.

make tac_plus — все
откомпилировалось!

В /etc/services добавляем: «tacacs 49/tcp», хотя это
вроде бы лишнее.

Засылаем в /usr/local/sbin и даем права «r-sr-s—«,
чтобы можно было запускать не ис-под
суперпользователя.

Для
использования алгоритма s/key для
аутентификации
необходимо подключить libskey.a при сборке.

Для обработки MSCHAP демоном
необходимо наличие
библиотеки DES (des_setkey() и др.) при
сборке. Если DES
отсутствует, то обработка MSCHAP
все-таки
производится, но на NAS, что менее
безопасно.mschap.h вместо ключа
содержит интересную фразу: «Contact Microsoft for the MSCHAP key».
Без такого ключа часть
обработки опять-таки будет
делаться не демоном, а NAS.

Предусмотрим автозагрузку

Конечно, можно стартовать сервис классическими /etc/init.d/tac_plus start и /etc/init.d/tac_plus stop, но, подразумевается, что после рестарта системы сервис поднимется автоматически. Начнем с того, что Ubuntu 19.04, как и большинство современных дистрибутивов Linux, используют подсистему инициализации systemd, которая очень неплохо работает с init-скриптами, написанными для более старой подсистемы sysv. Итак, для инициализации сервиса tac_plus, который мы будем использовать, увы, написан не systemd unit, а sysv init-скрипт. Найти такой скрипт можно здесь (мы его сами туда скопировали) — /etc/init.d, наш — /etc/init.d/tac_plus (этот для варианта с ldap, а для варианта без ldap будет tacacs_plus). Чтобы добавить наш tac_plus сервер в автозагрузку (а скорее всего его там нет, т.е. после рестарта он не запустится) можно изучить документацию по systemd и написать для него собственный unit, либо можно воспользоваться уже написанным sysv init-скриптом (ниже будет пара ссылок о написании systemd unit’ов). Выберем второй вариант:

1) В systemd предусмотрена совместимость со скриптами sysv из коробки. Для этого используется systemd-sysv-generator. Попробуем воспользоваться просто запустив sysv-скрипт не с помощью service, а с помощью systemctl:

Если все прошло успешно, то можем проверить статус:

Должны увидеть такое сообщение:

В выводе видно, что systemd запустил systemd-sysv-generator и преобразовал sysv-скрипт /etc/init.d/tac_plus в systemd unit. Теперь можем взглянуть на полученный systemd unit:

Выглядит это как-то так:

Перезагружаем сервер, проверяем, все ли хорошо(в выводе должны увидеть процесс tac_plus):

2) Вообще, чтобы systemd-sysv-generator отработал корректно, sysv-скрипт должен иметь LSB заголовок одними из первых строчек, хотя это не совсем верно, и он вполне неплохо распознает более ограниченные старые заголовки комментариев RedHat (description:, pidfile: и т. д.), которые есть в /etc/init.d/tac_plus. Однако, если systemd-sysv-generator все же подвел, попробуйте добавить LSB в начало файла tac_plus и повторить попытку:

Цифрами здесь указаны runlevel для sysv, на которых будет стартовать и останавливаться init-скрипт. Они, кстати, находятся там же (/etc/rc3.d, /etc/rc4.d, /etc/rc5.d и т.д), а скрипты с буквами S и K в начале стартуют и останавливаются скрипты (подробнее о sysv по ссылкам ниже). Еще стоит сказать, что стандартными способами добавления сервиса в автозагрузку в sysv были использование файла /etc/rc.local (в systemd он остался для совместимости, но не включен в автозагрузку, по умолчанию) и использование утилиты update-rc.d, которая раскидывает ваш init-скрипт по нужным runlevel.

3) Если добавление LSB заголовка не помогло (это мы делали в пункте 2), то давайте напишем свой systemd unit и добавим его в автозагрузку. Ну как свой, в существующем коде tacacs копаться мы не будем, а немного считерим и воспользуемся нашим /etc/init.d/tac_plus (добавим команды запуска, остановки и рестарта). Хоть это и не совсем красиво, но, вполне себе, практикуется. Итак, существует несколько директорий, где могут храниться unit’ы.

• */lib/systemd/system/ *# здесь хранятся копии всех unit’ов. Эти файлы могут быть запущены или остановлены самим сервисов во время его работы. Вносить изменения в эти файлы очень нежелательно. Для этого есть другая директория:
• */etc/systemd/system/ *# именно здесь и следует создавать systemd unit. К тому же эта директория имеет приоритет над остальными
• /run/systemd/system/ # файлы в этом каталоге имеют приоритет между /etc/systemd/system и/lib/systemd/system. К тому же systemd использует эту директорию для создания временных файлов в процессе работы. Рестарт сервера очищает каталог.

Создадим наш unit в /etc/systemd/system/

Добавим следующее:

Дадим unit-файлу права на выполнение:

Теперь запустим наш unit:

Добавим unit в автозагрузку:

Проверим, что unit-файл в автозагрузке:

Если вносите какие-то изменения в unit-файл, то systemd должен его снова изучить:

Обязательно рестартуем сервер и проверяем, работает ли автозагрузка для нашего tac_plus:

Кстати systemctl неплохо логирует в journalctl. Посмотреть логи автозагрузки для сервиса/unit’а можно так:

Final Words

TACACS+ is now ready to go. Congratulations, you just accomplished one part of hardening your organization’s networking devices!

Do not be afraid of Linux. There are a lot of freebies out there that can help your organization to save money on network tools and etc. Being free, it won’t be as fancy as the paid software but it will get the job done.

I hope this tutorial has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

TACACS+ (tac_plus daemon) ACLAdding two-factor authentication (2FA) to TACACS+How to configure AAA on Cisco router/switches Enabling AAA on Cisco ASA

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.