OpenWRT factory reset

Днес успях да ресетна паролата на един OpenWRT рутер който Иван Джеферов от BizLabs ми изпрати. Рутера е използван във организация и понеже е пенсиониран никой не му знаеше паролите и как да се влезе във административния интерфейс. Само се видя, че е „нестандартен“ firmware което е синоним на някое от WRT-тата.

За тази цел свързах рутера със кабел към настолния си Мак и се залових. Първото което ми хрумна е да прегледам трафика който излита от и влиза във самото устройство. Отворих терминала и натраках на бърза ръка
sudo tcpdump -Ani en0
което ми позволи да видя какво се случва вътре. Един от пакетите беше към NTP сърврър на OpenWRT което на практика беше това което търсех. А именно – рутера е рефлашнат със OpenWRT.

Етап 2 беше да видя как да сменя паролата. За тази цел рутера трябва да влезе във Failsafe mode и тогава се получава някакъв контрол. Общо взето по време на boot процеса трябва да се натисне един бутон. Проблема е, че рутерите имат още един режим Recovery mode който пак се активира със натискане на същия бутон.

Разликата между двата режима е колосална. Recovery mode на практика инсталира на устройството IP 192.168.0.86 и стартира TFTP клиент който ще дръпне и флашне recovery image. За тази цел компютъра трябва да му се набие IP 192.168.0.66 (ТВЪРДО!) и да се стартира TFTP сървър. Ако по време на tcpdump видите, че IP 192.168.0.86 прави ARP заявки за намиране на 192.168.0.66 значи сте влезнали във този режим. Или сте натиснали бутона много рано след включване на устройството.

Аз обаче не търсех Recovery mode, ами Failsafe mode което просто позволява да се нулират настройките на устройството. След известно количество проба-грешка се установи кога трябва да се натисне бутона за влизане във този режим. Това е приблизително 3-5 секунди след включване на самото устройство. Тогава един от светодиодите започва много бързо да мига което е сигнал, че режима е активиран. За да се възползвате от него обаче трябва да си набиете IP от рода на 192.168.1.10 (ТВЪРДО!) и тогава можете да достъпите устройството под telnet при по-старите OpenWRT или ssh при по-новите на адрес 192.168.1.1

Пробвах ssh, но ми отказа връзка което означаваше да пробвам под telnet. Разбира се се оказа, че на новите macOS няма telnet и се наложи да си го компилирам от сорс:
wget http://ftp.gnu.org/gnu/inetutils/inetutils-1.9.4.tar.gz
tar xvzf inetutils-1.9.4.tar.gz
cd inetutils-1.9.4
./configure
make
cd telnet
./telnet 192.168.1.1

при което ще видите нещо като:

И тук почна голямото брожение как да се нулират настройките. Според горния екран е трябвало само да използвам firstboot за целта. След като го изчаках културно към 10тина минутки, натиснах произволен клавиш и командата ми върна контрол. Изпълних reboot -f и устройството се рестартира. Неочаквано за мен обаче нищо не се случи. И така няколко пъти със различни комбинации със mount_root, без mount_root и т.н.

След малко гугълване видях, че няколко човека се оплакват от същото и единия написа, че се е оправил със изпълнение на следната команда:
mtd -r erase rootfs_data
изпълних я и след рестартиране можех да вляза във устройството през LuCI (уеб интерфейса на OpenWRT) на адрес 192.168.1.1

OpenWRT factory reset

WordPress създаване на потребител през SQL

От доста време ползвам този код за създаване на потребител през базата и никога не ме е подвеждал. Затова сега ще го споделя със вас.

INSERT INTO databasename.wp_users (ID, user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name) VALUES ('999', 'petern', MD5('p@ssw0rd'), 'Peter Nikolow', 'peter@nikolow.me', 'http://peter.nikolow.me/', '2011-01-01 01:01:01', '', '0', 'Peter Nikolow');

INSERT INTO databasename.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, '999', 'wp_capabilities', 'a:1:{s:13:"administrator";s:1:"1";}');

INSERT INTO databasename.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, '999', 'wp_user_level', '10');

