Життя після злому

  1. Відновлення після мережевої атаки Нарешті пятница! Адміністратор смакує заслужений відпочинок, але...
  2. Відкриті порти і неавторизовані користувачі
  3. План відновлення після злому
  4. Навчання на прикладах
  5. Атака на IIS в DMZ
  6. Атака на клієнта VPN
  7. Атака на Exchange Server (SMTP AUTH)
  8. Не потрібно паніки - просто будьте напоготові
  9. Що почитати додатково
  10. Більш докладні відомості про атаки типу «спам»:
  11. Аудіопрезентації (Webcast) про захист організації від загроз безпеки:
  12. Інші ресурси:
  13. Інтерактивні ресурси
Відновлення після мережевої атаки

Нарешті пятница! Адміністратор смакує заслужений відпочинок, але перед самим закінченням робочого дня хтось із користувачів раптово скаржиться на повільну роботу мережі, особливо при спробах доступу в Internet. Перевірка показує, що сервер і мережу і справді працюють дуже повільно. Тоді адміністратор перевіряє статистику трафіку через брандмауер і зауважує незвично високий рівень Internet-трафіку. Потім він запускає на сервері команду Netstat і виявляє кілька неавторизованих підключень до корпоративного сервера, причому все вказує на те, що підключилися з Internet. Адміністратор перевіряє реєстр сервера і тут також зауважує кілька невідомих програм, запуск яких проводиться автоматично. Про плани на довгоочікувані вихідні можна забути: належить приємний вікенд на робочому місці. Мережа тільки що зламали!

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

Де дивитись

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

Розділи реєстру. Якщо є підозра, що була зламана окрема система, першими слід перевірити розділи Run на цій машині. Необхідно подивитися, чи не запускаються з цих розділів будь-які незнайомі програми. Розділи Run - улюблене місце запуску шкідливих програм не тільки у хакерів, але і у творців вірусів, які також запускають з цих розділів свої «твори». Розділи Run підтримуються на платформах Windows Server 2003, Windows XP, Windows 2000, Windows NT, Windows Me і Windows 9x. Ось список цих розділів:

  • HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRun
  • HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRunOnce
  • HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRunServices
  • HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRunServicesOnce
  • HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRun
  • HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRunOnce
  • HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRunServices
  • HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRunServicesOnce

Якщо використовуються системи Windows 2003, XP, Windows 2000 або NT, необхідно також перевірити розділ HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows CurrentVersionPoliciesExplorerRun.

Будь-яка невідома програма, в принципі, може виявитися програмою злому. За допомогою Google або іншої машини пошуку потрібно спробувати відшукати в Internet програму з аналогічним ім'ям і з'ясувати, чи є вона легітимною. Особливу увагу слід звернути на програми, які запускаються з C :, C: windows і C: windowssystem32. Я дуже рекомендую всім адміністраторам придбати звичку регулярно переглядати зазначені розділи реєстру і знати «в обличчя» всі програми, які завантажуються на комп'ютері автоматично.

Перераховані нижче розділи використовуються для запуску програм злому не так часто, але їх теж слід тримати під контролем. Ці розділи також застосовуються у всіх версіях Windows. Якщо розділ реєстру за замовчуванням (розділ default) містить щось, відмінне від записи «% 1»% *, дуже ймовірно, що мова йде про програму злому.

  • HKEY_CLASSES_ROOTatfileshell opencommand
  • HKEY_CLASSES_ROOTcomfileshell opencommand
  • HKEY_CLASSES_ROOTexefileshell opencommand
  • HKEY_CLASSES_ROOThtafileshell opencommand
  • HKEY_CLASSES_ROOTpiffileshell opencommand
  • HKEY_LOCAL_MACHINESOFTWAREClassesatfile shellopencommand
  • HKEY_LOCAL_MACHINESOFTWAREClassescomfile shellopencommand
  • HKEY_LOCAL_MACHINESOFTWAREClassesexefile shellopencommand
  • HKEY_LOCAL_MACHINESOFTWAREClasseshtafile shellopencommand
  • HKEY_LOCAL_MACHINESOFTWAREClassespiffile shellopencommand

