Злом сервера на хостингу архів - форум про інтернет-маркетингу

Чекаємо реакцію і виправдання хостера.

ага, ось так прям взялися сервак ваш ламати турецькі хакери, ось сиділи собі готувалися півроку і взялися ламати? А давайте як вгадаю, движок у поломаних сайтів джумла або з виразника скачаний Дле. Все банально і просто. Скрипт і баги халявних движків))
А Ви реакцію хостера, виправдання рег ру, Ви батенька ще компенсація в стотищтятсот рублів з хостера запросите за моральну шкоду
Оновлюється ПОТРІБНО І 777 позакривати

Мабуть схожа тема вже є! Поспішав повідомити погану новину - а тут вже мінусувати почали фріки якісь.

схожа ситуація вже була у інших хостерів.

Причиною уразливості стало морально устарешая версія програмного забезпечення одного з сайтів на сервері, в яке арабські хакери впровадили свої скрипти. Результатом виконання шкідливого коду була зміна індексних файлів в кожному еккаунті сервера.

Хостинг-компанія ннастоятельно рекомендує всім блогерам, які використовують платформу Joomla або WordPress, негайно оновити їх до останньої версії. Інакше їх також може спіткати така доля.

Компанія заспокоює своїх клієнтів, і повідомляє що вжито всіх заходів щодо якнайшвидшого відновлення сервера і запобігання повторних атак. В даний час велика частина індексних файлів відновлена і сервер S2 працює в штатному режимі, а сайти клієнтів поступово відновлюють роботу. Компанія UAhosting просить не турбуватися і трохи почекати, якщо у вас сайт все ще не працює.

Провести оновлення зазначених CMS можна в автоматичному режимі. Якщо ж не вдається оновити Wordpress автоматично, потрібно відредагувати файл wp-config.php відповідно до вказівок на сторінках форуму.

Якщо ви не хочете вникати в налаштування файлу wp-config.php. можете оновити WordPress вручну - просто переписавши файли нової версії поверх старих файлів по протоколу FTP.

Це ще раз говорить про важливість дотримання мережевої безпеки і необхідності регулярного оновлення популярного програмного забезпечення.

Використовую ліцензійні движки! злом саме всіх сайтів на ip 87.242.73.209

Використовую ліцензійні движки!
Розмова не про те що ліцензію купити потрібно, а про те щоб оновитися і позакривати на запис все що можна

Розмова не про те що ліцензію купити потрібно, а про те щоб оновитися і позакривати на запис все що можна

В даному випадку не допоможуть ні ліцензії, ні оновлення, приблизна схема наступна:

PHP працює в режимі DSO (у апача), на сервері живе юзверя з CMS старих типів (наприклад Joomla 1.0), або в ручному режимі або використовуючи ботів знайшли цей сайт, через XSS (та інше) заливається ряд скриптів, ті (через exec ф ції) заливають бінарник і запускають його в / tmp, бінарник є екслоітом (бекдоров і т.д. на вибір), далі в залежності від ряду факторів (версії, наявність патчів і т.д.) виконуються деструктивні дії (від банальних перехоплень управління процесів апача і виставлення заставок на сайтах, що мовляв є такі круті перці, що зробили це, до підви ення привілеїв до рівня root з усіма наслідками, що випливають).

Чекаємо реакцію і виправдання хостера.

Така ж біда.
Зламано повністю акк на хостингу reg.ru
Спочатку взагалі не міг увійти в панель, говорить не правильний пароль. При спробі відновлення пароля видавало, що такого користувача немає.
Зараз увійшов в панель, але там ні чого не відображається.
FTP так само не працює: "не вдається з'єднатися з сервером"
У вас на якому сервері сайти?
Мої лежали на server9

Як від подібного захиститися?
Сайти були в основному на Joomla 1.5.x і на самопісний движку.
Чи не працює все. У ПУ хостингу взагалі ні чого не відображається.

