В systemd-journald выявлены три уязвимости, позволяющие получить права root
В компоненте systemd-journald, отвечающем за ведение логов в systemd, выявлены три уязвимости, позволяющие непривилегированному атакующему повысить свои привилегии в системе и выполнить код с правами root. Уязвимости проявляются во всех дистрибутивах, использующих systemd, за исключением SUSE Linux Enterprise 15, openSUSE Leap 15.0 и Fedora.

Полезности по ssh

https://hackertarget.com/ssh-examples-tunnels

перевод: https://habr.com/post/435546/

#pentest

Это если вдруг у кого-то возникают вопросы о том, почему jira работает через раз.

✅ 13.52.5.91 (api.media.atlassian.com)
✅ 13.52.5.90 (api.media.atlassian.com)
✅ 68.183.15.220 (api.media.atlassian.com)
✅ 94.237.83.155 (api.media.atlassian.com)
✅ 94.237.27.143 (api.media.atlassian.com)
✅ 94.237.87.168 (api.media.atlassian.com)
✅ 94.237.87.169 (api.media.atlassian.com)
✅ 104.248.205.44 (api.media.atlassian.com)

❗ Генпрокуратура 27-31-2018/Ид2971-18
❌ 94.237.31.136 (api.media.atlassian.com) by 94.237.31.136/32
❌ 94.237.31.142 (api.media.atlassian.com) by 94.237.31.142/32
❌ 94.237.87.160 (api.media.atlassian.com) by 94.237.87.160/32
❌ 94.237.82.76 (api.media.atlassian.com) by 94.237.82.76/32
❌ 94.237.81.191 (api.media.atlassian.com) by 94.237.81.191/32
❌ 94.237.87.166 (api.media.atlassian.com) by 94.237.87.166/32
❌ 94.237.87.161 (api.media.atlassian.com) by 94.237.87.161/32
❌ 94.237.83.25 (api.media.atlassian.com) by 94.237.83.25/32
❌ 94.237.87.155 (api.media.atlassian.com) by 94.237.87.155/32
❌ 159.65.207.81 (api.media.atlassian.com) by 159.65.0.0/16
❌ 167.99.220.193 (api.media.atlassian.com) by 167.99.0.0/16
❌ 174.138.6.186 (api.media.atlassian.com) by 174.138.0.0/17
❌ 174.138.13.134 (api.media.atlassian.com) by 174.138.0.0/17
❌ 206.189.98.69 (api.media.atlassian.com) by 206.189.0.0/16

To subscribe for lock status use /add

Приоритеты переменных в ansible

https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

update: изменена ссылка на доку

#ansible

Terraform

Попробую в качестве теста делать посты в таком формате.

А вы знали о такой крутой штуке как terraform? Это такая тулза для создания, изменения и версионирования конфигураций ваших серверов. Умеет работать из коробки со множеством провайдеров - aws, gce. Описываете вашу инсталляцию, если нужно прикручиваете helm или ansible, terraform plan && terraform apply...

#terraform #test

Расскажете о преимуществах вашей любимой платформы?

Коллеги, мы продолжаем поиск экстраординарных, уникальных людей к нам в команды, на вакансии: QA Engineer, Support Engineer, Разработчик Ruby, Frontend-разработчик, Системный аналитик, Pre-sale инженер, Менеджер по продажам ИТ проектов, Product Marketing Manager.

https://m.hh.ru/employer/2156053

можно в личку мне писать или через сайт.

#вакансии

@Civiloid Владимир, спасибо тебе отдельное. Ты подсказал на 100% верное решение, правда я ввиду отсутствия опыта не сразу понял как его правильно реализовать)
Может будет кому полезно - сейчас опишу как мы решили нашу проблему редиректа с HTTP на HTTPs балансер в GCP
Собственно у нас был виртуальный хост вида

server {
        listen 80;
        server_name ~.;
        return 301 https://$host$request_uri;
}

Т.есть все что приходит по 80 порту - редиректим на https://
Но c glb так не получилось, потому что трафик то приходит https, хоть и на 80 порт.
browser —> http —> glb —> https —> backend
В итоге редирект есть, а по факту - его нет) Зато все запросы которые идут не через glb он редиректил исправно.
Решение: можно этот же виртуальный хост для редиректа заставить слушать шифрованый трафик, но важно указать server_name

        listen 443;
        server_name *.

domain.com

;
    if ($http_x_forwarded_proto = 'http') {
            return 301 https://$host$request_uri;
        }

Ну или прописать уже на другие виртуальный хости это же правило


P.S. Кстати, при создании балансера тупонул еще в одном моменте. Вместе с 443 портом - добавил на backend еще и 80 порт, из-за чего glb начал довольно странно себя вести (ну а хули я хотел)
Даже на обычных страничках со статикой время получения первого байта доходило до 10сек ) В итоге когда оставили только один 443 порт на backend - все заработало как надо)

Чиним ssh-agent на mac

Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa

добавить в ssh config

#macos #ssh

поговаривают, что rsa - уныло, грустно и вообще устаревшие фекалии мамонта. За сям нужно все это дело апгредить.