Служби. Необхідно переглянути розділ реєстру HKEY_LOCAL_

MACHINESYSTEMCurrentControlSetServices у всіх версіях Windows. Записи в цьому розділі специфікують служби, описані на комп'ютері. Я рекомендую поглянути на список служб саме в реєстрі, а не через графічний інтерфейс Windows Services, оскільки деякі служби (наприклад, служби типу Type 1) там не показані. І знову-таки слід уважно поставитися до невідомим програмам. Якщо можливо, порівняйте записи розділу Services «підозрюваного» комп'ютера і аналогічні значення на станції, свідомо не зламаної, - можуть виявитися важливі відмінності.

Каталог Startup. Потрібно перевірити каталоги C: Documents and SettingsAll UsersStart Menu

ProgramsStartup і C: Documents and Settingsuser_name> Start MenuProgramsStartup на предмет пошуку невідомих програм і прихованих файлів. Для отримання списку прихованих файлів поточного каталогу і всіх підкаталогів потрібно набрати в командному рядку:

dir / ah / s

Планувальник (Task Scheduler). Слід перевірити каталог C: windows asks на заплановані завдання. Уважно досліджуйте всі невідомі завдання планувальника.

Win.ini. Для атаки можуть автоматично запускатися програми злому з C: windowswin.ini. Необхідно перевірити вміст наступної секції в файлі win.ini:

[windows]
Run =
Load =

Будь-яка програма, зазначена після Run = або Load =, буде автоматично завантажуватися при запуску Windows.

System.ini. Зловмисники можуть скористатися завантаженням програм з C: windowssystem.ini. Слід перевірити вміст секції

[boot] shell = explorer.exe

Будь-яка програма, зазначена після explorer.exe, буде автоматично завантажуватися при запуску Windows.

Існують і інші місця, звідки хакери можуть запускати програми автоматично при запуску Windows. Безкоштовна утиліта Autoruns (розробник - Sysinternals) покаже, які програми на станції налаштовані на автоматичне завантаження під час запуску NT або пізніших версій Windows. Завантажити цю утиліту можна за адресою http://www.sysinternals.com/ntw2k/ freeware / autoruns.shtml .

Відкриті порти і неавторизовані користувачі

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

Існують програми-невидимки (так звані root kits), які запускаються на рівні операційної системи і відкривають порти на скомпрометованої машині, яку порушник використовує для віддаленого доступу. Root kits типові для світу UNIX, але все частіше зустрічаються аналогічні програми для злому Windows. Щоб визначити, які підключення в даний момент є в комплекті з комп'ютером і які порти прослуховуються на хості Windows, потрібно відкрити вікно командного рядка і запустити команду

Netstat -a

У табл. 1 перераховані порти, які зазвичай відкриті на хості XP. Не варто панікувати, якщо на робочій станції або сервері виявиться більше відкритих портів, ніж перераховано в табл. 1. Порти можуть динамічно призначатися в залежності від типу запущеної служби. Наприклад, віддалений виклик процедур (RPC) використовує динамічно відкриваються порти, коли виконується віддалене адміністрування DHCP і серверів WIN. Детальніше про це читайте в статті Microsoft «How To Configure RPC Dynamic Port Allocation to Work with Firewall » за адресою http://support.microsoft.com/? Kbid = 15459 . При запуску Netstat особливу увагу необхідно приділити наступним обставинам:

Деякі утиліти злому можуть блокувати роботу Netstat і заважати відображати відкриті порти на комп'ютері. Якщо Netstat не вказує у відкритих портах нічого незвичайного, але підозри на цей рахунок все-таки залишаються, потрібно запустити з іншого комп'ютера утиліту Open Source Network Mapper (nmap), яку можна завантажити з Internet за адресою http://www.insecure.org/nmap , І подивитися на відкриті порти даної станції.

