Изпечатай

[EazySnatch]

Здравейте ,

Тези дни почиствам една машина която е била "хакната" като root достъп не е получен само са качвали разни PHP Shells. Главните сайтове НЕ са готови системи като wordpress / Joomla ...etc. Имат няколко блога които реално са били проблемни.

Какви бяха проблемите:

1. Стари Joomli от 2013г.
2. Нямаше мониторинг на услугите или на ресурсите на системата
3. Нямаше бекъп
4. Няма git/svn за сайтовете

Общо взето много трудно да разбера откъде се е шмугнал дали бот или човек.

Какво съм направил до тук:
1. Ъпдейтнах проблемн и пакети
2. Блоговете и без това не ги ползваха хората решиха да ги спрем вместо да се ъпдейват
3. настроен бекъп
4. Настроен мониторинг на услугите и за системата (CPU ,mem,disk,I/O , Apache, BIND ...etc) всичко което ми трябва да гледам .
5. rkhunter - Няма драми
6. След това започнах с  find / php файлове с различни възможности като:
 6.1 mtime , ctime за промяна по PHP файловете
 6.2 find + grep търся за определени думи за познати шелове
 6.3 find + grep тързя за eval , base64_decode
7. Проверил съм за странни потребители , портове , програми работещи на машината.
8. все още нещо съм направил което пропускам.

След като намерих няколко шела започнах да разглеждам access.log -a на Apache-to ,но не намерих нищо особено просто почистих каквото имаше.

В момента ситуацията е ,че реално ако тези шелчета са били качени от дупка(и) в съмият код на сайата ,а не на блоговете немога да бъда сигурен ,че пак няма да се случи.

Идеи :
Щях да гледам нещата с iwatch всички .php във /var/www което щеше да засмуче РАМ ,но щях веднага да хвана ако се промени PHP  - Само ,че греда   /proc/sys/fs/inotify/max_user_watches неможе да бъде променяно ,защото машината е на OpenVZ (VPS) (не съм го тествал на големи сайтове дали е ОК)

Реинстал на машината няма да помогне ,защото съм сигурен ,че няма root достъп и всичко е в /var/www/ и като кача пак сайтовете всичко ще си остане.

Мисля да настроя един tripwire с определни правила за PHP файловете.

В момента машината може да понесе натоварване важното е да разбера откъде са влезнали. Ако е човек ще влезне пак ако е бот все някога пак ще удари същото място.

Немога да седна да гледам кода на всички сайтове ред по ред ,но мога да хвана поне как влизат ,за да прегледам точно определени файле.

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

[wfw]

Аз лично за старите версии на CMS-и общо взето правя chown root, chmod 755 за директории и chmod 644 за файловете. Една голяма част от файловете не се променят така или иначе от потребителите. После разрешавам на определени директории достъп за писане от уеб потребителя и му спирам PHP-то за тези директории.
Така дори да качат PHP файл, трудно го пускат...

Освен това разните административни директории задължително ограничение по IP, направо в конф. файл на домейна го шибвам...

Това същото предполагам, че може да се приложи и за писан специално за хората сайт.

Може да мъчиш някой модул като mod_security...

[EazySnatch]

Здравей ,

Вече CMS-и няма блоговете ги махнахме

1. owner:group + permissions бяха оправени за всички сайтове.

2. Общо взето имаше една папка "public" където седяха PHP шеловете и след като ги изтрих седнахме с програмиста да изкара всичко което НЕ трябва да е там като темплейти ала бала и забраних *.php от сорта

 <Directory PATH/public>
     <FilesMatch "(?i)\.(php|php3?)$">
            Order Deny,Allow
            Deny from All
    </FilesMatch>
 </Directory>

Имаше пропуск в кода която не правеше проверка какъв файл качваш демек аз си качвам php-to после през URL си го отварям "so simple" ,но това вече е оправено като аз съм се презастраховал като съм спрял PHP-то за public-a.

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

Верно ще взема да погледна mod_security ползвал съм го преди бая време  да видя какви нови глезотийки има.

Мерси

[pennywise]

Аз лично за старите версии на CMS-и общо взето правя chown root, chmod 755 за директории и chmod 644 за файловете. Една голяма част от файловете не се променят така или иначе от потребителите.

Защо им даваш root? Има причина да си има отеделн потребител за уеб-сървъра - ако стане проблем да няма права да изпълняват акаквото си поискат.
Скриптове притежавани от роот могат да правят промени където си поискат.

[EazySnatch]

Сървъра не е мой аз не го администрирам хората никога са нямали администратори просто ме извикаха да помагам поради проблемите си. Мисля ,че това отг. на въпроса ти.

Вече всеки сайт си има потребител и програмиста си влиза от там.

[pennywise]

Въпроса ми беше към wfw - защо прави скриптове който са изпълними през уеб собственост на root?

[jet]

сканирай с nmap за отворени портове и дали нещо не слуша

[EazySnatch]

Вече е направено инспектирах всеки порт и услуга които слишат.

[gat3way]

Абе ей, кой е собственик на PHP скрипта няма нищо общо с това с какви права се изпълнява последния. Ще ви гази трактора за такива съвети да знаете. Щом като файловете няма да се модифицират от уеб приложението, собственикът им е root и точка.

