Menu

Hello and welcome to #root.bg!

Here you can find tutorials about linux, networks and their firewall, games and fun, as well as hobbies – rollers, drones and many more.

Ако искате да помогнете за развитието на root.bg

моля направете го от бутона тук!
Почерпи ме!

apache symlink protection for cPanel

, , , , 0

Привет,

Днес ще пиша за един наболял за мен проблем свързан с толкова омразното apache и проблема му със symlink защитита. Оказва се че при apache 2.2 такава защита по подразбиране няма. Има опция която може да се пусне : -FollowSymLinks , но тя лесно може да бъде заобиколена, от слагането на един прост .htaccess файл със следните неща:

Options all
Options +Indexes
Options +FollowSymLinks
DirectoryIndex Sux.html
AddType text/plain .php
AddHandler server-parsed .php
AddType text/plain .html
AddHandler txt .html
Require None
Satisfy Any

Проблемът:

apache-symlink

А проблема в случая е следния. Имаме cpanel сървър и много умрели Joomla и wordpress сайтове пълни с какви ли не стари и по-стари темплейти и плугини.
Някой псевдо хакер намира дупка в тях, и качва така накеченият експлойт (по-долу ще го покажа)
След като го стартира, самият експлойт прави symlink на всички home директории и на главната / . С опциите пуснати по-горе (+Indexes и +FollowSymLinks) хакерът вече може съвсем спокойно да си разцъка из директориите на другите потребители и да разгледа техните конфиг файлове на сайтовете. Тук е ясно какви могат да бъдат последствията.

Аз много съжалявам, че на тези наши сървъри apache-то още работи, но докато от Cpanel.net не накарат WHM/Cpanel да работят изцяло с nginx и php5-fpm примерно, ще имаме тези проблеми. Само да вметна , че за nginx има една проста опция :

disable_symlinks on;

която оправя този проблем…. но когато използваме nginx пред apache само за прокси, трябва да търсим решение на проблема в самото apache.

Решението:

Решението се оказа доста просто, но беше необходимо време докато го намеря.
Изпълнява се следният код :

wget http://layer1.rack911.com/before_apache_make -O /scripts/before_apache_make
chmod 700 /scripts/before_apache_make
/scripts/easyapache

След това може да се тества и да се види, че проблема вече не съществува! 🙂

Ето линк с експлойт-а , като тук искам да подчертая, че го качвам само за да се тества, не да се правят злонамерени неща с него!

Успех!

Raspberry Pi Wireless 3g Router

, , 0

Здравейте,

Днес ще споделя как през уикенда намерих малко свободно време и си направих Raspberry pi wireless 3g router – или намерих приложение на едното ми излишно Pi 🙂

Raspberry Pi Wireless 3g Router

Първо ще кажа че има много по-лесни начини да имате 3G рутер – продават се сполучливи модели на Tp-link , но аз исках да си го направя сам 🙂

За целта използвах Raspberry Pi модел B+ с 5.25 волта и 2 амперово захранване , Wifi Nano USB Dongle и usb 3G модем от Mtel

Инсталирах raspbian и след това сложих 3G модема и Wifi адаптера. Уверих се че PI-то ги засича :

Още..

auth_pam: pam_authenticate failed: Authentication failure

, , , , , 0

Привет,

Искам да споделя за един проблем който ме мъчи от сигурно половин година, свързан с един saslauthd демон.

Навремето имах един стар дебиан с ISPconfig и courier-imap. След време трябваше да ъпгрейдна сървъра, като го направих на виртуалка с ubuntu 12.04 и реших да заменя courier-a с dovecot. Обаче там се объркаха едни схеми, и за да оправя положението отново върнах courier-a.

От тогава обаче всеха да се случват странни неща при опит да се изпрати мейл, неща от типа на :

 

SASL LOGIN authentication failed: authentication failure

В този си му вид лога не ми говори нищо, и за целта добавих в /etc/pam.d/smtp “debug” и почнах да дъбъгвам. И както писах в предния пост по темата реших проблема временно с рестарт на saslauthd-то.