Шахраї в AD. Коли порушник компрометує систему, він може створити одну або кілька своїх облікових записів в Active Directory (AD). Нерідко порушники створюють такі облікові записи, не заповнюючи поле опису (description) користувача. Щоб протистояти подібної тактики, раджу додавати дані в поле description (слідуючи при цьому специфічним правилам іменування) для кожного авторизованого користувача AD. Це дозволить впорядкувати облікові записи користувачів AD по полю description, і всі записи з порожнім полем опису з'являться в самому верху списку.

Неавторизовані користувачі в привілейованих групах. Одна з головних задач зломщика полягає в отриманні привілейованих прав доступу. Необхідно перевірити вміст таких груп AD (наприклад, Administrators, Domain Admins, Enterprise Admins, Server Operators) на наявність неавторизованих облікових записів. Потрібно створити обмеження членства в привілейованих групах, щоб завжди можна було швидко виявити неавторизованих членів.

План відновлення після злому

Якщо встановлено, що одна з систем була зламана, не варто впадати в паніку. Необхідно зберігати холоднокровність і діяти логічно. Ось план дій, який допоможе знизити ступінь потенційних руйнувань.

  1. Ізолюйте мережу. Потрібно відключити всі зовнішні мережеві інтерфейси, в тому числі Internet, WAN, VPN і комутовані, відключити всі лінії маршрутизатора, бездротові точки доступу Access Points (AP) і будь-які інші пристрої, які з'єднують мережу з зовнішнім світом. Ця дія дозволить зупинити активну атаку і перешкодить порушникові скомпрометувати інші системи.
  2. Виконайте перевірку поточного стану бездротової мережі. Необхідно скористатися бездротовим сніфера, наприклад Airscanner Mobile Sniffer або NetStumbler.com NetStumbler, для локалізації «скомпрометованої» AP. Важливо переконатися, що сніфер встановлений на мережевої карти, яка підтримує всі поточні бездротові стандарти (тобто 802.11a, 802.11b і 802.11g).
  3. Перевірте інші скомпрометовані машини. Слід використовувати методи, описані в даній статті, для пошуку інших скомпрометованих машин.
  4. Проаналізуйте настройки брандмауера. Необхідно звернути увагу на незнайомі правила, незаконно відкриті порти для зв'язку із зовнішнім світом і неавторизовані правила Network Address Translation (NAT). Потрібно перевірити журнали брандмауера на будь-яку підозрілу активність. Рекомендую завжди обмежувати вихідний трафік тільки строго необхідними портами і дозволяти відправляти поштові повідомлення з обмеженого числа комп'ютерів через брандмауер.
  5. Проінспектуйте AD. Потрібно звернути увагу на неавторизовані облікові записи користувачів і, якщо такі знайдуться, відключити їх.
  6. Організуйте примусову зміну паролів для всіх облікових записів в мережі. Для облікових записів з високими привілеями рекомендую створити пароль (або якусь ключову фразу) принаймні з 15 символів. Паролі такої довжини важче зламати, оскільки хеші паролів LAN Manager (LM) не зберігається на сервері, якщо довжина пароля перевищує 14 символів.
  7. Замініть жорсткі диски зламаних систем. Заміна дисків ізолює і зупиняє хакерську активність. Дані на старих дисках завжди можна потім переглянути і витягти цінну інформацію про атаку.
  8. Визначте і ліквідуйте виявлене слабке місце. Важливо встановити, яким чином хакер отримав доступ в мережу. Як правило, це простіше сказати, ніж зробити. Якщо ідентифікувати вразливість не вдасться, варто подумати про залучення консультанта з безпеки для надання допомоги.
  9. Заново переустановите скомпрометовану машину. Повністю очистити зламаний комп'ютер практично неможливо. Якщо один або кілька інструментів зломщика залишилося на комп'ютері, порушник знову може перехопити управління станцією. Єдиний спосіб гарантовано очистити уражену комп'ютер - відформатувати жорсткий диск і перевстановити все з нуля, при цьому треба переконатися, що при відновленню не будуть встановлені раніше виявлені інструменти злому. Всі програми бажано перевстановити з компакт-диска, вручну розгорнути виправлення і відновити тільки файли даних. Ніколи не слід відновлювати реєстр, операційну систему або будь-які інші програми з стрічки.
  10. На всіх комп'ютерах запустіть програму антивірусного сканування. Потрібно мати на увазі, що антивірусне програмне забезпечення може іноді ідентифікувати інструменти злому як цілком законні програми. Якщо сканування показало, що все чисто, але в цьому є хоч якісь сумніви, рекомендую встановити всю систему з нуля.
  11. Заново підключіть всі лінії WAN. Необхідно підключити лінії WAN і уважно стежити за даними моніторингу, це допоможе переконатися, що прогалини в мережі компанії усунені. Об'єкт особливої ​​уваги - використання смуги пропускання, журнали брандмауера і журнали аудиту на всіх серверах.
  12. Проведіть ретельне дослідження зламаних жорстких дисків. Слід встановити зламані жорсткі диски на ізольований комп'ютер і постаратися отримати якомога більше інформації про характер злому. Хоча зловмисники часто використовують техніку спуфинга (отримання доступу обманним шляхом; ситуація, коли користувач отримує доступ до Internet-сервером, proxy-сервером або брандмауером, вводячи помилковий IP-адреса), адреса IP - то, з чого добре починати вибудовувати шлях до джерела атаки . Отримати список IP-адрес можна на Web-сайті Internet Assigned Numbers Authority (IANA) за адресою http://www.iana.org .
  13. Сповістіть компетентні органи. У США, наприклад, співробітниками ФБР організований Web-сайт Internet Fraud Complaint Center (IFCC - http://www.ifccfbi.gov/index.asp ) Для складання звітів про підозрілу активність в Internet, а більшість регіональних відділень ФБР мають спеціальні групи протидії хакерам Cyber ​​Action Teams (CAT). Ніхто не відчуває особливої ​​радості, зізнаючись, що його мережа була зламана, однак своєчасне оповіщення компетентних органів допоможе запобігти ще більші руйнування від дій хакерів. У США, наприклад, можна зв'язатися з найближчим відділенням ФБР за адресою http://www.fbi.gov/contact/ fo / fo.htm .

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

Навчання на прикладах

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

Атака на IIS в DMZ

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

Ідентифікація злому. Я відкрив в Microsoft Management Console (MMC) оснащення Active Directory Users and Computers і переглянув облікові записи користувачів. Хтось створив дивну обліковий запис, яка виявилася в складі групи Administrators. Я зрозумів, що порушник зламав мережу, тому всі зовнішні підключення були моментально відключені і почався всебічний аналіз скомпрометованого комп'ютера. Це не забрало багато часу: мій клієнт мав два Web-сервера в демілітаризованій зоні (DMZ). Один з них представляв Web-сторінку компанії; інший вів узгодження часу. Я перевірив розділи реєстру Run і виявив підозрілі BAT-файли на диску С на обох серверах. На сервері з програмним забезпеченням узгодження часу були виявлені дивні FTP- і SMTP-програми і велике число root kits. Цей сервер підключався до системи Microsoft SQL Server по локальній мережі і за допомогою тільки трафіку від SQL Server передавав дані з DMZ в локальну мережу. Цей сервер був Windows 2000 з встановленим пакетом оновлень Service Pack 2 (SP2) і на ньому було відсутнє величезне число критичних виправлень для систем Windows 2000.

Ліквідація наслідків злому. Я перебудував сервер «з нуля», переніс його в локальну мережу за брандмауер і закрив загальний доступ до нього. Потім знову підключив зовнішні зв'язки і встановив моніторинг, відстежуючи будь-яку підозрілу активність.

Робимо Висновки. Перед тім як поміщаті публічній сервер в DMZ, Переконайся, что Виробники програмного забезпечення, вікорістовуваного в вашій системе, віпускають в достатній мірі Безпечні продукти для роботи в режімі Загальна доступу. Необходимо підтрімуваті всі сервери, а не только ті, что знаходяться в DMZ, на Рівні останніх пакетів оновлення и критичних змін. Потрібно переконатися, що додатки використовують SQL Server-інтегровану систему безпеки і не застосовують в коді програм для підключення до сервера SQL рядка з'єднання (connection string - використовується в ODBC для з'єднання із зовнішнім базою даних). Вбудовування зв'язують рядків в код Web-сервера дає зловмиснику прекрасну можливість отримати ім'я та пароль діючої облікового запису. Детальніше про встановлення з'єднання SQL Server з Web-сервера розповідається в статті Microsoft «Recommendations for Connecting to Databases Through Internet Information Services» ( http://support.microsoft.com/? kbid = 258939 ). Слід переконатися, що Microsoft IIS використовує збережені процедури для отримання доступу до даних SQL Server, і не дозволяти сервера IIS запускати оператори SQL. Оскільки всі перераховані кроки дозволяють надати аутентифікованим користувачеві дозвіл Execute тільки для збережених процедур, ви тим самим можете запобігти спробам користувача запустити оператори SELECT на SQL Server.

