Още една халба с акъл… Наздраве!
Паролата за отдалечен достъп до Уиндоус (Windows Remote Desktop) компютър може да се съхрани в RDP файла, който бихме могли да ползваме, като шорткът. Така няма да бъдат искани никакви креденшъли при влизане. Добавя се следния ред:
password 51:b:encrypted-password
Паролате е кодирана с инструментчето cryptRDP5. Изпълнява се в командния ред:
> cryptRDP5.exe mega-password
01000000D08C9DDF0115D1118C7A00C04FC297EB010...Интернет е пълен, даже направо фрашкан с адреси бълващи спам, сканиращи ботове, заразени устройства и какви ли още не безполезни генератори на трафик.
Аз не бих ги пуснал до мой сървър. Лесен начин да се оттървем поне от познатите такива съм публикувал тук.
Това е прост баш скрипт, който изтегля публичен списък с лоши адреси и създава iptables плравила, които да издропят трафика идващ от тях.
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
Наложи ми се да копирам големи файлове от уиндоус към линукс през SSH. Обикновнео ползвам WinSCP за подобни дейности. За малки файлове или отдалечено редактиране е приемливо и удобно, но когато стане дума за много гигабайти – по-скоро не. Проблемът му е, че дори при достатъчно бърза връзка, скоростта на копиране пак се колебае между 1 и 3 МВ/с. Ползвайки последната към момента версия.
В чудене и безброй проби с подреждания и размествания на крипто алгоритмите на клиента и на сървъра, в крайна сметка стигнах до най-бързото решение (за мен). Уловката е, че е линукс-линукс. В уиндоус вероятно с cygwin може да се измисли нещо, но нямам доказателства.
Самото копиране:
tar -zcvf - /path | ssh user@1.2.3.4 "cd /tmp && tar -zxvf -"
Това ще вземе директорията /path и ще я излее на 1.2.3.4 в /tmp. Явно да се прекара през тарване и зипване дава положителни резултати.
ldapmodify е основен инстурмент с който могат да се редактират обекти в една активна директория (АД) посредством *nix среда.
За едно сравнително популярно действие, като смяна на парола, обаче нещата не са толкова лесни, или поне на пръв поглед не са. Смяната на паролата в LDIF формат изглежда така:
dn: CN=Testi Testev,OU=Users,OU=Accounts,DC=corp,DC=local
changetype: modify
replace: userPassword
userPassword: SlivovSladoledKомандата се изпълнява успешно и редактира съответния атрибут, но ефект от това няма. Т.е. никаква парола не сме сменили.
Оказва се, че в 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 е страхотен инструмент, с който, ако не се внимава, може напълно и завинаги да бъде сасипана една Активна Директория.
С конфигурацията на 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
Както всички телефони, и моят се препълни със снимки и клипове.
Включвам го с УСБ кабел към компютъра и започвам да копирам. По най-стандартния уиндоусовски начин – копи от телефона, пасте на диска на компютъра. Да, ама върви със скорост все едно през телефонна линия го правя. Беше късно, не ми се занимаваше, реших да го оставя да се изкопира през нощта. На другия ден поглеждам какво става и за около 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-131B32GB-товата ми 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, с която пък могат да бъдат копирани файлове в другата посока – към телефона.
Наздраве!
Има един инструмент, който почти бях забравил – 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."
Маршрутизаторите и комутаторите също имат нужда от архивиране! Не че това ще направи подмяната на изгорял рутер удоволствие, но ще е значително по-лесно. А и решението е почти контрол на версиите – с един 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.
Сега може да си пиете бирата все едно мрежата е архивирана 🙂
Наздраве!
Ще използваме minimal образ на Ubuntu 20.04 LTS, защото е изключително малък и ще бъде лесно да бъде изпратен на бай Иван.
Образа е наличен тук.
Отваряме ISO-то и редактираме txt.cfg. Той би трябвало да съдържа следните редове:
label install
menu label ^Install
menu default
kernel linux
append vga=788 initrd=initrd.gz --- quietappend vga=788 initrd=initrd.gz console-setup/layoutcode=us locale=en_US.UTF-8 keyboard-configuration/layoutcode=us languagechooser/language-name=English countrychooser/shortlist=BG localechooser/supported-locales=en_US.UTF-8 hostname=ubuntuserver domain=local interface=auto url=http://kamenitza.org/files/preseed.cfg ipv6.disable=1 ---
Нещата, които този ред върши са сравнително ясни и самообясняващи се. По-интересни са
Ако в мрежата няма DHCP сървър и IP-то трябва да се настрои ръчно, interface=autо се замества със следните примерни параметри:
netcfg/get_ipaddress=192.168.150.111 netcfg/get_netmask=255.255.255.0 netcfg/get_gateway=192.168.150.1 netcfg/get_nameservers=8.8.8.8 netcfg/disable_dhcp=true
За редакция на ISO файл в Уиндоус няма особено работещи безплатни програмчета. Аз ползвах WinISO, което в триал/демо режим върши работа за малки образи.
По наша преценка се прави бутваща USB флашка (с Rufus) или CD или DVD.
Горещо препоръчвам ползването на възможно най-пълен preseed.cfg, за да се елиминира ръчния труд при повторно изпълнение на задачата:
d-i preseed/early_command string anna-install network-console
d-i debian-installer/locale string en_US.UTF-8
d-i localechooser/supported-locales multiselect en_US.UTF-8
d-i console-setup/ask_detect boolean false
d-i keyboard-configuration/layoutcode string en
d-i anna/choose_modules string network-console
d-i network-console/authorized_keys_url string http://kamenitza.org/files/ssh-key.txt
d-i mirror/country string Bulgaria
d-i mirror/http/hostname string bg.archive.ubuntu.com
d-i mirror/http/mirror select bg.archive.ubuntu.com
d-i mirror/http/proxy string
d-i passwd/user-fullname string Todor Kandev
d-i passwd/username string tkandev
d-i passwd/user-password-crypted password $5$ceFBePtE$n0S0.mW1tQQUYH4RPfshNIWd/vilV3E2NhBkUWk/yd0
d-i clock-setup/utc boolean false
d-i time/zone string Europe/Sofia
d-i clock-setup/ntp boolean true
d-i clock-setup/ntp-server string bg.pool.ntp.org
d-i pkgsel/update-policy select none
d-i apt-setup/services-select none
d-i apt-setup/universe boolean true
d-i tasksel/first multiselect standard system utilities, OpenSSH server
d-i preseed/late_command string \
in-target mkdir -p /home/tkandev/.ssh; \
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIN1hQH5HHB8U2PUbUn7nwYUHm0jdz3URoFdYZY1+QSVk kandev-v2" > /target/home/tkandev/.ssh/authorized_keys; \
in-target chown tkandev:tkandev /home/tkandev/.ssh -R; \
in-target sed -i s/#PasswordAuthentication\ yes/PasswordAuthentication\ no/g /etc/ssh/sshd_config; \
apt-install mc net-tools
d-i finish-install/reboot_in_progress notemkpasswd -m sha-256
Сега бай Иван трябва да буутне сървъра с нашия имидж и да избере опцията за инсталация по подразбиране. След няколко минути всичко спира на следния екран:
Може да си знаем адреса, а може и бай Иван да ни го изпрати по някакъв начин. Инструкциите са ясни. Свързваме се с дадения IP адрес по SSH с потребител installer, като се автентикираме с личния си ключ. Довършваме инсталацията с всичко, което липсва от preseed фйла.
Наздраве! 🙂
Ползвал съм собственоръчно направени НАС-ове, било то полу-готови с Freenas, изградени от стандартна Linux дистрибуция или напълно готови хардуерни решения, за които съм писал и преди. В крайна сметка най-доволен останах от Synology. Не защото е перфектно, а защото има най-малко проблеми и бъгове.
Разбира се че е пълно с бъгове! Пакетът му с основни приложения е абсолютен качамак! Нито снимките можеш да си архивираш по някакъв полезен начин, нито файловете. Но целта на поста не е да правя ревю на продукта, а да споделя един особено дразнещ и неприятен дефект.
Притежавам един от малките модели – DS218+. Машинката е закачена за APC UPS, има и комуникационен кабел между нея и UPS-a, за да ѝ е по-ясно каква е ситуацията с тока. Включена е 24/7, като е разрешено единствено да гаси дисковете, ако не се ползват известно време.
Няколко пъти намирам НАС-а загасен. Ама все едно съм му натиснал копчето и се е изключил. А още по-неприятното е, че не може и да се включи. След натискане на бутона, светва, развърта вентилатора, но не развърта дисковете и след 10сек се изключва отново. После пак натискам бутона и стискам палци. И така понякога от 5-тия, понякога от 10-тия опит, вземе, че развърти дисковете и тръгне.
Актуализирах софтуера. Сканирах за грешки. Проверявах захранващия блок. Не открих проблем.
Единствената закономерност, която открих е, че, ако извадя единия или и двата диска, след като се е самозагасил, и натисна копчето, зарежда веднага. Не открих в Интернет някой да е писал за дискова несъвместимост, а и ползвам доста стандартни дискове – 4TB HGST (HDN726040ALE614).
Все още не се предавам и не звъня в гаранционния сервиз за рекламация!
След поредната проверка на конфигурацията и търсене на скрити детайли или каквито и да е улики за проблема из интерфейса на устройството се натъквам на следната опция:
Естествено това беше включено. Даже кой би си помислил, че такава екстра няма да си я има бай-дизайн вградена и ще се налага ръчно да я пускаш и спираш!?
Ами изключих я и проблемите изчезнаха! Вече повече от година не се е самоизключвало.
Наздраве!
Натъкнах се на неочаквана мотика при комуникацията от контейнер към самия себе си, но през публичния му адрес.
Очаквано тук трябва да се случат някои гимнастики с iptables, за да има двупосочна транслиране, известно още като nat reflection или hairpin nat. Да, обаче пак не работи!
В крайна сметка се оказва, че Docker си прави всичко сам, ама само, ако си поискаме 🙂
Вградената userland proxy услуга трябва да бъде спряна, за да се получи това, което желаем, а именно, ако контейнера ни е с адрес 172.17.0.2, който от Интернет е достъпен на 70.80.90.100, да можем от самия контейнер да се свържем към адреса 70.80.90.100 и това да бъде правилно транслирано от хоста обратно към контейнера.
На кратко:
Създаваме файл /etc/docker/daemon.json със следното съдържание:
{
"userland-proxy": false
}
systemctl restart docker
# sysctl net.ipv4.conf.docker0.route_localnet
net.ipv4.conf.docker0.route_localnet = 1
Като млад, зелен и бесен метъл пишех разни щуротии на Паскал и Делфи. Прости инструментчета или шеговити програми от сорта на тази в чиято памет е този пост. Писана е някъде 1999-2000-та година – сиреч преди ДВАЕСЕ години! Т.е. аз съм вече чичка…
Компютъра ми по онова време беше Cyrix 6×86 PR166 с 16MB RAM и чернобял монитор. Уиндоуса беше ’95, а линукса – Red Hat 5 (Hurricane) с ядро 2.0. Най бързата връзка с Интернет беше 2.5КБ/с през домашния телефон на дядо ми и съм чакал по цяла нощ, за да сваля новата песен на Гуано Ейпс от Напстера…
Качвам си играта ТУК, да ми седи за спомен, че хостинга на официалния ѝ сайт фалира преди години. Бахур Хак Тийм също се оказаха няк’ви несериозници…
Хав фун! 😉
Онлайн скенерите, с които Интернет е претъпкан са основна отправна точка за “втвърдяването” (hardening) на всеки уеб сървър. Много от препоръките, които дават са ясни, точни и лесни за изпълнение. Голяма част от тях обаче правят така, че някои уеб страници спират да работят или в най-добрия случай започват да се държат неадекватно.
Едни от най-популярните са internet.nl и ssllabs.
ServerSignature Off
ServerTokens Prod
Header set X-Frame-Options: "sameorigin"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer"
Header set X-Content-Type-Options: "nosniff"
SSLStrictSNIVHostCheck On
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
SSLOpenSSLConfCmd DHParameters /etc/apache2/dhparam
Options -Indexes -FollowSymLinks
SSLProtocol TLSv1.2А следното трябва да фигурира в конфигурацията на всеки виртуален сайт:
SSLProtocol TLSv1.2
Protocols h2 http/1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"Изтегляне на правилните Дифи-Хелман параметри (файла вече сме го посочили по-горе):
curl https://ssl-config.mozilla.org/ffdhe4096.txt > /etc/apache2/dhparam
Изтеглянето на този файл наистина е важно и има значение. По последни данни саморъчното генериране на DH е пълна скръб и не трябва да се практикува. Задълбано инфо по темата има тук.
Примера е за Апач, но хедърите са същите какъвто и да е уеб сървъра. Разлика има единствено в това, как се подават в конфигурацията.
Що пък да не си направим LAMP (linux+apache+mysql+php) в докер контейнер?
Започнах с Alpine Linux, като един от най-подходящите за подобни цели, но се оказа че пакета на Апач има редица проблеми, а и разнообразието от готови допълнителни пакети е леко бедно и щеше да се наложи ръчна компилация на това-онова.
В крайна сметка се спрях на последния наличен Ubuntu Server, който към този момент е 18.04. А до няколко дни ще излезе 20.04 и ще актуализирам.
Готов контейнер качвам в Docker Hub. А изходния код и рецептата за забъркване, в Github.
На кратко:
Ще се радвам, ако свърши работа и на някой друг, освен мен 🙂
Последни коментари