Също така, от гадове до гадове и от мотиви до мотиви има разлика, та не може лесно да се дават такива съвети, но в общият случай, ако изолираш проблема, заради който са се сдобили с локален достъп, па макар с правата на apache потребителя - преинсталирай машината, връщай от бекъпи и запуши проблема. Това някои хора не могат да го разберат, веднъж ескалираш ли си достъпа до superuser-ски, нещата придобиват качествено нови измерения и можеш такива поразии да направиш *лесно*, които трудно ще се разберат без да се инвестира достатъчно време и ресурси в заниманието. Има една такава група системни администратори, обикновено ненагледали се на глупости, които нямат ама никаква идея как работи тази операционна система и силно много разчитат на това което им го вадят стандартните tool-ове и си мислят поради някаква причина че ако нещата не са такива, каквито изглеждат, то имат работа с някакви много зли, лоши хора и извънземни намеси. Съжалявам, ма живеем в 21-ви век. Процеси, файлове, сокети ИЗКЛЮЧИТЕЛНО лесно се крият ако имаш root достъп и можеш да изпълняваш твой си код в kernel mode. И това не е нещо ново, едни и същи изпълнения отпреди 10-15 години продължават да работят. Значи има два варианта - или връщаш от бекъпи върху нова инсталация след като си запушил дупките, или наглееш и ползваш разни hardened пачове за ядрото, MAC дивотии като selinux, които сами по себе си ти превръщат живота в кошмар и честито ако трябва да ги менажираш като хората, особено върху много системи, за повечето от които не си запознат силно с особеностите на софтуера дето търкалят, но да де - така се чувстваш много спокоен. Нищо на тоя свят не идва безплатно, та си избери едно от двете.

[EazySnatch]

root достъп не е имало или както ти каза поне аз не виждам да има.

Наясно съм ,че може да си вкара какви ли код в ядрото и от там да си скрива процеси сокети и какво ли още не ,но общо взето разбрахме ,че е бивш програмист с достъп през web .

Идеята е как да хвана ако по някаква причина направи НОВ php shell  файл някъде в /var/www/SITE

Драснах какво точно съм направил до момента. Идеята за преинсталация я отхвърлих ,защото ако влиза през дупка в сайта и на новата инсталация пак ще влезе ,а вече доколкото съм нясно РУУТ никога не е получавал и да никога пак немога да бъда сигурен.

[gat3way]

Ми ако има , най-вероятно няма да видиш така или иначе, така че спокойно. Сега остава интересното - приемаме че е бивш web developer и напълно не се интересувам от причината, поради която ще тръгне да го прави. Сега ако имаше нормални процеси и се следваше нормална практика, вероятно целият код на сайта се пази в някаква version control система, примерно git. Всяка такава дава някаква възможност да видиш кой кога и какво е commit-вал, а добрите практики са в branch-а дето се deploy-ва всичко да минава след код ревю и тестове, но ОК де - задните му вратички са минали през код ревю и тестове, то не е необичайно, поне ще знаеш все пак върху какво да търсивш. Обаче предполагам че добрите практики и нормалните процеси са отебани в полза very rapid extreme девелопване при което bus factor-а е крив и няма причини някой напуснал да прави сечено на фирмата. Ми да, трудно е тогава. С грепване на разни неща в кода я стане я не стане, не знам. Както казах, нищо не е безплатно и на евтините неща, рано или късно им плащаш цената. Сега цената е някой да хване и да изрови целия код без да има идея кога какво въпросния човек е творил. Което може да е кофти работа. Но пък от друга страна сигурно ще доведе до следване на добрите практики, поне с идеята да не се повтаря.

[EazySnatch]

Вершън контрол няма както и бекъп тоес нямах никаква база за сравнение.

Общо взето мислех да пусна tripwire да гледам за създаване на нови файлове да хвана дали успява да влезне от някъде и да прави shells ,НО той влиза ли от някакъв контролен панел бил той през Hosting , Firm Admin panel или нещо подобно хванаще няма.

[d0ni]

Инсталирай clamav и го пусни да сканира в document root-а. Хваща всички популярни php бози.

[gat3way]

Реално погледнато няма нужда да се появяват нови файлове със зловреден код. Лошият напуснал девелопер може да си е оставил вратичка, която да хваща някакво URL като GET параметър, да го дърпа с fopen()/fgets() (или с curl примерно ако remote файловите операции са забранени) и да го eval-ва, и пак ще си има PHP шел без да се сваля файл. Аз всъщност не знам защо трябва да има от тия идиотски шелове на машината, прекалено шумно е това. passthru($_COOKIE['something']) примерно е просто нещо и може да се набие навсякъде и няма да буди никакви подозрения - уебсървъра не логва кукита, такива лесно се сетват и всичко излиза като нормален HTTP трафик в логовете, не се появяват странни файлове, но въпреки всичко произволни команди се изпълняват.

Интересното е, сигурно има причина да вярвате че казуса е с напуснал човек, но дали е основателна? Може проблемът да е просто в joomla-та или някой неин плъгин там и да се е възползвал съвсем случаен човек. Това второто е по-добрият вариант, защото най-вероятно ползва някаква добре известна дупка там. Ако наистина е варианта с напусналия програмист - лоша работа. Много лоша след като няма vcs някакъв. Кодът трябва да се изрине и да се намери проблема. Има други решения, ама не ги препоръчвам, вариантът да се оплескат доста вероятен така или иначе.

[KPETEH]

Не разбирам защо е тази паника при положение, че са спряни всякакви CMS-и има ограничение през .htaccess, сканирано е с rkhunter, може би и с clamav тук автора вече ще си каже. Може би инсталация на fail2ban и строги политики по отношение на достъп до системата с iptables също ще помогнат. Ако не се доверяваш на clamav може да ползваш сума ти свободни антивирусни, които работят под линукс просто, за да се презастраховаш, ако случайно се съмняваш от резултатите след сканирането. Инсталиране и конфигуриране на modsecurity2 е много добра идея.
В крайна сметка не разбрах има ли някакъв съмнителен достъп до системата след намесата ти ?