Атака на клієнта VPN

Ще один мій клієнт (з Exchange 2000 Server) зіткнувся з труднощами при виконанні робіт, пов'язаних з резервуванням даних, а також з дуже низькою продуктивністю сервера при відправці та отриманні електронної пошти. Нам вдалося з'ясувати, що причина того, що відбувається більш серйозна, ніж збої в роботі драйвера стримера або недостатньо потужний сервер. Сервер демонстрував неперевершену дискову активність і високий відсоток використання процесора. Я відкрив Windows Task Manager і розсортував час завантаження процесора по процесам. Store.exe забирав левову частку часу. У компанії не було настільки інтенсивно працює користувача Exchange і на той момент було всього-то 15 підключень до сервера. З такою кількістю користувачів Exchange не повинен був споживати так багато обчислювальних ресурсів, і я запідозрив руйнування в поштовому сховище.

Ідентифікація злому. Я запустив Exchange System Manager (ESM) і вибрав Administrative Groups, Admin_Group_Name, Servers, Server_Name, Protocols, Smtp, Default SMTP Virtual Server, Current Sessions. Попутно я помічаю, що шість сесій підключено до віртуального сервера SMTP вже не менше п'яти хвилин - пряма доказ, яка вказує на те, що хтось неправильно використовує сервер. У типовій ситуації сесія Exchange Server залишається активною лише кілька секунд, якщо тільки не проводиться відправлення або прийом повідомлення з вкладенням великого обсягу. Я переглянув черзі віртуального сервера SMTP за замовчуванням і виявив понад 50 черг в різних стадіях відправки пошти або очікують відновлення роботи. Хтось використовує поштовий сервер як ретранслятор, але як? На сервері встановлено останній пакет оновлень (Windows 2000 SP4 і Exchange 2000 SP3) і найсвіжіші виправлення, тому я запускаю тест Open Relay Database (ORDB) (його можна завантажити за адресою http://www.ordb.org ; тест перевіряє зазначені хости на предмет відкритої ретрансляції), щоб переконатися, що ретрансляція закрита.