Кода създава потребител със ID 999, за да не се омешат със съществуващите. Потребителското име е petern, паролата е p@ssw0rd. Само трябва да замените databasename със истинската база и да го изпълните. Кода е много полезен когато имате пълен достъп до WordPress включително базата, но не можете да влезете защото нямате акаунт. Или ако акаунта ви е със по-ниски права например редактор.

WordPress създаване на потребител през SQL

netboot.xyz

Едно ново бижю на хоризонта:
https://netboot.xyz

След като си го запишете на CD или USB позволява да заредите някъде около 1MB файл. След което всичко останало се дърпа през интернет от официалните им сървъри. Говорим за инсталация на Linux или FreeBSD без наличие на ISO. Ето пълен списък на операционните системи със които идва:
https://github.com/antonym/netboot.xyz

Наличието на подобен инструмент позволява да не се разкарваш със много CDта или USBта из раницата и всичко пак да ти е под ръка. Все пак не всеки може да се разкарва със 30 Линукс дистрибуции със по няколко версии.

netboot.xyz

Ubuntu netboot images

Ако горния трик за Debian netinst ви е харесал ето и netboot изображенията за Ubuntu 19.04:
http://archive.ubuntu.com/ubuntu/dists/disco/main/installer-i386/current/images/netboot/mini.iso
http://archive.ubuntu.com/ubuntu/dists/disco/main/installer-amd64/current/images/netboot/mini.iso
и на 18.10:
http://archive.ubuntu.com/ubuntu/dists/cosmic/main/installer-i386/current/images/netboot/mini.iso
http://archive.ubuntu.com/ubuntu/dists/cosmic/main/installer-amd64/current/images/netboot/mini.iso
и на 18.04 LTS:
http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-i386/current/images/netboot/mini.iso
http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/mini.iso
и на 16.04 LTS:
http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-i386/current/images/netboot/mini.iso
http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/mini.iso

Както казах и преди – аз ги харесвам защото мога да си направя инсталация която цялата да се преточи от-до през интернет и да се използват актуални версии на пакетите. Това което не харесвам във традиционната инсталация със големи ISO файлове е, че дори и да направиш прясна инсталация после половината дистрибуция се обновява след първото влизане което губи време.

Ubuntu netboot images

Debian netinst + netboot images

Да не забравя ето линковете към netinst изображенията на новия Debian:

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.0.0-amd64-netinst.iso
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-mac-10.0.0-amd64-netinst.iso
https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.0.0-i386-netinst.iso
https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-mac-10.0.0-i386-netinst.iso
https://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/debian-10.0.0-amd64-i386-netinst.iso

Ако горните изображения са ви идват малко големи за тестове под виртуалки ето и по-малките изображения (10тократно по-малки):

https://cdimage.debian.org/debian/dists/buster/main/installer-amd64/current/images/netboot/mini.iso
https://cdimage.debian.org/debian/dists/buster/main/installer-i386/current/images/netboot/mini.iso

Разбира се ако имате по-нестандартен хардуер (мрежови карти или дискови масиви) по-малките изображения може и да не ви свършат работа защото не идват със всички налични драйвери. Така устройствата няма да могат да се инициализират и намерят съответно.
Аз обаче си ги харесвам защото всичко се точи по интернет така и след инсталация няма нищо за обновяване.

Debian netinst + netboot images

Как да пренасочиш порт 3000 към 80?

Понякога се налага да се пренасочи порт от едно приложение да отговаря на друг. Най-пресния пример е пренасочване на Ruby On Rails който слухти на порт 3000 да работи на порт 80.

Ето как става:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000

Така със нула промени по конфигурацията вече RoR започва да обработва заявки на порт 80.

Как да пренасочиш порт 3000 към 80?

Enabling HTTP/2 on nginx over Amazon AMI

Една от любимите oперационни системи на Amazon EC2 е тяхната Amazon AMI. Разбира се няма нищо по-хубаво когато производителя на хардуера ти доставя оптимизиран софтуер за него. УВИ има няколко проблема като най-големия е, че отделни модули са доста стари. Това е защото AMI използва някакъв миш-маш от няколко операционни системи – RHEL6, RHEL7 и дори Fedora. Във моя случай nginx е версия 1.8, но за да активирам HTTP/2 се нуждая поне от версия 1.9.5 (докато актуалната е 1.10.1). Разбира се ако изчакам още някой месец може и да ме огрее… но чакам вече година и ми писна. Затова взех нещата във свои ръце и си прекомпилирах своя версия на nginx.