В даному випадку не допоможуть ні ліцензії, ні оновлення, приблизна схема наступна:

насилу віриться та й / tmp як правило з noexec.

використовують зазвичай ПО типу s99shell і т.д. бінарник можуть виконати там, де є права (у випадку з DSO можливостей маса, особливо якщо олпенбаздір протекція не варто і т.д.)

Зламали хакери з Туреччини які називають себе "1923Turk-Grup"

в яке арабські хакери впровадили свої скрипти.

І нахрена цим французам з Австралії знадобилося так по-китайськи ламати сервера? ))))))
Турки (а з ними азербайджанці, татари, узбеки) і араби - не тільки різні національності, мови, традаціі, цінності та культури, а й різні групи (тюркська і семітських): D Нормально так переплутали.

Вже скільки разів твердили світу - не купуйте домени у хостера і не купуйте хостинг у реєстраторів, аж ні!
До чого наш народ любить на граблі наступати: D
Чим це зумовлено? просветите.

Тим, що добре і якісно можна вміти робити тільки одну річ. Коли компанія розпорошує увагу, у неї виходить одна річ добре, а інші погано. Ось реєстрація у reg.ru вийшла добре.

ось завжди знайдеться людина, яка відкритими чакрами визначить проблему і знайде рішення, навіть не знаю всіх даних. )

А найцікавіше, що по посту зрозуміло, що знань у який написав на цю тему - нижче плінтуса.

Як нескромно ви собі ведете молода людина.
Знання чужі взявся він оцінювати.

Ситуація ця виникла через хостера, як написали вище, що немає доп. захисту у них.
Злом був не індивідуальної сайту а всіх які розташовані були в одному місці.

Методи індивідуального захисту це добре, але ці хакери працюють за іншим принципом атака на незахищені належним чином сервера, де було це слабке місце видніше їм я не спец у зломи.

Ну взагалі-то молода людина прав. Крім того, що Ви уявляєте собі систему захисту куди як простіше, ніж вона повинна бути (тобто просте нерозуміння принципів), Ви ще й перевалює провину на хостера. Захистити самогубця від смерті нереально, навіть якщо до нього приставити кращих охоронців. Він все одно замкнеться в туалеті і самоубьется. Як Ви це зробили. Неможливо засобами сервера захистити від дірок в сайті. Просто фізично неможливо.

Безпека - середовище, в якому повинні брати участь всі ланки. Якщо одне не бере - вже все. Як мінімум хостер повинен був проводити тоді ревізію Вашого сайту.

Поламати можна будь-який сервіс. це доведено.
Не погоджуся з Вами, можна вимкнути сервер з розетки і тоді його ніхто не зламає :)))

А що не так в цьому твердженні: "будь-яка фірма може займатися будь-яким бізнесом.". Може. Питання тільки в тому чи добре вона це робить або погано. Якщо погано - то розориться і закриється а якщо добре то кому від цього погано то?
Не бачу нічого поганого коли реєстратор доменів починає і хостинг надавати і сертифікатами приторговувати і ще чимось займатися. Це називається розширення послуг, що надаються і оптимізацією наявної інфраструктури. Що в цьому може бути поганого? Все залежить від результатів.

Речі про "погано" ніхто не вів.

Емпіричним шляхом доведено. Можна розширювати межі бізнесу, але він повинен залишатися в одному руслі. Якщо реєстратор паралельно починає торгувати сертифікатами - це одне, але якщо займатися хостингом - це вже дуже далеко йде. Це вже не вписується в список розширених послуг.
Навіть монструозні умани типу Google і Microsoft не здатні на це. Як Google провалився зі своєю операційною системою і не вирвав практично ніякої частки проти M $, так і остання нічого не змогла протиставити своїм Бінгом проти Google. Така се ля ві.
Якісно розвиваються тільки ті, хто акумулює сили на одному завданню. Тому що в той час як Ви їх розпорошувати, Ваші конкуренти їх акумулюють і у Вас вже немає шансів.