Всякий раз, коли я намагався очистити з'єднання на віртуальному сервері SMTP за замовчуванням, воно знову з'являлося, зазвичай з іншим доменним ім'ям, але з тим же самим IP. Перевіряю цей список адрес IP і дізнаюся, що він виділений одним з Internet-провайдерів в далекому Китаї. Переконавшись, що мій сервер не налаштований на відкриту ретрансляцію, я приходжу до висновку, що хтось, мабуть, пройшов аутентифікацію на сервері і тепер розсилає від його імені повідомлення. А процедура Backup видає збої, оскільки весь час намагається створити резервну копію всього спаму, що розсилається. Відкриваю Active Directory Users and Computers і видаляю записи всіх підозрілих користувачів. При цьому помічаю, що деякі неавторизовані користувачі знаходяться в групі Administrators, і видаляю їх. Потім перевіряю реєстр, але не знаходжу нічого поганого в розділах Run. Про всяк випадок запускаю сканування вірусів - програма повідомляє, що сервер чистий.

Щоб не дати спамеру продовжити розсилку нових повідомлень, я відключив брандмауер від Internet і видалив всі активні сесії з сервера Exchange. Потім я спробував було за допомогою ESM видалити повідомлення з черг друку, але на це пішло б надто багато часу. Тоді я просто зупинив всі служби Exchange, відкрив вікно командного рядка і за допомогою команди Del видалив всі повідомлення з каталогу D: exchsrvrmailrootvsi 1queue. Як тільки були зупинені служби Exchange, продуктивність сервера стрибнула вгору. на видалення