1. Инсталирайте nginx – ще ви спести поне писане на конфигурационни файлове. Конфигурирайте си го по свой вкус.
2. sudo yum install pcre-devel openssl-devel #библиотечки… ще ви потрябват
3. wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz
4. tar zxvf openssl-1.0.2j.tar.gz -c /lib/opt
5. wget http://nginx.org/download/nginx-1.10.1.tar.gz
6. tar zxvf nginx-1.10.1.tar.gz
7. cd nginx-1.10.1
8. ./configure –prefix=/usr/share/nginx –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –http-client-body-temp-path=/var/lib/nginx/tmp/client_body –http-proxy-temp-path=/var/lib/nginx/tmp/proxy –http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi –http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi –http-scgi-temp-path=/var/lib/nginx/tmp/scgi –pid-path=/var/run/nginx.pid –lock-path=/var/lock/subsys/nginx –user=nginx –group=nginx –with-file-aio –with-ipv6 –with-http_ssl_module –with-http_realip_module –with-http_addition_module –with-http_sub_module –with-http_dav_module –with-http_flv_module –with-http_mp4_module –with-http_gunzip_module –with-http_gzip_static_module –with-http_random_index_module –with-http_secure_link_module –with-http_degradation_module –with-http_stub_status_module –with-mail –with-mail_ssl_module –with-http_v2_module –with-openssl=/opt/lib/openssl-1.0.2j –with-pcre –with-pcre-jit –with-debug –with-cc-opt=’-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’ –with-ld-opt=’ -Wl,-E’
9. make
10. /etc/init.d/nginx stop
11. sudo cp objs/nginx /usr/sbin
12. /etc/init.d/nginx start

ВАЖНО! Ако обновление ви презапише по-стара версия на nginx ще се наложи да изпълните точка 9 поне още веднъж. Защото това е един дърт пач върху оригиналния nginx.

Сега вече ако напишете nginx -V ще видите нейде:
nginx version: nginx/1.10.1

Оттук насетне е лесно. Отивате във конфигурационния файл и издирвате това:
listen 443 ssl;
за да го замените със:
listen 443 ssl http2;

Честито! Вече имате работещ nginx със http/2.

Забележка!!! Оригиналния nginx във AMI е компилиран със малко повечко опции. Липсващите са:
–with-http_xslt_module
–with-http_image_filter_module
–with-http_geoip_module
–with-http_perl_module
–with-google_perftools_module
но аз така или иначе не ги използвам тях.

Enabling HTTP/2 on nginx over Amazon AMI

Спиране на спам ботове и линкове във Аналитикс

От няколко години във интернет се подвизава един метод за създаване на трафик към сайт. Говорим за spambot referrers които посещават сайт X като са дошли от сайт Y. По този начин те правят refferer трафик към сайт Х от името на сайт Y. Само администраторите и потребителите на Analytics подобен софтуер (Google Analytics, KissMetrics, Moz Analytics, Piwik, HubSpot Analytics и други) може да го видят уви. Но това са предимно администратори, web програмисти, дизайнери, оптимизатори или самите собственици на сайтове и има голям интерес от тяхна страна. Все пак всеки би се заинтригувал точно как сайт Y ни е линкнал.

Уви този метод не е етичен и напоследък доста се злоупотребява със него във интернет. Сега ще ви покажа прост метод как този спам трафик може да се блокира под Apache, nginx и Google Analytics.

за Apache .htaccess:

SetEnvIfNoCase Referer semalt.com spambot=yes
SetEnvIfNoCase Referer buttons-for-website.com spambot=yes
SetEnvIfNoCase Referer darodar.com spambot=yes
SetEnvIfNoCase Referer 7makemoneyonline.com spambot=yes
SetEnvIfNoCase Referer ilovevitaly.co spambot=yes
SetEnvIfNoCase Referer myftpupload.com spambot=yes
SetEnvIfNoCase Referer econom.co spambot=yes
SetEnvIfNoCase Referer iskalko.ru spambot=yes
SetEnvIfNoCase Referer ilovevitaly.ru spambot=yes
SetEnvIfNoCase Referer ilovevitaly.com spambot=yes
SetEnvIfNoCase Referer o-o-8-o-o.ru spambot=yes
SetEnvIfNoCase Referer o-o-6-o-o.ru spambot=yes
SetEnvIfNoCase Referer cenoval.ru spambot=yes
SetEnvIfNoCase Referer priceg.com spambot=yes
SetEnvIfNoCase Referer cenokos.ru spambot=yes
SetEnvIfNoCase Referer seoexperimenty.ru spambot=yes
SetEnvIfNoCase Referer gobongo.info spambot=yes
SetEnvIfNoCase Referer vodkoved.ru spambot=yes
SetEnvIfNoCase Referer adcash.com spambot=yes
SetEnvIfNoCase Referer websocial.me spambot=yes
SetEnvIfNoCase Referer cityadspix.com spambot=yes
SetEnvIfNoCase Referer luxup.ru spambot=yes
SetEnvIfNoCase Referer ykecwqlixx.ru spambot=yes
SetEnvIfNoCase Referer superiends.org spambot=yes
SetEnvIfNoCase Referer slftsdybbg.ru spambot=yes
SetEnvIfNoCase Referer edakgfvwql.ru spambot=yes
SetEnvIfNoCase Referer socialseet.ru spambot=yes
SetEnvIfNoCase Referer screentoolkit.com spambot=yes
SetEnvIfNoCase Referer savetubevideo.com spambot=yes
Order allow,deny
Allow from all
Deny from env=spambot

вмъкнете горния код някъде във основния код на .htaccess. Ако имате друг лош referrer просто го допишете във списъка.

за nginx:

if ($http_referer ~* (semalt.com)) {return 403;}
if ($http_referer ~* (buttons-for-website.com)) {return 403;}
if ($http_referer ~* (darodar.com)) {return 403;}
if ($http_referer ~* (7makemoneyonline.com)) {return 403;}
if ($http_referer ~* (ilovevitaly.co)) {return 403;}

добавете във конфирурационния файл на виртуалния сървър само тези редове които ви трябват. Ако има друг сървър просто го добавете като конфигурация.

за Google Analytics:

Admin tab > View Section > Filters Add a filter > Custom > Filter Field трябва да бъде Referral Pattern > и прибавяме сайта като www\.domain\.com
или
Admin tab > Property Section > JS tracking Info и прибавяме сайтовете към referral exclusion list

Разбира се това няма да попречи на „Лошите Момчета“ да продължават да се опитват да ви заразят статистиките във аналитикса, но ще ги намали драстично. Винаги трябва да проверявате лог файловете си и аналитикса за подозрителен трафик от сайтове и да реагирате своевременно.

Спиране на спам ботове и линкове във Аналитикс

robots.txt and WordPress

Във предния материал ви показах колко лесно е да се използва WordPress не по предназначение и как да се предпазите от това. Сега ще ви покажа как едно тривиално извикване на robots.txt под WordPress също води до неочаквани резултати, как да му противодействате и още нещо.

Предистория на robots.txt

Имало едно време Интернет и едни сайтове които не били индексирани от никого. На няколко младежа им е хрумнало да направят търсачки които да обхождат денонощно интернет-а и да позволява на потребителите да търсят информация върху вече индексираната информация. Както винаги се случва обаче се оказва как някои страници не трябва да бъдат индексирани и през 1994 се е достигнало до консенсус относно начина по който да става това. Именно тогава се е зародила идеята за robots.txt и неговата спецификация. Тук можете да намерите оригиналната версия на документа. Както виждате няма нищо сложно имаме 2 реда User-agent и Disallow, във първия се описва робота а последващите един или няколко реда описват какво да не индексира. Както може да се забележи стандарта е силно повлиян от Unix и може да се използва # за коментар. През далечната 1996-та година обаче все пак са го вкарали като чернова за IETF и тук е оригинала на документа. Единственната разлика е, че този път е прибавен Allow където се описва изрично какво може да се индексира. Принципа си остава, че всичко което не е забранено е разрешено. В наши дни е широкоразпространено използването на robots.txt във всички сайтове. Едно от първите действия при пускането на сайт е да се настрои правилно robots.txt за да бъде сайта правилно обходен от роботите. Както може и да се очаква почти всички системи за съдържание CMS разполагат със поддръжка на този стандарт. WordPress не прави изключение и е robots.txt съвместим.