Да обаче днес оправих проблема напълно!
За целта реших тотално да се отърва от saslauthd, и да използвам courier-authdaemon-a.
Първо направих следната промяна в /etc/postfix/sasl/smtpd.conf
Замених pwcheck_method: authdaemond вместо pwcheck_method: saslauthd
Замених authdaemond_path: /var/run/courier/authdaemon/socket вместо saslauthd_path: /var/run/saslauthd/mux

Спрях saslauthd и пуснах courier-authdaemon.
След това направих следната схема :

/etc/init.d/courier-authdaemon stop
rm -rf /var/run/courier/authdaemon/
rm -rf /var/spool/postfix/var/run/courier/authdaemon/
mkdir -p /var/spool/postfix/var/run/courier/authdaemon/
ln -s /var/spool/postfix/var/run/courier/authdaemon/ /var/run/courier/authdaemon
/etc/init.d/courier-authdaemon start
/etc/inti.d/postfix restart

И воала! Нещата придобиха дормалният си вид и всичко си проработи както трябва!

Извода, има бъг в pam модулите, в http://wiki2.dovecot.org/PasswordDatabase/PAM пишат да се използва директивата pam_maxrequests за да се избегнат подобни проблеми, но аз реших кардинално да си реша проблема.

При другите ми мейл сървъри които използват dovecot и saslauthd нямам подобни ситуации, и заради това мисля че всичко се обърка заради първоначлното инсталиране на dovecot и модулите му и след това courier.
Аз винаги съм използват howto-тата от howtoforge.com и не съм имал проблеми, но в случая мисля че сам си създадох моя 🙂

debug website’s load time with strace

, , , , 0

Хелоу,

В работата ми като системен администратор, често се налага да помагам на девелопърите в дебъгване на ситуации с бавно зареждащи уеб сайтове. Като изключим факта че сме проверили дали всичко по сървъра е наред, дали другите уеб страници на самата машина зареждат добре, а конкретния уеб сайт зарежда 10 пъти по-бавно от другите, в този случай използваме за помощ – strace.
debug website's load time with strace

Това е много полезна програма с която дебъгваме примерно index.php-то на конкретния сайт, и в лога който ще запише програмата можем да видим в timeline кога какво се стратира и зарежда и къде идва и разликата в секундите и съответно къде е проблема в кода.

Чрез командата :

 

strace -t -f -o strace.txt /usr/bin/php index.php

Ние ще направим точно това което съм написал по-горе и резултатите можем да ги прочетем после в strace.txt лога.

Резултатите са нещо от рода на :

1727 10:31:38 fcntl(4, F_SETFL, O_RDWR) = 0
1727 10:31:38 sendto(4, "GET /feed/ HTTP/1.0\r\n", 21, MSG_DONTWAIT, NULL, 0) = 21
1727 10:31:38 sendto(4, "Host: www.tips.website"..., 42, MSG_DONTWAIT, NULL, 0) = 42
1727 10:31:38 sendto(4, "\r\n", 2, MSG_DONTWAIT, NULL, 0) = 2
1727 10:31:38 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 0 (Timeout)
1727 10:31:38 poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=4, revents=POLLIN|POLLERR|POLLHUP}])
1727 10:31:59 recvfrom(4, 0x7faf915a8b10, 8192, 64, 0, 0) = -1 ECONNRESET (Connection reset by peer)
1727 10:31:59 close(4) = 0
1727 10:31:59 socket(PF_FILE, SOCK_STREAM, 0) = 4
1727 10:31:59 fcntl(4, F_SETFL, O_RDONLY) = 0
1727 10:31:59 fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
1727 10:31:59 fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
1727 10:31:59 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
1727 10:31:59 connect(4, {sa_family=AF_FILE, path="/var/lib/mysql/mysql.sock"}, 110) = 0

От всичкия лог, най-важното за нас е разликата в секундите – 21 секунди. Тук идва и проблема – самият сайт се зареждаще за около 20-25 секунди. И в крайна сметка се оказа че, в конфигра му беше зададен грешен url към несъществуващ хостнейм (www.tips.website…), и забавянето идваше от факта че , самият сайт се опитваше да го резолвне и не успяваше.

Load More