10 000 повідомлень з черг пішло більше години. Потім настала черга «спам» -каталог D: exchsrvrmailrootvsi 1admail. На видалення повідомлень з неї пішло ще близько 8 годин. І нарешті, були змінені всі паролі мережевих користувачів і на брандмауері створено правило для блокування трафіку з діапазону IP-адрес, звідки спочатку надходив спам. Після виконання всіх змін я заново підключив брандмауер до Internet і запустив моніторинг сервера. Потік спаму не може бути поновлено.

Дана мережа мала кілька віддалених сайтів, які працювали через тунелі VPN. На одному з сайтів на віддаленій машині були виявлені наступні программивзломщікі: Bat.Mumu.A.Worm, Hacktool, W32.Valla.2048, W32.HLLW. [email protected], Bat.Boohoo.Worm і MSBlast.

Мій клієнт сказав, що даний комп'ютер був включений постійно, тунель VPN на ньому залишається активним. В такому випадку злом системи - це тільки питання часу. Я завжди рекомендую, щоб віддалені клієнти сиділи за брандмауером, особливо якщо вони використовують широкосмугове підключення. Якщо у вас система XP з'єднується по комутованого або бездротовому з'єднанню, необхідно переконатися, що Windows Firewall (колишня назва - Internet Connection Firewall, ICF) захищає комп'ютер при підключенні до Internet.

Ліквідація наслідків злому. Робоча станція була перебудована заново, поміщена за брандмауер TELE3 (виробник - SonicWALL), і на брандмауері була налаштована можливість створювати зворотний тунель до центрального корпоративного офісу. На щастя для клієнта, зловмисник використовував сервер тільки для розсилки спаму.

Робимо висновки. Прийнявши до уваги причини злому, компанія тепер не дозволяє на станціях клієнтів використовувати програмне забезпечення Mobile VPN Client на широкосмуговому з'єднанні без установки брандмауера. Якщо у вас є віддалені сайти з тунелями VPN і широкосмугові з'єднання, слід встановити брандмауер або принаймні наполягати на тому, щоб користувачі відключали свої комп'ютери, коли в них немає необхідності. Крім того, треба навчити користувачів деактивувати тунель VPN, якщо він в даний момент не потрібен.

Атака на Exchange Server (SMTP AUTH)