Це ви вивели новий економічний закон? Будь-яка нормальна компанія з адекватним керівництвом прагне розвивати свій бізнес, а в суміжних сферах в першу чергу. Вони ж не займаються додатково установкою кондиціонерів, наприклад. Що з хостингом, що без у них тепер повинна бути своя команда адміністраторів, інженерів і тд. Так чому б наявні вільні ресурси і накопичені напрацювання і досвід не застосовувати на благо компанії? Люди знають як вести бізнес і робити гроші, а решта це все расуссоліванія для форумів.
Так сфери не дуже суміжні. Ось від хостингу до доменів вже інша справа. Навпаки - дещо інші завдання. Я в плані технічної реалізації. Одне - коли хостер через API великого реєстратора реєструє домени, а інша - коли реєстратор починає займатися хостингом. (Я вважаю, що фахівці досить різні. Та й завдання / встановлення масового хостингу дещо інші). Тут і керівництву не так просто буде, имхо.
Нічого поганого не хочу сказати ні про кого, це чисто моє ІМХО.

Навіть монструозні умани типу Google і Microsoft не здатні на це. Як Google провалився зі своєю операційною системою і не вирвав практично ніякої частки проти M $, так і остання нічого не змогла протиставити своїм Бінгом проти Google. Така се ля ві.
А чому мовчите, як Google злетів з своєї Android і заткнув за пояс Symbian? І взагалі це світові корпорації, з багатомільярдними прибутками, там інші масштаби, ризики, завдання. Не дуже коректно їх приклади застосовувати до компаній національного і регіонального масштабу.

Дивно що для Вас злом сайту в загальному - це "нормально".
Коли клієнт сам винен (зламали його сайт через дірки в скриптах) - це одне. А коли зламали весь сервер (навіть через дірки в сайтах одного клієнта) - інше.

у reg.ru з реєстрацією теж не все гладко. зокрема там, де вони не реєстратор, а реселлер реєстратора. не забуду, як домен .de, зареєстрований через них, через кілька місяців виявився видалений без повідомлень і адекватних пояснень. з тих пір вони закрили реєстрацію в цій зоні.

Коли клієнт сам винен (зламали його сайт через дірки в скриптах) - це одне. А коли зламали весь сервер (навіть через дірки в сайтах одного клієнта) - інше.
Безумовно! І кожен з випадків потрібно ретельно контролювати і перевіряти. Але якщо говорити узагальнено то злом сайту це вже ніяк не «нормально" :) Це може бути в гіршій ступеня або в звичайній, але ніяк не в нормі, так-же як і з вини хостера або клієнта :)

а хто сказав що у них suphp? і ця зв'язка працює передбачувано для пхп а для перл скрипта запущеного з / tmp вона не спрацює (навіть якщо засекурен / tmp).

а хто сказав що у них suphp? і ця зв'язка працює передбачувано для пхп а для перл скрипта запущеного з / tmp вона не спрацює (навіть якщо засекурен / tmp).
Запуск perl з tmp та й будь-якого бінарники відключається дуже просто.

P.S.
А дійсно, яка панель була у них?

P.P.S.
і щось я зовсім не вірю, що запущений perl скрипт з temp якимось чином омине систему привілеїв linux.

Не думаю що сервак реграм ламав досвідчений дослідник в області безпеки через найновіші діру в якій нитка бібліотеці, про яку навіть розробникам не відомо. Вони такою нісенітницею не займаються, отже це робив школоло через старі дірки в софті або свідомо небезпечною налаштування сервера. Чого тут і говорити, гріш ціна тому анікейщіку який налаштовував цей сервак.

Ви перш ніж вважати себе найрозумнішим, розповідати хто чим займається, і навішувати ярлики, порахуйте скільки в libc було критичних фіксів тільки за цей рік.

hvosting, були "епідемії" з цього приводу через libc і повальний винос серверів? Не пригадую таких новин.

