Перевірка підозрілих сеансів і налаштувань Ubuntu: розбір старої інструкції

Ця нотатка 2013 року описувала мою перевірку сеансів, SSH, firewall, sudo та вебсервера. Деякі тодішні висновки були надто категоричними. Нижче збережено команди й приклади, але уточнено, що саме вони можуть підтвердити.

1. Перевірка сеансів

who

r        tty7         2013-03-11 06:52 (:0)

r        pts/2        2013-04-03 05:21 (192.168.3.62)

r        pts/6        2013-04-03 08:27 (192.168.3.62)

r        pts/5        2013-04-03 07:58 (192.168.3.62)

(unknown) tty8         2013-04-03 06:16 (:1)

(unknown) tty9         2013-04-03 08:28 (:2)

(unknown) tty10        2013-04-03 08:47 (:3)

Позначка (unknown) сама по собі не доводить стороннього проникнення. Потрібно зіставити сеанс із процесами, диспетчером входу та журналами автентифікації.

who -a -p

завантаження системи 2013-03-11 06:54

           рівень виконання 2 2013-03-11 06:54

ВХІД   tty4         2013-03-11 06:54              1575 id=4

ВХІД   tty5         2013-03-11 06:54              1581 id=5

ВХІД   tty2         2013-03-11 06:54              1588 id=2

ВХІД   tty3         2013-03-11 06:54              1589 id=3

ВХІД   tty6         2013-03-11 06:54              1593 id=6

r        + tty7         2013-03-11 06:52  да        4824 (:0)

ВХІД   tty1         2013-03-11 06:52              5937 id=1

           pts/2        2013-03-11 06:57                 0 id=/2    термінал=0 вихід=0

r        + pts/2        2013-04-03 05:21 01:26        2104 (192.168.3.62)

r        + pts/6        2013-04-03 08:27   .           409 (192.168.3.62)

           pts/7        2013-03-11 11:45                 0 id=/7    термінал=0 вихід=0

           pts/8        2013-04-03 09:21             15957 id=ts/8  термінал=0 вихід=0

           pts/10       2013-04-03 09:13             14507 id=s/10  термінал=0 вихід=0

           pts/12       2013-03-11 10:18             19235 id=s/12  термінал=0 вихід=0

           pts/14       2013-03-11 10:31             21030 id=s/14  термінал=0 вихід=0

r        + pts/5        2013-04-03 07:58 00:05       23871 (192.168.3.62)

           pts/3        2013-04-03 07:36              5537 id=ts/3  термінал=0 вихід=0

           pts/7        2013-04-03 09:17             10140 id=ts/7  термінал=0 вихід=0

           pts/9        2013-04-03 09:14             14013 id=ts/9  термінал=0 вихід=0

           pts/11       2013-03-19 18:33              6218 id=s/11  термінал=0 вихід=0

           pts/13       2013-03-11 22:14             17281 id=s/13  термінал=0 вихід=0

           pts/15       2013-03-11 22:33             18853 id=s/15  термінал=0 вихід=0

           pts/17       2013-03-11 21:52             19310 id=s/17  термінал=0 вихід=0

           pts/6        2013-03-25 07:43                 0 id=/6    термінал=0 вихід=0

           pts/8        2013-03-25 07:43                 0 id=/8    термінал=0 вихід=0

(unknown) + tty8         2013-04-03 06:16  да        5873 (:1)

(unknown) + tty9         2013-04-03 08:28  да         813 (:2)

           tty10        2013-04-03 09:10              7691 id=:3    термінал=0 вихід=0

У старому випадку я завершував процеси так:

kill 5873 813

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

2. Пересилання X11 через SSH

Пересилання графічних застосунків контролює параметр у /etc/ssh/sshd_config:

X11Forwarding    no
/etc/init.d/ssh restart

Це не те саме, що повністю заборонити віддалений вхід чи будь-який доступ до робочого столу. Початкова згадка про X11 «за замовчуванням» залежала від системи; у поточній довідці OpenSSH базовим значенням є no, а дистрибутив може мати власну конфігурацію.

Історичне посилання з нотатки: http://d51x.ru/page/udalennyj-dostup-x11-forwarding.

3. Обмеження SSH-доступу

У первинному тексті наводилися такі параметри:

Port 22
ListenAddress 0.0.0.0
AllowUsers user1 user2 user3
/etc/init.d/ssh restart

Port 22 є стандартним портом, а 0.0.0.0 означає прослуховування всіх IPv4-адрес, не звуження доступу до однієї адреси. Зміна порту може зменшити фонове сканування, але не замінює автентифікацію та правила доступу. AllowUsers потрібно узгоджувати з реальними обліковими записами. Перед перезапуском перевірте конфігурацію й збережіть спосіб відновлення віддаленого доступу.

4. Початковий приклад arno-iptables-firewall

apt-get install arno-iptables-firewall

У нотатці конфігурація пов'язувалася з /etc/arno-iptables-firewall/conf.d:

EXT_IF="eth0 ppp0"

EXT_IF_DHCP_IP=1



# 3343,4434 - Порты для администрирования svn

# 9000 - порт для darkstat

# 3389 - терминал Windows

# 1500 - ???

# 8080 - порт для доступа к svn

# 1500 - ISP админка

# 440 - новый номер порта для ssh

# 22 - был ssh УБРАН



OPEN_TCP="80,443,21,6543,47,3343,4434,8080,1500,440"



# 110,25,995



OPEN_UDP=""

INT_IF="eth1"

NAT=0

INTERNAL_NET="192.168.3.0/24"

NAT_INTERNAL_NET="eth1"

OPEN_ICMP=1

LAN_OPEN_TCP="80,443,21,6543,1723,47,3389,1500,9000,5900,440"

invoke-rc.d arno-iptables-firewall restart

Це перелік потреб конкретного старого сервера, а не рекомендований набір відкритих портів. Відкривайте тільки потрібні служби. Число 47 у списку TCP-портів не означає дозвіл GRE як IP-протоколу; відповідні мережеві механізми різні.

5. Перевірка sudoers

Початковий приклад /etc/sudoers:

# User privilege specification
#root    ALL=(ALL:ALL) ALL

r           ALL=(ALL:ALL) ALL



# Members of the admin group may gain root privileges

#%admin ALL=(ALL) ALL



# Allow members of group sudo to execute any command

#%sudo<>ALL=(ALL:ALL) ALL



# See sudoers(5) for more information on "#include" directives:



#includedir /etc/sudoers.d

Не слід механічно коментувати root, групи чи включення каталогу: це може зламати передбачений порядок адміністрування. Спочатку визначте необхідні права, резервний адміністративний доступ і наявні правила. Для редагування використовуйте visudo, який перевіряє синтаксис. Старий фрагмент збережено разом із його особливостями форматування.

6. Пароль root

У старій нотатці рекомендувався складний пароль щонайменше з 12 символів і наводилася команда:

passwd root

Довжина сама по собі не гарантує захисту. Політика root, парольна автентифікація та SSH-доступ мають розглядатися разом; команда не є обов'язковим кроком для кожної Ubuntu-інсталяції.

7. Старий приклад щодо Range-запитів Apache

У початковому матеріалі було наведено:

curl -I -H "Request-Range: bytes=0-1,0-2,0-3,0-4,0-5,0-6" -s Ваш домен/robots.txt | grep Partial

Відповідь 206 Partial Content не є достатнім доказом вразливості. Вона може відображати звичайну підтримку часткових відповідей. Реальну вразливість потрібно перевіряти за версією, конфігурацією та офіційними повідомленнями безпеки, а не цим одним рядком.

Тоді пропонувалися такі зміни:

sudo a2enmod headers

proxy_set_header Range "";
proxy_set_header Request-Range "";

SetEnvIf Range (?:,.*?){5,5} bad-range=1
 RequestHeader unset Range env=bad-range
 RequestHeader unset Request-Range

/etc/init.d/apache2 restart

Фрагменти належать до різних конфігурацій: proxy_set_header — до Nginx, SetEnvIf і RequestHeader — до Apache. Їх не можна вставляти як один конфіг. Вони можуть змінювати поведінку завантажень і не замінюють оновлення.

Apache описує Range-вразливість CVE-2011-3192 як історичну проблему, виправлену в гілці 2.2. Сама гілка 2.2 вже завершила підтримку. Для робочого сервера потрібні підтримувані версії та перевірені налаштування.