https://bagja.net/blog/upgrade-ssh-key-to-ed25519.html

#ssh #rsa #ed25519

Openvpn объединение файлов в один конфиг

Клиент openvpn прекрасно умеет работать по одному файлу, в котором включены все параметры, сертификаты и ключи. Преимуществ уйма - начиная от автоматизации, когда генерируется всего один файл и заканчивая отсутсвием необходимости таскать за собой ворох ключей, следить за их именами и путями где они лежат.

Для того чтобы создать такой файл в конфиг openvpn.conf последовательно в любом порядке записываются все ключи и сертификаты, отделяясь друг от друга тегами, как в html разметке. Для каждого ключа - свой тег.

Полный список тегов: ca, cert, dh, extra-certs, key, pkcs12, secret, --tls-auth.

Пример:

key-direction 1

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
f745... rest of tls key
-----END OpenVPN Static key V1-----
</tls-auth>

<ca>
-----BEGIN CERTIFICATE-----
MIIG... rest of ca.crt data
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
MIIH... rest of client/user .crt data
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
MIIJ... rest of client/user .key data
-----END PRIVATE KEY-----
</key>

Как настроить 2500 микротиков по всей стране и поддерживать на них актуальный конфиг, когда у падаванов на местах - лапки

Итак, постановка задачи:

* Имеется порядка 2500 географически разнесенных торговых точек. В каждой точке установлен т.н. Главный компьютер, он же ПК заведующего, кассы на базе персональных компьютеров под управлением Windows, система видеонаблюдения.

* Сеть одноранговая, 192.168.0.0/24, адрес шлюза и ДНС, он же роутер, 192.168.0.254, адрес главного компьютера - 192.168.0.1. Подключение к Интернет не стандартизировано.

* Необходимо обеспечить доступ главного компьютера в интернет без ограничений, остальным устройствам в сети предоставить доступ только на заранее известный список ресурсов. Кроме того, требуется обеспечить возможность удаленного управления каждым роутером в отдельности, а также возможность массовой настройки всех устройств, например, для добавления нового ресурса в список разрешенных.

* Постепенную замену всех установленных роутеров на MikroTik hAP ac lite необходимо произвести силами региональных техников, не знакомых с RouterOS. Предоставление доступа к настроенным роутерам местному персоналу по умолчанию не предполагается.

Взяли python в зубы и за три дня набыдлокодили. Структурно вышло вот так:

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

* Для удаленного управления устройствами поднимается VPN-туннель до центрального офиса

* В офисе установлен и настроен VPN-сервер

* Параметры подключения(логин и пароль) генерируются для каждого устройства как средствами программы настройки, так и на стороне сервера. IP-адрес на VPN-интерфейсе ассоциирован с номером торговой точки по следующему правилу: номер торговой точки приводится в 4-значный hex, который разделяется на 2 октета, и каждый из них возвращается в dec. Пример: точка №500. hex(500)=01f4, dec(01)=1, dec(f4)=244. Таким образом, два последних октета адреса на PPTP интерфейсе будет 1.244

* На серверной стороне разработан скрипт, осуществляющий массовое применение изменений. Для каждого устройства выполняются только те команды, которые еще не были применены для него, то есть контролируется версионность.

за подробностями и кодом - в wiki или vk:

http://pubwiki.mindsellers.ru/index.php/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%86%D0%B5%D0%BD%D1%82%D1%80%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D1%80%D0%BA%D0%BE%D0%BC_MikroTik

vk.com/@mindsellers-sistema-centralizovannogo-upravleniya-parkom-mikrotik

#python #mikrotik #vpn

Grafana basic auth

В ролях:
- grafana stable chart
- nginx ingress controller
- terraform

Задача:
Сделать basic auth для графаны на уровне nginx, передавая username в grafana, так чтобы переданное имя использовалось как пользователь в grafana и запихнуть всё это в терраформ.

Решение: (выписка из values.yaml)

ingress:
  enabled: true
  annotations:
    'kubernetes.io/ingress.class': ${var.controller_ingress_class}
    'nginx.ingress.kubernetes.io/auth-type': ${var.auth-type}
    'nginx.ingress.kubernetes.io/auth-secret': ${var.basic_auth_secret_name}
    'nginx.ingress.kubernetes.io/auth-realm': ${var.auth-realm}
    'nginx.ingress.kubernetes.io/configuration-snippet': |
      proxy_set_header X-Remote-User $remote_user;
....
grafana.ini:
  users:
    allow_sign_up: false
    allow_org_create: false
  auth:
    disable_login_form: true
  auth.proxy:
    enabled: true
    header_name: X-Remote-User
    header_property: username
    auto_sign_up: true

где переменные в main.tf принимают такие значения:

auth-type         = "basic"
auth-secret       = "nginx-ingress-auth"
auth-realm        = "Authentication Required - OK"
basic_auth_secret = "${file("basic_auth.txt")}"

Содержимое файла basic_auth.txt заполняется так:

htpasswd -nb username long_long_password > basic_auth.txt

#grafana #kubernetes #nginx #ingress #terraform