Архив рубрики: Администрирование Linux

Алерты Grafana в Telegram через прокси

В моём случае Grafana работает на CentOs7.
На данный момент в Grafana (v6.1.4) не реализовано подключение прокси-сервера для отправки оповещений в telegram. При поиске в Google можно найти ряд статей (раз,два,три) в которых утверждается что она станет ходить через прокси, если его добавить переменные окружения с указанием прокси сервера:

export http_proxy="http://myproxy:3128"
export https_proxy="http://myproxy:3128"

но по какой-то причине этот способ у меня так и не заработал, графана игнорирует прокси и пытается отправить уведомление напрямую на api.telegram.org

Если способ выше вам так же не помог, предлагаю ознакомиться с «костылём» описанным ниже.
Суть кратко: будем отправлять все запросы в сторону https://api.telegram.org на свой сервер с Apache и на нём делать proxy_pass на реальный api.telegram.org.
Можно, конечно, просто на уровне IPTABLES редиректить все обращения на 443 порт на реальную API, но при таком раскладе мы займём 443 порт на нашей VPS, что не очень кошерно, сайтики с HTTPS уже не похостишь..
Читать далее

0

IPSec на CentOs 7 с помощью LibreSwan

Ниже небольшой гайд по настройке IPSec в двух топологиях с помощью LibreSwan:

  • для сервера с публичным IP на интерфейсе;
  • для сервера c локальным IP и за маршрутизатором с NAT, используя NAT Traversal (NAT-T)


Подготовительный этап одинаков в обоих случаях:

  1. Устанавливаем libreswan:
    yum install libreswan
    
  2. Включаем IP forwarding, а IP redirects отключаем, перезагружаем параметры:
    # Открываем файл
    nano /etc/sysctl.conf
    
    # и добавляем параметры:
    net.ipv4.ip_forward = 1
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    
    # Применяем новые параметры
    sysctl -p
    
  3. Разрешаем IPSec траффик в firewalld:
    firewall-cmd --zone=public --add-service=ipsec
    
  4. Добавляем сервис в автозагрузку и запускаем
    systemctl enable ipsec
    systemctl start ipsec
    

Дальнейшая конфигурация отличается от топологии. Оба случая описаны ниже.
Читать далее

0

Linux — выполнение команды в фоне

Порой возникает необходимость выполнять команду в фоне и не зависеть от происходящего в сессии. Чтобы выполнить любую задачу в фоне необходимо создать bash скрипт. В примере я запускаю tcpdump и пишу результаты в файл.

Создадим скрипт:

[root@server /]# nano script.sh

Содержимое скрипта:

#!bin/bash
tcpdump -i ens33 dst port 5332 -w dump.cap >& /dev/null &
echo $! > script.pid

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

Делаем скрипт исполняемым:

[root@server /]# chmod +x script.sh

Запускаем скрипт:

[root@server /]# ./script.sh

PID читаем из файла:

[root@server /]# cat script.pid
115966

Когда выполнение команды нужно остановить просто убиваем процесс:

[root@server /]# kill 115966

 

1+

Samba share на CentOS 6

Создаем директорию, которая станет шарой, в моем случае:

mkdir /samba-share

Устанавливаем самбу и добавляем в автозагрузку:

yum install samba
chkconfig smb on

Идём в директорию с конфигом и бекапим дефолтный конфиг на всякий случай:

cd /etc/samba/
mv smb.conf smb.conf-default

Создаем свой smb.conf подобного содержания:

#========== Global Settings ================

[global]

workgroup = WORKGROUP # Имя рабочей группы

security = user

map to guest = bad user

min protocol = SMB1 # Минимальный и максимальный протокол самбы, если не указать то на последних сборках Windows не открывается
max protocol = SMB2

#========= Share Definitions ===============

[NWSC] # Имя шары

path = /samba-share # Путь до директории

writable = no

read list = root # Список пользователей, кто может читать

write list = root # Список пользователей, кто имеет право на запись

В моем случае я использую уже имеющуюся учётку root, при желании можно создать ещё пользователя и дать ему права на созданную папку.

Далее добавляем системного пользователя в базу пользователей самба и задаем ему пароль:

smbpasswd -a root

Открываем порт 445 например для посети 10.10.10.0/24 в iptables:

iptables -I INPUT 1 -s 10.10.10.0/24 -p tcp -m tcp --dport 445 -j ACCEPT
iptables-save

Запускаем самбу:

service smb start

Всё должно работать, дебажить просмотром лога или командой smbstatus

2+

Базовая HTTP авторизация nginx/apache

Создаём файл с учётками и добавляем туда пользователя/пароль:

htpasswd -c /var/www/nfsen/.htpasswd test

Идём в конфиг сайта (по дефолту у HTTPD /etc/httpd/conf/httpd.conf) и в параметрах хоста добавляем следующее (выделено красным):