robots.txt wordpress example usage

Какъв е проблема със robots.txt под WordPress?

WordPress текущо поддържа 2 режима на индексиране управляващи се от Settings -> Reading Settings:

  • Забрана за индексиране на сайта – използва се когато сайта е във режим на разработка, някакви промени или други причини и съответно не трябва да се индексира. Тогава трябва да се укаже „Search Engine Visibility“ и да бъде избрано.
  • Разрешаване на индексиране на сайта – използва се когато сайта е във работен режим и индексирането му е разрешено. Във този случай „Search Engine Visibility“ не трябва да е избрано.

Единственното което прави тази настройка е да активира във базата данни една опция „blog_public“. Ако е забранено индексирането се връща следния код за robots.txt:

User-agent: *
Disallow: /

и съответно ако е разрешено кода има следния вид:

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/

Горните редове са всичко което ви трябва и се намират във файла wp-includes/functions.php във функцията do_robots. Проблема е, че да се върнат 3 реда се изпълнява сложна комбинация от код – зарежда се целия WordPress като фреймуорк, установява се връзка към базата, правят се няколко запитвания и на финала се връщат 2-3 реда които винаги са едни и същи.

Как можем да подобрим нещата?

Във момента се занимавам по ускоряване на WordPress със създаването на статични файлове и забелязах през административния панел, че виждам всички заявки към robots.txt. Това ме наведе на мисълта, че този файл не съществува реално, а е виртуален и се генерира от системата. Направих проверка и точно така се указа. Във сървъра такъв файл липсва, но през уеб браузър може да го видя. Разбира се всяка заявка към такива виртуални натоварва сървъра и технически е много по-добре да се направи статичен файл robots.txt във основната папка на WordPress и да се сложат вътре следните редове:

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/

Така малко ще ускорим работата на системата като спестим време. При мен условно от около 100 посещения дневно имам приблизително 100 зареждания на файла. Разбира се при вас стойностите може да се различават във зависимост от натовареността на сайта, социалните сигнали и индексирането му.

Има ли минуси при горния подход?

Има три минуса при този подход. Първия е, че повече няма да можем да управляваме файла от интерфейса. Втория е че повече няма да може да се активира това при обновяване на системата или плъгините. Обикновенно докато обновлението тече се забранява достъпа до сайта и когато свърши се разрешава отново. Технически във този период от няколко секунди може да мине бот и няма да индексира правилно страниците. Лично във моя случай това не е толкова фатално защото WordPress връща грешка и търсещата машина така или иначе узнава, че нещо не е наред и ще дойде пак. Третия минус е при използването на допълнителни плъгини за управлението на robots.txt тогава просто повече няма да може да работят.

Може ли да подобрим нещата още повече?

По време на тазгодишната конференция SMXWest имаше отделна секция Meet the Search Engines където за пореден път се изказа мнението, че е добра практика да се разреши на търсещите машини да индексират JS, CSS и други файлове. Още по въпроса можете да намерите SMX West Liveblog. При горния пример за разрешаване това е частично невъзможно, защото самия ядрото на WordPress се намира във горните две папки. Ето защо ако желаете да разрешите на ботовете да индексират целия сайт кода на robots.txt трябва да изглежда ето така:

User-agent: *
Disallow:

Евентуално може да се прибави и още един ред със sitemap съдържащ пълен URL към файла указващ картата на сайта.

Разбира се целите при които аз правя тази кръпка към WordPress относно robots.txt при мен са различни и може да не са подходящи за Вас. Моята цел е да генерирам статично съдържание от WP със цел качване по CDN без да изгубвам контрол върху съдържанието.

robots.txt and WordPress