Ако следите блога ни, малко преди Великден сте видели една новина. Или може и да не сте я видели. Става въпрос за Linux/Cdorked.A - вирус, атакуващ Apache сървъри, по-случайност - най-разпространенитe в интернет.
Дали този вирус касае по някакъв начин сигурността на вашата компания? Въпросът е много на място, защото много потребители и компании, които използват Linux, не се считат за потребители на тази операционна система. Както се оказва обаче, вирусът, посветен на Linux сървъри, работещи с платформата Apache (или Lighttpd или nginx) може да причини много главоболия на не една и две компании, дори и те да не се считат за потребители на Linux.
Всъщност, готови сме да се обзаложим, че Linux играе много по-важна роля дори и в личния ви живот, от колкото може да си представите. Особено, когато става въпрос за фирмения ви уеб сайт (в корпоративен аспект) или в смартфона ви, който работи с Android (ако не знаете, операционната система на Google за мобилни устройства е създадена именно на база Linux). Или дори за DVD плейъра ви, който най-вероятно също използва подобна операционна система. Без да коментираме рутера вкъщи. Или в офиса.
Знаете ли къде се хоства уебсайтът ви? В хостинг провайдър? Или на колокиран сървър? Или на споделен сървър в център за съхранение на данни? Кой го поддържа? Компанията, която го е създала? Ако не сте сигурни, сега е моментът да разберете. И между другото, докато проучвате този въпрос, разберете дали и случайно сайтът ви не е хостнат на Linux платформа.
Що се касае до Apache, платформата има 350 млн. потребителя. Иначе казано, над 350 млн. сървъра по света работят именно с тази операционна система. От 1 млн. най-натоварени уеб сайта, около 60% работят под Apache (по данни на Netcraft Web Server Survey, февруари 2013 г.). И съвсем не е спекулативно да се твърди, че по-голяма част от тези сървъри използват Apache, което работи под някаква вариация на Linux.
Когато говорим за информационна сигурност, Linux и Apache имат репутация на относително сигурни - и като дизайн на самата операционна система, и като метод на инсталация. Ако знаете какво правите, разбира се. Историята помни не един и два примера на хакнати сайтове, работещи под Linux/Apache. В повечето случаи обаче пробивът в сигурността е благодарение на пропуски в PHP и SQL кодовете, а не на дупки в кода на Linux/Apache. Днес атаките срещу тези машини се осъществяват на няколко фронта, сред които заразени Apache модули, слаби администраторски пароли и дупки в приложения като cPanel, Plesk, Joomla, Drupal и WordPress. А към тях можем да добавим и добрите стари PHP и SQL атаки.
Между другото, ако мислите, че компанията ви не използва PHP и SQL, сега е моментът да помислите отново. Като за начало, всички WordPress сайтове използват PHP/SQL. А над 60 млн. сайта разчитат именно на тази платформа за управление на съдържание. Акронимът LAMP се използва често, за да опише екосистемата с отворен код - Linux, Apache, MySQL, PHP. И да, с LAMP може да се създаде наистина сигурен уеб сървър. Ако не знаете какво правите и как го правите обаче, може да станете жертва на атаки.
Защо "лошите" искат вашата LAMP машина
Преди да разгледаме няколко конкретни примера с проблеми в сигурността на Linux системите, които се появиха на бял свят наскоро, не е лошо да разберем защо "лошите" непрекъснато атакуват подобни машини. В "добрите стари дни" хакването на уеб сървъри се случваше най-вече с цел обезобразяване на уеб сайтове, което водеше до опозоряване на собственика на сайта - какъвто беше случая с обезобразяването на сайта на ЦРУ през 1996 и 2011 г.
В наши дни хакването на определен сайт се използва най-вече като платформа за осъществяване на атаки срещу крайни потребители, които вярват на самия уеб сайт. Разбира се, ако на хакнатия сървър могат да бъдат открити и откраднати лични данни или друг тип важна информация, тя също може да продадена или използвана за облага на хакера, което също е повече от достатъчен мотив за осъществяване на атака. И все пак, ето някои основни причини за осъществяване на атака именно срещу сървър:
- Той е винаги включен. Природата на уеб сървъра изисква той да бъде включен непрекъснато, за разлика от домашния или служебния компютър. Обикновено, уеб сървърите се намират в центрове, в които е гарантирано дори и резервно захранване. Като цяло, те са имунизирани срещу спирането на тока. Но са програмирани да се рестартират в случай на подобна ситуация - а именно, прекъсване на електрозахранването. Това ги превръща в идеална цел за осъществяване на нелегални дейности, които изискват денонощна процесорна мощ. Подобни дейности включват осъществяване на DDoS атаки, разпространяване на различни вируси, които осъществяват финансови измами, спам, кражба на лични данни и т.н.
- Той е рядко посещаван. Случвало ли ви се е (на вас или компанията ви) да стартирате уеб проект, който да прекратите? Сигурни сме, че много хора са го правили, което от своя страна е причина за създаването на огромно количество слабо поддържани и администрирани уеб сървъри, за които не се грижи почти никой. Тази липса на внимание се означава и по-бавно време за реакция в случай на пробив в сигурността на съответния сървър.
- Той е с добра свързаност. Повечето уеб сървъри са с гарантирана свързаност с интернет на доста по-добри нива, отколкото който и да било краен потребител, за да се правят с големия трафик, който евентуални би трябвало да поемат. Това е допълнителен чар за атакуващите, които могат да използват този капацитет на връзката за доста незаконни неща.
Влиянието върху бизнеса ви
Ако все още не ви се врява, че уеб сървърът ви е потенциална цел за атака, то погледнете файла по-долу. Това е лог (запис на случващото се със сървъра) на типичния сървър, който се използва за хостване на сайтове за малки бизнеси или неправителствени организации. Не е необходимо да сте Linux експерти, за да видите, че някой се опитва да достъпи до сървъра, като въвежда грешна парола през интервал от 2 секунди в 5.30 часа сутринта: 
Атакуващият или по-скоро скриптът на атакуващия се опитва да проникне в сървъра чрез нестандартни портове (51091, 51549, и др.). Понякога точно тези портове се използват от системните администратори за забрана на SSH достъп, за който обикновено се използва порт 22.
Имайте предвид, че този лог не е от сайт на голям електронен магазин или корпорация, а виртуален частен сървър за сайт на малка компания, какъвто предлагат големите доставчици от сорта на GoDaddy, HostGator и 1&1 Internet (както и повечето български хостинг компании). Атакуващият най-вероятно няма идея каква точно информация може да открие на съответния сървър, но се опитва пробие защитата му, за да използва процесорната му мощ или капацитета на интернет връзката му за незаконни цели.
Дори и да не успят да разбият защитата на сървъра, по този начин атакуващите могат да забавят уеб сайта ви, което е неприятно - особено, ако развивате бизнес през него. Ако атаката все пак успее и хакерите се сдобият с достъп до сървъра ви, последиците ще са още по-неприятни. Така например, сайтът ви може да бъде замразен или блокиран от уеб браузърите, които вече идват със съвременни методи за защита. Което със сигурност означава значителни разходи за разрешаване на проблема, дори и да разполагате с резервно копие на информацията. В противен случай, може да очаквате няколко извънбюджетни разхода за връщане на нещата там, откъдето някога сте започнали. (Не може да разчитате на просто възстановяване на сървъра от автоматичен бекъп, тъй като нямате 100% сигурна информация кога е осъществена заразата).
А ако не обръщате внимание на този сървър, евентуално уведомление от страна на доставчика на хостинг услугата може да е първото съобщение, от което да разберете за атаката. Или може би гневни обаждания от потребители, които не могат да достъпят сайта ви, тъй като е блокиран от браузърите им. Всички тези сценарии са доста кошмарни за всяка организация, която разчита на сайта си, за да развива бизнес.
Проблеми в LAMP-ландия
Говорейки за примери, не можем да подминем и няколко големи атаки, които засегнаха доста по-мащабни организации, използващи Linux/Apache машини. (Едно важно уточнение: Нито Linux, нито Apache са виновни за тези пробиви, те са просто операционна среда, която в момента е доста интересна и проучвана от киберпрестъпниците).
Банкови DDoS атаки: непрекъснато увеличаващите се DDoS атаки срещу американски банкови сайтове, започнали през септември миналата година, са дело именно на компрометирани Linux/Apache уеб сървъри, обединени в ботмрежата Brobot. В последствие, атакуващите създадоха няколко други подобни ботмрежи. Цялата операция е известна с името Операция Абабил (Operation Ababil). Обикновено компрометирането на сървъри се осъществява чрез Joomla или WordPress, чрез "незапушени" пробиви с сигурността или чрез метода брут форс (непрекъснати опити за логин в сървъра използващи списък с предварително дефинирани пароли). За момента Ababil е класически случай на хакване на уеб сървъри за използване на процесорната им мощ и връзката с интернет, а не толкова за кражба на наличната на тях информация.
Darkleech или Chapro: През декември миналата година анализатори на ESET публикуваха детайлен анализ на вирус за Linux/Apache, наречен Chapro и познат още като Darkleech. Инфекцията засегна над 20,000 сървъра за по-малко от 2 седмици и напомни на системните администратори, че поддръжката на Apache сървърите е по-важна от всякога. (За да сме напълно точни: този вирус не използва пропуск в сигурността на Apache, а инсталира модул под Apache, с други думи - сървърите се използват, за да разпространяват вируси, а не фалшиви модификации на Apache.)
WordPress Brute Force ботмрежа: Както отбеляза Дийн Валант от най-големия американски доставчик на хостинг услуги HostGator, "някой създава най-голямата ботмрежа от WordPress инсталации чрез брут форс атаки." "Докато пиша това се осъществява глобална атака срещу множество WordPress инсталации, инсталирани на най-различни хостове. Атаката е добре организирана и много, много добре разпространяваща се. В нея участват над 90,000 IP адреса," казва той. Дългосрочната цел на атаката все още не е ясна, но тя показва до каква степен уеб сървърите могат да бъдат атакувани през такива широко разпространени платформи.
Linux/Cdorked: Наскоро изследователите на ESET публикуваха технически анали на Apache вирус, наречен Linux/Cdorked.A - наистина сложен и потаен бекдор вирус, чиято цел е генериране на трафик към заразени уеб-сайтове. Рискът за организациите, използващи Apache, Lighttpd или nginx за уеб сървърите си е следният: блокиране на уеб сайтовете им, които те видимо са използвани от система за разпространение на вируси. В този смисъл, бекдор означавам, че част от кода на сървъра (в случая httpd) е била променена, за да изпълнява зловредни дейности. Системните защити като Tripwire би трябвало да засичат този проблем, но инфекцията може да бъде използвана за повод за повдигане на въпроса до колко подобни системи се използват. Затова, препоръчваме да проверите дали и вашият сървър не е сред заразените. Как може да стане това - вижте тук.
Как да се защитим от атаки
За да се избегне превръщането си в жертва на тази нова вълна от атаки, вземете предвид следните действия: 1. Оценете: Има ли шанс да използвате Linux/Apache сървъри? Къде се намират? Кой ги управлява? Каква е тяхната функция? Колко ценни са те за вашата организация? Какви мерки за защита прилагате за защитата им? Кой може да ви помогне да ги защитите?
2. Създайте политики. Направете така, че защитата на вашия/те Linux/Apache сървъри да е политика и дефинирайте как точно да стане това. Възложете това като отговорност на служител в компанията ви.
3. Изберете методи за контрол. Решете кои са най-подходящите мерки - например, ограничаване на достъпа до сървъра до определени IP адреси. Или двуслойна защита? Или софтуер за антивирусна защита на сървърите ви?
4. Въведете мерките в действие. Използвайте квалифицирани (знаещи и можещи) хора, които да приведат мерките в действие. Много от горе-описаните стъпки могат да бъдат намерени на из интернет. Въвеждането на не малка част от тях обаче изисква специфични познания.
5. Обучете персонала си и доставчиците на услуги. Направете така, че всички, участващи в управлението на уеб сървъра и съдържанието на него да са запознати с въведените ограничения и отговорностите им по опазването на сигурността/
6. Продължете с оценки, одити и тестове.