і щось я зовсім не вірю, що запущений perl скрипт з temp якимось чином омине систему привілеїв linux.
Во-во, воно саме.

порахуйте скільки в libc було критичних фіксів тільки за цей рік.
Ем. А сервери оновлювати - не пряма задача адміністратора ?!

TheJetHost.com, робота апача від nobody - потенційна дірка. Ніколи так не робіть.

банальний mod_php фактично більш безпечний, якщо пользоателей грамотний, а продуктивність вище приблизно раз п'ять
Дивлячись що за адмін їм рулить. Налаштувати його складніше.

Відключаємо глобально в php.ini ВСЕ ф-ції, котрі можуть бути використані для підвищення прав (exec, system і т.д.)
І чим це вам допоможе? Не забудьте перл тоді порізати. закрити доступ до системного інтерпретатора python, пошматував ruby і у вас взагалі нічого працювати не буде.

Обмежуємо шлях, по якому апач буде шукати php.ini (щоб не було можливості завантажити свій php.ini з дозволеними ф-ціями)
Теж марення. А ви під кожну cms окремий сервер ставите (з включеним magick quotes і з відключеним, наприклад)?

Використовуємо CloudLinux + CageFS + Grsecurity
Гм, гм. Не бачу, як це допоможе. Від сплойтов може і врятує в якійсь мірі, але сподіватися не рекомендую.

Використовуємо mod_security (з правилами відповідними)
Знову ж потрібен спец. Інакше тільки собі гірше робимо.

Нормального користувача на тому ж сервері ні хто не вкусить.
Так ось я поки не знаю, в чому ж там собсно справа то було. Якщо підвищення привілеїв мало місце - і нормальному звірові дістанеться. До речі, 70% юзверей ставлять правильні права.

які доступні тільки на читання 644
Особливо мені подобається ставити такі права на файли конфігов скриптів з паролями до БД. Ну за умови що на папки варто 755 - самі розумієте, до чого може привести. Не можна так робити, або обмежувати через openbasedir - але тоді права не мають значення. Правда, існують способи обходу цього обмеження, але все ж краще ніж нічого.

Використовувати свій php.ini там можливо в будь-якому випадку.

Тут я з Вами змушений не погодитися, якщо дозволити користувачам використовувати свій php.ini, є ймовірність, що включать ф-ції, які були відключені глобально (якщо були зрозуміло), тобто system, exec, shell_exec і т.д. що в свою чергу не страшно саме по собі, але якщо в ОС є публічно відомі уразливості, за допомогою них (використовуючи дані ф-ції) можуть підвищити привілеї аж до root

але якщо в ОС є публічно відомі уразливості, за допомогою них (використовуючи дані ф-ції) можуть підвищити привілеї аж до root

Проти запуску будь-яких "небажаних" речей допомагає mod_security і ваервол. Власний php.ini тут нічим зловмиснику не допоможе взагалі.

А публічні дірки в ОС патчатся дуже швидко.

Що поганого в своєму php.ini? Це навпаки фішка корисна. Ніякої загрози безпеки я тут не бачу, а якщо застромлять ліміт на пам'ять або час виконання скриптів відключать, то це все одно не прокотить, тому що є глобальне обмеження на важливі параметри для всього сервера і власний php.ini їх не зможе перебити.
Я товаришеві Хостплюс це і намагаюся пояснити приблизно. як доводить цей топік не у всіх
А ви знаєте, що там і як сталося? Боюся, що ні.

Але в даному випадку ламали НЕ БД, а затирали індексний файл
Якщо вже змогли затерти, то і прочитати теж

Andreyka, В даному випадку - згоден.

Компанія REG.RU зафіксувала факт злому одного з хостингових серверів, в зв'язку з чим були порушені 128 клієнтських сервісів. Всі сервіси відновлені.

Вжито заходів для недопущення подібних інцидентів у майбутньому. Компанія приносить свої вибачення за даним фактом.

Схожі статті

Попередня ◈ Наступна