Блог К2 ERP

К2®

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

Для удаления лицензии RDP с клиентского компьютера, откройте ветку реестра
HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing
и удалите все подразделы.

После этого повторите подключение к серверу RDP. При первом подключении запустите клиент «от имени Администратора».

--------------

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

Причина данной ошибки - отсутствие у пользователя прав на создание данных разделов реестра. Для устранения данной ошибки выполните следующие действия:
- Запустите mstc.exe с правами администратора или войдите под правами администратора.
- Подключитесь к терминальному серверу. В этот момент будут автоматически созданы разделы в реестре HardwareID и StoreID.
- Отключитесь от терминального сервера.

К2®

У квітні 2013 року виникла потреба запустити другий екземпляр Apache, використовуючи той самий виконуваний файл. Для незалежної роботи потрібно розділити конфігурації, адреси й порти прослуховування, PID-файли та журнали. Два процеси самі по собі не створюють відмовостійкого сервісу.

Нижче збережено початкові команди для середовища з SysV init та пояснено помилки в узгодженні шляхів. На сучасній системі спосіб керування службою слід узгодити з її пакетом і менеджером служб.

Окремі файли й журнали

Початкова схема спиралася на /etc/apache2/apache2.conf, /etc/apache2/ports.conf і /etc/apache2/envvars. Журнали задавалися директивами:

ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined

У старій системі копіювали init-скрипт та додавали його в автозапуск:

cd /etc/init.d
cp apache2 apache2_srv
update-rc.d apache2_srv defaults

Практично спочатку варто завершити налаштування й перевірку, а вже потім вмикати автозапуск. У скрипті замість початкового блока:

PIDFILE=`. /etc/apache2/envvars ; echo $APACHE_PID_FILE`
if [ -z "$PIDFILE" ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars >&2
exit 2
fi

використовували окремий файл середовища:

PIDFILE=`. /etc/apache2/envvars_apache2_srv ; echo $APACHE_PID_FILE`
if [ -z "$PIDFILE" ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars_apache2_srv >&2
exit 2
fi

ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin APACHE_ENVVARS=/etc/apache2/envvars_apache2_srv"
cp /etc/apache2/envvars /etc/apache2/envvars_apache2_srv

У копії змінювали PID-файл:

export APACHE_PID_FILE=/var/run/apache2.pid

на:

export APACHE_PID_FILE=/var/run/apache2_apache_2.pid

Окремий файл портів у першій частині нотатки називався /etc/apache2/ports_apache_srv.conf і містив:

Listen 81

Для журналів наводилися такі команди:

touch /var/log/apache2/error_apache2_srv.log
touch /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:root /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:adm /var/log/apache2/error_apache2_srv.log
chmod 640 /var/log/apache2/error_apache2_srv.log

Передавання команд потрібному екземпляру

У старому init-скрипті був такий блок запуску; у тому середовищі кеш не використовувався:

start)
log_daemon_msg "Starting web server" "apache2"
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;

Початковий виклик:

APACHE2CTL="$ENV /usr/sbin/apache2ctl"

замінювали на:

APACHE2CTL="$ENV /usr/sbin/apache2ctl -f /etc/apache2/apache2_srv.conf"

Відповідно змінювали команди:

$APACHE2CTL -k start
$APACHE2CTL -k stop
$APACHE2CTL -k graceful
$APACHE2CTL -t

Документація Apache пояснює: -f вибирає конфігурацію, -k задає дію керування, -t перевіряє синтаксис. Потрібні саме узгоджені налаштування цільового екземпляра.

Пошук процесів: недолік старого підходу

Початок функції у старому скрипті:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=`pidof apache2` || true

пропонувалося замінити таким фрагментом:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=`ps aux | grep 'apache2_srv' | grep -v 'grep' | awk '{print $2}' | xargs` || true

Обидва уривки є лише початками функції. Пошук через grep залежить від тексту командного рядка й може вибрати не той процес. Загальний pidof apache2 також не розрізняє потрібні екземпляри. Для керування слід використовувати відповідну службу та її окремий PidFile.

Узгодження імен і перевірка запуску

Перша спроба в нотатці завершилася так:

/etc/init.d/apache2_srv start
Starting web server: apache2apache2: Could not open configuration file
/etc/apache2/apache2_failover.conf: No such file or directory
failed!

Помилка посилалася на apache2_failover.conf, хоча вище було задано apache2_srv.conf. Перед запуском потрібно виправити всі виклики, щоб вони посилалися на один обраний файл. У нотатці його створювали так:

cp /etc/apache2/apache2.conf /etc/apache2/apache2_srv.conf

Наприкінці наводилися:

CustomLog /var/log/apache2/other_vhosts_access_apache2_srv.log vhost_combined
ErrorLog /var/log/apache2/error_apache2_srv.log
Include /etc/apache2/ports_apache2_srv.conf

Тут є ще одна розбіжність: раніше файл портів називався ports_apache_srv.conf, без «2» після apache. Назва у Include має точно збігатися з реально створеним файлом. Перевірте також, чи не підключає новий конфіг спільні файли з конфліктними Listen, віртуальними хостами або PID-шляхами.

У початковому тексті згадувалися NameVirtualHost xx.xx.xx.xx:80 та VirtualHost xx.xx.xx.xx:81. Адреси й порти потрібно узгоджувати з Listen. У сучасній гілці Apache 2.4 NameVirtualHost вже не впливає на роботу.

Старий запис завершувався успішним запуском:

/etc/init.d/apache2_srv start
Starting web server: apache2.

Для реальної перевірки потрібні успішний тест конфігурації, окремі PID і журнали, відповідь на потрібному порту та підтвердження, що зупинка другого екземпляра не зачіпає перший.

К2®

Ця нотатка 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 вже завершила підтримку. Для робочого сервера потрібні підтримувані версії та перевірені налаштування.

К2®

Для початкової діагностики Linux часто достатньо читати системні файли за допомогою cat. Віртуальна файлова система /proc надає відомості ядра про поточний стан системи.

cat /proc/cpuinfo — відомості про процесор.
cat /proc/meminfo — стан оперативної пам’яті.
cat /proc/interrupts — лічильники переривань.
cat /proc/swaps — активні області підкачування.
cat /proc/version — версія ядра та відомості про його складання.
cat /proc/net/dev — мережеві інтерфейси та їх статистика.
cat /proc/mounts — змонтовані файлові системи.
cat /proc/partitions — відомості про розділи блокових пристроїв.
cat /proc/modules — завантажені модулі ядра.
cat /etc/issue — текст привітання перед входом, який може містити назву дистрибутива.

Ці команди читають дані та не змінюють конфігурацію. Вміст /proc відображає поточний стан, а не вичерпний паспорт усього обладнання; доступність окремих відомостей залежить від ядра та середовища запуску.

Файл /etc/issue, на відміну від решти списку, не належить до /proc. Це налаштовуваний текст привітання, тому його не слід вважати безумовно точним джерелом версії операційної системи.

Детальний опис системних файлів: The /proc Filesystem — документація ядра Linux.

Блог К2 ERP

вівторок, 9 квітня 2013 р.

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

пʼятниця, 5 квітня 2013 р.

Другий екземпляр Apache: архівна схема SysV init та узгодження конфігурації

Окремі файли й журнали

Передавання команд потрібному екземпляру

Пошук процесів: недолік старого підходу

Узгодження імен і перевірка запуску

середа, 3 квітня 2013 р.

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

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

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

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

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

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

6. Пароль root

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

вівторок, 2 квітня 2013 р.

Як переглянути конфігурацію Linux через /proc

K2 Chat — навіщо бізнесу ще один месенджер, особливо під час війни?

Користне

вівторок, 9 квітня 2013 р.

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

пʼятниця, 5 квітня 2013 р.

Другий екземпляр Apache: архівна схема SysV init та узгодження конфігурації

Окремі файли й журнали

Передавання команд потрібному екземпляру

Пошук процесів: недолік старого підходу

Узгодження імен і перевірка запуску

середа, 3 квітня 2013 р.

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

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

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

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

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

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

6. Пароль root

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

вівторок, 2 квітня 2013 р.

Як переглянути конфігурацію Linux через /proc

K2 Chat — навіщо бізнесу ще один месенджер, особливо під час війни?

вівторок, 9 квітня 2013 р.

пʼятниця, 5 квітня 2013 р.

середа, 3 квітня 2013 р.

вівторок, 2 квітня 2013 р.