rev="post-1391" No Comments
fallocate -l 8G /swapfile && mkswap /swapfile && swapon /swapfile
Обема и мястото на файла се корегират на вкус.
Още една халба с акъл… Наздраве!
rev="post-1391" No Comments
fallocate -l 8G /swapfile && mkswap /swapfile && swapon /swapfile
Обема и мястото на файла се корегират на вкус.
rev="post-1299" No Comments
Collectd е чудесен инструмент за събиране на статистическа информация. Обикновено го ползвам в съчетание с Graphite/Carbon и Grafana. За съжаление обаче в pfSense, Collectd липсва като пакет за инсталация през уеб интерфейса.
Но пък е налино за инсталация в пакетната система на FreeBSD, а ние знаем, че pfSense е базиран на FreeBSD. Тогава отваряме SSH конзолата и действаме (за версия 2.4.5_1):
pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/release_3/All/liboping-1.8.0_1.txz
pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/release_3/All/collectd5-5.8.1_2.txz
Ако пакетния мениджър е строшен и върне грешка за липсваща библиотека, просто го преинсталираме:
pkg-static install -f pkg
rev="post-1359" 2 Comments
Един проблем при ползването на Bacula с MySQL база за каталог:
Termination: *** Backup Error ***
Fatal error: catreq.c:680 Restore object create error.
Fatal error: sql_create.c:1273 Create db Object record INSERT INTO RestoreObject
(ObjectName,PluginName,RestoreObject,ObjectLength,ObjectFullLength,ObjectIndex,
ObjectType,ObjectCompression,FileIndex,JobId) VALUES ('RestoreOptions',
'bpipe:/MYSQL/database_name.dump:/usr/bin/mysqldump database_name:mysql',
'# Plugin configuration file\n# Version 1\nOptPrompt=\"Restore command to use\"\nrestore_command=@STR@\n\n',98,98,0,27,0,381,18) failed.
ERR=Data too long for column 'PluginName' at row 1
Случва се при архивиране на mysql бази данни с по-дълги имена. Решението на проблема е дребна редакция в ДБ модела на каталога:
ALTER TABLE 'RestoreObject' CHANGE 'PluginName' 'PluginName' BLOB NOT NULL;
rev="post-1336" No Comments
Начало 7 Май 2022 17:00, край 8 Май 2022 17:00.
Успях да направя скромно включване в контеста от една затънтена полянка в родопите. В общи линии всички познати, лесно достъпни и сгодни местенца за излизане около Пловдив бяха заети от туристи, та се наложи да пообикалям, докато си намеря свободна полянка в района между с. Марково и с. Гълъбово (KN22IA). Открити посоки – само север и северозапад.
Техниката, с която работих:
Успях да се чуя с приятели, с които не съм се чувал и виждал от много време и в крайна сметка записах в лога си 5 връзки с български станции. Макар, че чувах и станции от Сърбия, с моите 4-5W и не особено фокусирана антена, нямаше как да ги стигна.
За следващия контест планирам нова двубандова антена, а може и да споделя процеса по изработката ѝ.
Правилата за провеждане на радиолюбителски УКВ състезания може да прочетете тук.
73,
de LZ1ETE
rev="post-1323" No Comments
Въпрос за 1-ви клас: Знаете ли как се конфигурира SSH автентикация базирана на ключове?
Въпрос за 2-ри клас: Знаете ли какво е обратен (reverse) SSH тунел?
Ситуация: Имаме *nix сървър, който е разположен зад NAT или има толкова лош firewall, че не разрешава никакви входящи връзки. А ние искаме да се свържем с него „от вън“ (през Интернет). А може сървъра да е в мрежата на някой глупав Интернет доставчик, чиито DHCP lease е неприлично кратък и адресите се сменят…
Решение 1: Инсталираме OpenVPN клиент и го свързваме с наш VPN сървър, който е публикуван и достъпен в Интернет. После по изградения VPN канал се свързваме към супер секретния или с неизвестен ИП адрес отдалечен хост.
Решение 2: Стартиране на обратен SSH тунел към наш сървър в Интернет. Ето това решение разглеждам в текущата статия.
Най-краткия пример е следния:
На отдалечения хост изпълняваме следната команда:
ssh -R 42001:localhost:22 tunnel@ssh.kamenitza.org
Това ще изгради SSH връзка до адрес ssh.kamenitza.org и през тази връзка ще тунелира трафика от 127.0.0.1:42001 на сървъра ssh.kamenitza.org към 127.0.0.1:22 на динамичния хост с неизвестно ИП. Т.е, ако искаме да се свържем с отдалечената машина е необходимо в SSH сървъра да извикаме:
ssh 127.0.0.1:42001
Супер лесно и готино. Обаче как да си осигурим постоянното стартиране на SSH тунела от отдалечения хост?
Създаваме си демон, който ще се стартира автоматично сам и ще осигурява SSH връзката.
Генерираме ключовете за автентикация на клиента:
mkdir -p /etc/tunnel
ssh-keygen -qN "" -f /etc/tunnel/id_rsa
Създаваме файл /etc/systemd/system/ssht.service със следното съдържание:
[Unit]
Description=Reverse SSH tunnel
Wants=network-online.target
After=network-online.target
StartLimitIntervalSec=0
[Service]
Type=simple
Environment=REVERSE_PORT=42001
Environment=SSH_SERVER=ssh.kamenitza.org
Environment=SSH_PORT=22
Environment=SSH_USER=worm
Environment=CLIENT_SSH_PORT=22
ExecStart=/usr/bin/ssh -qNn \
-o ServerAliveInterval=30 \
-o ServerAliveCountMax=3 \
-o ExitOnForwardFailure=yes \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-i /etc/${SSH_USER}/id_rsa \
-R ${REVERSE_PORT}:localhost:${CLIENT_SSH_PORT} \
${SSH_USER}@${SSH_SERVER} -p ${SSH_PORT}
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target
Създаване на потребителя на сървъра:
useradd -m -s /bin/true tunnel
mkdir -p ~tunnel/.ssh
chown -R tunnel:tunnel ~tunnel/.ssh
chmod 700 ~tunnel/.ssh
Поставяме съдържанието на /etc/tunnel/id_rsa.pub от клиента в ~tunnel/.ssh/authorized_keys на сървъра.
Настройката на правата е задължителна:
chmod 600 ~tunnel/.ssh/authorized_keys
И вече можем да активираме демона на отдалечената машина:
systemctl daemon-reload
systemctl enable ssht
systemctl start ssht
Ако всичко е наред, би трябвало сега от SSH сървъра да можем да се закачим за отдалечения хост ето така:
ssh localhost:42001
rev="post-1319" No Comments
# virsh start my_virtual_pc
error: Failed to start domain my_virtual_pc
error: internal error: process exited while connecting to monitor: failed to initialize KVM: Cannot allocate memory
Това е гадно, нали? Ето причината:
# free -h
total used free shared buff/cache available
Mem: 62G 45G 558M 2.9G 16G 13G
Swap: 31G 2.8G 29G
И това е нормално – свободната памет трябва да бъде ползвана. В случая, 16ГБ от оперативната памет са отишли за кеширане на каквото е намерил за добре линукса. Но ние искаме да си пуснем виртуалната машина! И не искаме да спираме никой от процесите, които заемат повечеко RAM. Най-лесно е да вземем да разчистим всичкия тоя кеш буфер:
# echo 3 > /proc/sys/vm/drop_caches
Бърза проверка:
# free -h
total used free shared buff/cache available
Mem: 62G 46G 12G 2.8G 4.3G 12G
Swap: 31G 2.8G 29G
rev="post-1304" No Comments
Паролата за отдалечен достъп до Уиндоус (Windows Remote Desktop) компютър може да се съхрани в RDP файла, който бихме могли да ползваме, като шорткът. Така няма да бъдат искани никакви креденшъли при влизане. Добавя се следния ред:
password 51:b:encrypted-password
Паролате е кодирана с инструментчето cryptRDP5. Изпълнява се в командния ред:
> cryptRDP5.exe mega-password
01000000D08C9DDF0115D1118C7A00C04FC297EB010...
rev="post-1297" No Comments
Интернет е пълен, даже направо фрашкан с адреси бълващи спам, сканиращи ботове, заразени устройства и какви ли още не безполезни генератори на трафик.
Аз не бих ги пуснал до мой сървър. Лесен начин да се оттървем поне от познатите такива съм публикувал тук.
Това е прост баш скрипт, който изтегля публичен списък с лоши адреси и създава iptables плравила, които да издропят трафика идващ от тях.
rev="post-1093" No Comments
Ubuntu Server 18. Уж модула е инсталиран, но в логовете се виждат ей такива грешки:
# warning: pcre:/etc/postfix/domains.pcre is unavailable. unsupported dictionary type: pcre
Все пак проверяваме:
# postconf -m | grep pcre
pcre
Ръчно събитието може да се повтори ето така:
# postmap -q foo pcre:/etc/postfix/domains.pcre
postmap: warning: unsupported dictionary type: pcre (/usr/lib/postfix/dict_pcre.so: No such file or directory)
postmap: fatal: unsupported dictionary type: pcre
И тук вече се изяснява картинката. Библиотеката е инсталирана, просто файла е с друго име.
Поправяме конфигурацията ей така:
# sed -i 's/\/dict_pcre/\/postfix-pcre/g' /etc/postfix/dynamicmaps.cf
rev="post-1089" No Comments
Наложи ми се да копирам големи файлове от уиндоус към линукс през SSH. Обикновнео ползвам WinSCP за подобни дейности. За малки файлове или отдалечено редактиране е приемливо и удобно, но когато стане дума за много гигабайти – по-скоро не. Проблемът му е, че дори при достатъчно бърза връзка, скоростта на копиране пак се колебае между 1 и 3 МВ/с. Ползвайки последната към момента версия.
В чудене и безброй проби с подреждания и размествания на крипто алгоритмите на клиента и на сървъра, в крайна сметка стигнах до най-бързото решение (за мен). Уловката е, че е линукс-линукс. В уиндоус вероятно с cygwin може да се измисли нещо, но нямам доказателства.
Самото копиране:
tar -zcvf - /path | ssh user@1.2.3.4 "cd /tmp && tar -zxvf -"
Това ще вземе директорията /path и ще я излее на 1.2.3.4 в /tmp. Явно да се прекара през тарване и зипване дава положителни резултати.
rev="post-1080" No Comments
ldapmodify е основен инстурмент с който могат да се редактират обекти в една активна директория (АД) посредством *nix среда.
За едно сравнително популярно действие, като смяна на парола, обаче нещата не са толкова лесни, или поне на пръв поглед не са. Смяната на паролата в LDIF формат изглежда така:
dn: CN=Testi Testev,OU=Users,OU=Accounts,DC=corp,DC=local
changetype: modify
replace: userPassword
userPassword: SlivovSladoled
Kомандата се изпълнява успешно и редактира съответния атрибут, но ефект от това няма. Т.е. никаква парола не сме сменили.
Оказва се, че в Windows Active Directory, userPassword полето по подразбиране не е разрешено. Разрешаването му е лесно с ADSI Edit:
Стойността на dsHeuristics трябва да е точно 000000001 (не 1). След промяната е необходима и актуализация на схемата:
И сега вече нещата се случват! Пример:
LDAPTLS_REQCERT=never ldapmodify -D 'CN=Admin,OU=Admins,DC=corp,DC=local' -w AdminPwd -p 389 -ZZ -x -h 192.168.1.1 -f ldif.txt
*ADSI Edit е страхотен инструмент, с който, ако не се внимава, може напълно и завинаги да бъде сасипана една Активна Директория.
rev="post-1075" No Comments
С конфигурацията на Carbon по подразбиране, Whisper база данни файловете пазят информация само за последните 24часа. Промяната на този период е лесно да се направи в конфигурацията на Carbon:
/etc/carbon/storage-schemas.conf
[default]
pattern = .*
retentions = 1m:30d,15m:10y
# find /var/lib/graphite/whisper/ -type f -name '*.wsp' -exec whisper-resize --nobackup {} 1m:30d 15m:10y \;
# chown _graphite:_graphite /var/lib/graphite/whisper -R
# systemctl restart carbon-cache
rev="post-1065" No Comments
Както всички телефони, и моят се препълни със снимки и клипове.
Включвам го с УСБ кабел към компютъра и започвам да копирам. По най-стандартния уиндоусовски начин – копи от телефона, пасте на диска на компютъра. Да, ама върви със скорост все едно през телефонна линия го правя. Беше късно, не ми се занимаваше, реших да го оставя да се изкопира през нощта. На другия ден поглеждам какво става и за около 10 часа беше изкопирало 9%. А данните общо са около 30ГБ. Надушвам конспирация! Нарочно са го направили така, за да не могат хората да си копират файловете, а да им ползват облаците. Прекратих го. Обмислях варианта просто да извадя картата памет от телефона и да си взема файловете директно от нея, но исках да опитам и още нещо.
Дали няма да мога да си помогна с Android Debug Bridge?
Необходимо е да се активира „Отстраняване на УСБ грешки“, което се намира в „Настройки > Опции на програмиста“. Менюто „Опции на програмиста“ по принцип е скрито, и за да се покаже е необходимо първо да отворим „Всичко за телефона“ и да натискаме бързо 10-15 пъти върху „Номер на версията“.
ADB e разархивиран някъде на компютъра. Пускам командния ред (cmd) и отивам в директорията на ADB.
Първо влизам в телефона и проверявам къде точно са снимките или файловете, които ще копирам:
>adb shell
HWVNS-H:/ $ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 1.3G 14M 1.3G 2% /
tmpfs 1.3G 544K 1.3G 1% /dev
tmpfs 1.3G 0 1.3G 0% /mnt
none 1.3G 0 1.3G 0% /sys/fs/cgroup
/dev/block/dm-0 1.8G 1.8G 17M 100% /system
/dev/block/dm-1 580M 394M 173M 70% /vendor
/dev/block/dm-2 182M 101M 77M 57% /product
/dev/block/dm-3 27M 412K 26M 2% /version
/dev/block/dm-4 182M 95M 83M 54% /cust
/dev/block/bootdevice/by-name/cache 248M 164K 243M 1% /cache
tmpfs 1.3G 0 1.3G 0% /storage
/dev/block/dm-5 10G 8.9G 1.4G 87% /data
/data/media 10G 8.9G 1.3G 87% /storage/emulated
/dev/fuse 30G 28G 2.0G 94% /storage/4308-131B
32GB-товата ми SD-карта е ясна – /storage/4308-131B.
Още малко ориентиране:
$ cd /storage/4308-131B
HWVNS-H:/storage/4308-131B $ ls
Android DCIM Download Huawei HuaweiBackup LOST.DIR Pictures backup z
Директорията със снимките е DCIM. Излизам от телефона:
exit
Копиране:
adb pull /storage/4308-131B/DCIM/Camera c:\todor\
След няколко секунди става ясно, че скоростта на копиране е коренно различна. Сега е сравнимо с нормална USB2 флашка. 30те ми ГБ се изкопираха за по-малко от час.
Има и противоположна команда push, с която пък могат да бъдат копирани файлове в другата посока – към телефона.
Наздраве!
rev="post-1063" No Comments
Има един инструмент, който почти бях забравил – haveibeenpwned.com.
В този сайт е събрана база данни от всички известни изтичания на потребителски данни в Интернет. Можете да проверите дали ваш акаунт е бил засегнат от подобен ВиК проблем.
Друго, което сайта предлага е възможност да проверите дали паролата ви е изтичала някога от някъде. Та, ако си мислите, че сте си измислили ултра мега сигурна парола, която се окаже, че някой някъде е използвал и акаунта му е изтекъл, ще разберете даже колко пъти се е случвало това. Проблемът с това е, че щом е изтекла, то най-вероятно тя е включена в базите данни с думи, които се ползват основно за речникови атаки. И ако някой вземе, че реши да ви хаква, шанса му да успее е значително по-висок, ако паролата ви е в подобен речник.
А сега кой ще си напише паролата в някакво поленце в някакъв сайт, за да му каже колко е добра? 🙂 Ми аз не бих.
Все пак е възможна проверка по сигурен начин. Сайта има АПИ интерфейс, към който можем да подадем само първите 5 символа от паролата, а той ще върне всички съвпадения (може да са 5 или 500), за да може ние сами да си търсим пълния хеш. Е да, ама е малко неудобно и изисква някакъв ръчен труд.
Направил съм малък баш скрипт, който пита за парола, обръща я в SHA1, пита онлайн базата за съвпадение с първите 5 символа от хеша, после сравнява върнатия резултат и сервира проверената информация. Паролата не се подава, като аргумент на скрипта, за да се записва в историята на командите.
Качен е публично в GitHub тук.
Това е кода:
#!/bin/bash
echo -n "Enter password to check: "
read PWD
HASH=$(echo -n $PWD | sha1sum | awk '{print $1}')
RESULT=$(curl -s https://api.pwnedpasswords.com/range/$(echo $HASH | cut -c1-5) | grep -i ${HASH:5} || echo "0:0")
echo "Your password has leaked $(echo $RESULT | awk -F: '{print $2}' | sed 's/[^0-9]//g') times."
rev="post-1054" No Comments
Маршрутизаторите и комутаторите също имат нужда от архивиране! Не че това ще направи подмяната на изгорял рутер удоволствие, но ще е значително по-лесно. А и решението е почти контрол на версиите – с един commit на ден, което помага и при синдрома „вчера работеше“.
Най-лесния начин, за който се сещам е автоматична бекъпвачка с Ansible.
Попълваме инвентара в текстов файл горе-долу по тоя пример (ios-inventory):
[all:vars]
backup_dest="/ios_backups/"
date_stamp="{{ ansible_date_time.year }}{{ ansible_date_time.month }}{{ ansible_date_time.day }}-{{ ansible_date_time.hour }}{{ ansible_date_time.minute }}"
ansible_connection=local
ansible_user=ansible
ansible_password=na-baba-mi-parolata
ansible_become_method=enable
[sw1]
192.168.0.254
[sw2]
192.168.0.253
[sw3]
192.168.0.252
После създаваме следния ямълски плейбук (playbook.yml):
---
- name: Cisco IOS backup job
hosts: all
gather_facts: yes
strategy: free
tasks:
- name: Collecting remote facts
ios_facts:
gather_subset:
- all
- name: Create backup root folder
file:
path: "{{ backup_dest }}"
state: directory
run_once: yes
- name: Create backup device folder
file:
path: "{{ backup_dest }}{{ ansible_net_hostname }}"
state: directory
run_once: yes
- name: Saving configuration to file
copy:
content: "{{ ansible_net_config }}"
dest: "{{ backup_dest }}{{ ansible_net_hostname }}/{{ inventory_hostname }}-{{ date_stamp }}.txt"
Изпълняваме ето така:
ansible-playbook -i ios-inventory playbook.yml
Добавяйки абсолютните пътища до файловете, тоя ред го мушваме в крон за ежедневно изпълнение и с това връзваме гащите.
Ако имената и паролите за достъп до техниката са различни, то, където е необходимо, променливите с името и паролата ги слагаме на реда с ИП адреса, разделени с интервал.
Ретеншън може да се поддържа с logrotate.
Сега може да си пиете бирата все едно мрежата е архивирана 🙂
Наздраве!
Последни коментари