У третьому випадку клієнт, який використовує Internet-з'єднання, повідомив, що обмін відбувається дуже повільно через надзвичайно інтенсивного трафіку. Після того як я попросив всіх користувачів Internet відключитися, трафік і раніше залишився дуже високим. Я подивився статистику вихідних черг на сервері Exchange 2000 і виявив понад 100 черг, причому в кожної черги була присутня велика кількість повідомлень. За допомогою ESM я проінспектував повідомлення в декількох чергах. З'ясувалося, що в них були присутні повідомлення, в яких відправник і одержувач належали локальному домену, і це означало, що поштовий сервер використовувався зразок ретранслятора поштових повідомлень. За замовчуванням Exchange 2000 і більш сучасні системи допускають ретрансляцію, якщо відправник повідомлення може успішно пройти аутентифікацію на поштовому сервері.

Ідентифікація злому. Хакери можуть застосовувати цілий набір різних методик для захоплення імені користувача та його пароля. Наприклад, вони можуть періодично намагатися вгадати гостьовий пароль або пароль реального користувача і робити це до тих пір, поки не посміхнеться удача або не вийде запустити програму злому для захоплення імені та пароля користувача. Спамеру досить роздобути одне-єдине правильне ім'я і пароль, і тоді вже все одно, налаштований поштовий сервер на ретрансляцію чи ні.

Щоб встановити, яку обліковий запис використовує спамер, я запустив ESM і відкрив Organization, Administrative Groups, Organizational Unit, Servers, потім перейшов в контекстне меню Server Name, Properties і на вкладку Diagnostics Logging. У вікні Services я клацнув MSExchangeTransport і в вікні Categories підвищив рівень реєстрації подій до максимуму для категорій Routing Engine, Categorizer, Connection Manager, Queuing Engine, Exchange Store Driver, протоколу SMTP і драйвера сховища NTFS. Потім я клацнув Event Log і звернув увагу на наявність подій аутентифікації від зовнішнього або відповідної поштової сервера. Невдалі спроби виконати реєстрацію відображаються в журналі Security Log з кодом ID 680. Я виявив, що в процесі аутентифікації на поштовому сервері зловмисник використовував обліковий запис, яка не була локальної обліковим записом Exchange Server.

Ліквідація наслідків злому. Після того як була ідентифікована обліковий запис, через яку йшла аутентифікація, я зробив наступні кроки для забезпечення безпеки сервера Exchange.

  1. Змінив пароль облікового запису, який використовував спамер. Якщо припустити, що спамер міг скористатися кількома обліковими записами, тоді можна поміняти паролі для всіх користувачів мережі. Також була відключена обліковий запис Guest і встановлені виділені облікові записи для запуску служб на сервері. Не варто використовувати запис Administrator для запуску служб. Якщо машина буде зламана, обліковий запис, від імені якої запускається служба, може бути скомпрометована.
  2. Відключив аутентифікацію на зовнішньому сервері Exchange. Для цього потрібно запустити ESM і вибрати Organization, Administrative Groups, Organizational Unit, Servers, Server Name, Protocols, SMTP, потім відкрити контекстне меню віртуального сервера SMTP за замовчуванням, вибрати Properties, перейти на вкладку Access і клацнути Authentication. Я залишив Anonymous Access включеним, але зняв прапорці Basic Authentication і Integrated Windows Authentication. Зняття цих прапорців фактично призводить до того, що на SMTP-сервері відключається команда Auth.
  3. Включив ретрансляцію для інших внутрішніх серверів Exchange, щоб переконатися, що вони можуть посилати пошту на зовнішні (outward-facing) сервери Exchange. Для цього потрібно запустити ESM, відкрити контекстне меню віртуального сервера SMTP та вибрати Properties. На вкладці Access слід клацнути Relay, вибрати Only the List Below і перерахувати внутрішні поштові сервери, яким дозволяється ретранслювати поштові повідомлення на зовнішні сервери.
  4. Після всіх цих змін я провів суворе тестування отриманої конфігурації. Був протестований вхідний і вихідний поштовий Internet-трафік, а також поштовий трафік між серверами всередині компанії. Зміни теоретично могли порушити потік поштових повідомлень між серверами, тому є сенс для проведення подібних робіт дочекатися вихідних. А ще краще перевірити внесені зміни в лабораторних умовах до реального втілення в бізнес-середовищі.
  5. В даному випадку виявилася станція, яка виявилася дуже серйозно скомпрометована, її довелося перебудовувати «з нуля». У якийсь інший ситуації може знадобитися ідентифікувати всі скомпрометовані станції і або спробувати їх відновити, або перебудувати заново.
  6. Перевірив ORDB для того, щоб встановити, чи не виявився клієнт поштового сервера занесеним в «чорний список» для ретрансляції повідомлень. На щастя, я виявив і ліквідував наслідки злому до того, як поштовий сервер клієнта був занесений в «чорний список». Поштовий сервер може бути поміщений в «чорний список», якщо ретрансляція відкрита або якщо поштовий сервер ідентифікується як сервер, який посилає величезний обсяг даних, ідентифікованих як спам. Існує безліч баз даних відкритої ретрансляції. Подивитися список деяких баз даних можна за адресою: http://dmoz.org/computers/internet/abuse/ spam / blacklists .