<VirtualHost *:80>
ServerName netflow.local
DocumentRoot "/var/www/nfsen"
Alias /icons "/var/www/nfsen/icons"
<Directory "/var/www/nfsen">
AuthType Basic
AuthName "nfsen"
AuthUserFile /var/www/nfsen/.htpasswd
Require valid-user
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

После перезапуска web-сервера будет происходить запрос авторизации.

Удаление пользователя делается так:

htpasswd -D /var/www/nfsen/.htpasswd test

0

Настройки аутентификации пользователя postgres в PostgreSQL по паролю

Аутентификация клиентов управляется конфигурационным файлом, который традиционно называется pg_hba.conf и расположен в каталоге с данными кластера базы данных.
По умолчанию для локального пользователя postgres установлена аутентификация peer (более подробно в документации https://postgrespro.ru/docs/postgrespro/9.6/auth-pg-hba-conf).
Поэтому, для подключения к серверу переключаемся в консоли на пользователя postgres:
sudo su — postgres
Подключаемся к серверу:
psql
Чтобы задать пароль пользователю postgres выполняем в консоли postgres запрос:
alter user postgres encrypted password 'new_password';

Для того чтобы переключить аутентификацию пользователя postgres в режим по паролю (т.к. пароль у него теперь задан) редактируем файл pg_hba.conf:

sudo nano /etc/postgresql/9.6/main/pg_hba.conf

Находим в нем строку:
local all postgres peer
И меняем peer на md5. Сохраняем конфигурационный файл.
Чтобы применить изменения в конфигурации сервера без его рестарта то используется команда:
sudo service postgresql reload
Использование этой команды не приведет к прерыванию любых активных запросов или подключений к базе данных.
Того же эффекта можно достичь выполнив запрос SQL на сервере:
SELECT pg_reload_conf();
После выполнения команды подключимся снова к серверу (из сеанса любого пользователя (чтобы выйти из сеанса пользователя postgres нужно в консоли ввести exit и нажать Enter)):
psql -U postgres
После ввода пароля мы подключимся к серверу БД. Для проверки можно выполнить запрос:
SELECT version();
0

Как сменить пароль пользователя в Linux

Для смены пароля пользователя в Linux, необходимо выполнить в Терминале (или консоли) следующую команду:
passwd
После ввода этой команды, система потребует от вас корректно и дважды ввести ваш новый пароль. Если вы хотите сменить пароль другого пользователя, вам необходимы права суперпользователя root. Если вы наделены такими правами, то выполните в терминале:
sudo bash
И введите пароль суперпользователя root (о переходе в режим суперпользователя будет свидетельствовать знак «#» вместо привычного для вас знака «$»). И, затем, выполните команду:
passwd имя_пользователя
Где имя_пользователя — логин пользователя, которому вы меняете пароль. Система опять же потребует от вас корректно и дважды ввести новый пароль.
0

Создание пользователя в Ubuntu Linux с правами суперпользователя

Задача:

Создать на сервере Ubuntu Linux пользователя с правами root (суперпользователя).

Step-by-step guide

  1. Подключаемся к серверу и логинимся под пользователем имеющим права sudo
  2. Выполняем команду: sudo adduser username
  3. Вводим и подтверждаем пароль нового пользователя
  4. Заполняем или оставляем пустыми данные пользователя и подтверждаем их корректность
  5. Пользователь создан, добавляем его в группу sudo введя команду: sudo usermod -aG sudo username
  6. Проверяем наличие прав суперпользователя — переходим в сессию нового пользователя: su — username
  7. Выполняем команду которая требует прав суперпользователя, например: sudo ls -la /root
  8. По запросу системы вводим пароль пользователя — после этого команда выполнится с правами администратора.
0

Сертификат с несколькими IP SANS или Common Name

Для создания такого сертификата нам потребуется заранее подготовить конфиг для opnessl вида:

В разделе alt_names можно указать сколько угодно IP для подписи, а для подписи нескольких Common Name а не IP меняем параметры IP.1 на DNS.1 итд)

nano openssl.cnf
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
[req_distinguished_name]
countryName = RU
countryName_default = RU
stateOrProvinceName = Moscow
stateOrProvinceName_default = Moscow
localityName = Moscow
localityName_default = Moscow
organizationalUnitName = MYCORP
organizationalUnitName_default = MYCORP
commonName = 192.168.1.1
commonName_max = 64
[v3_req]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
IP.1 = 192.168.1.2
IP.2 = 192.168.1.3
IP.3 = 192.168.1.4
IP.4 = 192.168.1.5

После подготовки конфига мы можем сгенерировать приватный ключ и создать CSR

openssl genrsa -out my.key 2048
openssl req -new -out my.csr -key my.key -config openssl.cnf

Полученный CSR можно скормить любому CA, в том числе и собственно созданному.

0