Коли поштовий сервер поміщається в «чорний список», адміністратору залишається або надіслати запит про видалення сервера з «чорного списку», або змінити зовнішній адресу IP свого поштового сервера. Якщо вирішено змінити адресу поштового сервера, то необхідно також оновити запис Mail Exchanger (MX) Record на цьому сервері, інакше вихідна кореспонденція буде блокуватися.

Робимо висновки. Щоб відновити Exchange Server після атак типу SMTP AUTH і не допустити їх повторення в майбутньому, я строго рекомендую виконати всі перераховані вище кроки. Якщо зловмисник якимось чином роздобув справжнє ім'я і пароль користувача і вміє організувати ретрансляцію пошти, тоді поштовий сервер незабаром виявиться в «чорних списках» електронної пошти. Ви витратите набагато менше часу на запобігання подібних атак, ніж на з'ясування причин, пов'язаних з ненормальною розсилкою поштових повідомлень, шляхом видалення свого сервера з «чорних списків» і ліквідації вразливих місць.

Не потрібно паніки - просто будьте напоготові

План відновлювальних заходів після проведеної атаки - це частина будь-якої ІТ-структури. Він допоможе відшукати ефективний шлях протидії атакам на мережу. Ознайомтеся з утилітами і методами, які використовують зловмисники, і не нехтуйте профілактичними заходами проти атак на мережу.

Що почитати додатково

WINDOWS IT PRO RESOURCES

Щоб швидко вивчити різними аспектами в області безпеки:

Security Administrator newsletter http://www.windowsitpro.com/windowssecurity/ issues

Більш докладні відомості про атаки типу «спам»:

«A New Kind of Attack," InstantDoc ID 40507

Аудіопрезентації (Webcast) про захист організації від загроз безпеки:

Microsoft Security Strategies Roadshow http://www.winnetmag.com/roadshows/c omputersecurity2004

Інші ресурси:

Intrusion Detection FAQ http://www.sans.org/resources/idfaq

Інтерактивні ресурси

Зайдіть на сайт www.windowsitpro.com і введіть в поле InstantDoc ID номер 43875

October 13, 2004, 12:00 noon EST:

Бесіда з фахівцем Windows IT Pro Аланом Сугано (Alan Sugano) про способи виявлення злому і відновлення системи

October-December 2004: Додати

Бесіда з Бреттом Хіллом про протидію хакерам і вирішенні деяких інших проблем безпеки

Нотатки Паули Шерік «Lessons from the Cyber Trenches»

Алан Сугано ( [email protected] ) - президент компанії ADS Consulting Group, що спеціалізується на мережевих технологіях, програмуванні, проектуванні на базі Microsoft .NET і SQL Server

З чого почати?
Com/?
Com/?
Хтось використовує поштовий сервер як ретранслятор, але як?
IRC (Internet Relay Chat)