17310

Захист поштових серверів Exchange Server

Лекция

Информатика, кибернетика и программирование

Лекція 21. Захист поштових серверів Exchange Server Основні рекомендації для забезпечення безпеки Хоча існує величезна кількість різних складних і сучасних засобів які можна використовувати для посилення безпеки структури сервера Exchange не варто недооцінювати наступні осн

Украинкский

2013-06-30

201 KB

0 чел.

Лекція 21.  Захист поштових серверів Exchange Server

Основні рекомендації для забезпечення безпеки

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

Елемент

Дія

мережева безпека

- забезпечення безпеки AD - вимога складних паролів - проходження принципу мінімуму привілеїв - використання антивірусних рішень

безпека сервера

- фізично захищати сервера - видаляти всі непотрібні служби - використовувати останні оновлення

безпека повідомлень

- створення списку затверджених адрес IP і назв доменів - включення журналізації і моніторингу серверів - уникнення релея SMTP

безпека даних

- використання спеціального плану для відновлення пошкоджених або втрачених даних

Знання інфраструктури

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

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

Ефективна стратегія безпеки також описує порти, які пов'язані з кожною службою, що використовуються в організації. Для того, щоб понизити поверхню атак, слід закрити доступ до портів, які не використовуються. У наступній таблиці описані порти сервера Exchange і пов'язані з ними служби:

 Порт

Служба

25

SMTP

80

HTTP (Hypertext Transfer Protocol)

88

Kerberos authentication protocol

102

MTA (message transfer agent) —X.400 connector over TCP/IP (Transmission Control Protocol/Internet Protocol)

110

POP3

119

NNTP

135

Client/server communication RPC (віддалений виклик процедур)

143

IMAP

389

LDAP

443

HTTP (Secure Sockets Layer (SSL))

465

SMTP (SSL)

563

NNTP (SSL)

636

LDAP (SSL)

993

IMAP4 (SSL)

995

POP3 (SSL)

3268, 3269

Global catalog lookups

Будь-яке єдине застереження не зможе гарантувати безпеки структури сервера Exchange. Необхідно розуміти ризики пов'язані з безпекою, для яких уразлива більшість компаній. За допомогою ідентифікації ризиків безпеки і використанні технологій і методів, що призводять до зниження цих ризиків, можна понизити вірогідність атак на систему безпеки.

Наступна таблиця описує основні типи небезпек для системи безпеки.

Тип небезпеки

Характеристики ризиків

Крадіжка даних

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

Фальсифікація

Підміна передаваних даних.

Відмова в обслуговуванні

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

Трояни

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

Віруси

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

Імітація з'єднання

Заміна електронної адреси клієнта власною електронною адресою.

Підміна листів

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

Адміністративні ролі

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

В даному випадку, в середовищі Exchange, де є декілька груп адміністраторів, може виникнути ситуація, при якій деякі адміністратори зроблять зміни в конфігурації для об'єктів, для яких вони не повинні цього робити. Для уникнення такої ситуації, необхідно зробити декілька речей:

  •  Налаштувати додаткові адміністративні групи – адміністративні групи забезпечують спосіб угрупування об'єктів разом (наприклад, сервери (servers), політики (policies), маршрутні групи (routing groups) і загальні каталоги (public folder)) і дозволяють визначити область дозволу для групи.
  •  Використовувати майстер по передачі адміністрування Exchange Administration Delegation Wizard. Слід використовувати цей майстер для передачі адміністративних прав користувачеві або групі.
  •  Призначати адміністративні ролі. Адміністративна роль – це збір об'єктів Exchange для управління і передачі дозволів.

У наступній таблиці представлений список адміністративних ролей в Exchange:

Роль

Права в структурі

Права в адміністративній групі

Повний адміністратор

• права на повний контроль (Full Control) для контейнера MsExchConfiguration

• права Deny Receive-As і Send-As для контейнера Organization 

• права Read (читання) і Change (зміни) для контейнера Deleted Objects в Configuration naming context (Config NC)

• Права Read, List object і List contents для контейнера MsExchConfiguration

• права Read, List object і List для контейнера Organization container 

• Права Full Control, Deny Send-As і Deny Receive-As для контейнера Administrator Groups 

• Права Full Control для об'єкту Connections 

• Права Read, List object, List contents і Write properties для контейнера Offline Address Lists container

Адміністратор

• Всі права для контейнера MsExchConfiguration container.

• Права Deny Receive-As і Send-As для контейнера Organization.

• Права Read, List object і List contents permissions для контейнера MsExchConfiguration (тільки для цього об'єкту).

• права Read, List object і List contents permissions для контейнера Organization.

• Всі права (за винятком прав Change, Deny Send-As і Deny Receive-As permissions) для контейнера Administrator Group.

• Всі права (за винятком Change permissions) для контейнера Connections.

• права Read, List object, List contents і Write properties permissions для контейнера Offline Address Lists.

Exchange View Only Administrator

• Права Read, List object і List contents permissions для контейнера MsExchConfiguration.

• Право View Information Store Status permissions для контейнера Organization.

• права Read, List object і List contents permissions для контейнера MsExchConfiguration. • Права Read, List object і List contents permissions для контейнера Organization.

• права Read, List object і List contents permissions для контейнера Administrator Groups.

• права Read, List object, List contents і View Information Store Status permissions для контейнера Administrator Groups.

• права Read, List object і List contents permissions для контейнерів sExchRecipientsPolicy, Address Lists, Addressing, Global Settings, System Policies.

В деяких випадках майстер по передачі адміністративних прав Exchange Administration Delegation Wizard не забезпечує достатньої детальності при призначенні прав безпеки. Тому для окремих об'єктів усередині Exchange можна змінити настройки у вкладці Security.

Можливості по журналізації

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

Існує декілька можливостей по журналізації в Exchange, наприклад, журналізація діагностики (diagnostic logging), відстежування повідомлень (message tracking), журналізація активності (activity logging), а також журнал аудиту (audit logging). Об'єм даних, який можуть формувати ці журнали за день, може бути величезним, у тому випадку, якщо буде зайнято весь вільний простір, то Exchange очистить їх.

Як якнайкраща рекомендація необхідно створити план аудиту до застосування політики аудиту:

  •  Розглянути ресурси, які необхідно використовувати для збору і перегляду в журналі аудиту (audit log).
  •  Вирішити, який тип інформації потрібно отримати від зібраних для аудиту подій.
  •  Збирати і упаковувати журнали безпеки (security logs) у всій організації.

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

Хоча існує величезна кількість можливостей по журналізації на сервері Exchange, нижче представлений список найважливіших журналів для середовища Exchange:

  •  Системний журнал безпеки (Event Viewer system security log)
  •  Журнали віртуального сервера SMTP (Virtual Server logs)
  •  Журнали HTTP logs
  •  Журнали відстежування подій (Message tracking logs)

Майстер настройки безпеки в Windows

При посиленні безпеки сервера системи обміну повідомленнями, логічно, що на початку слід підсилити безпеку самої операційної системи. Для цього в Windows Server внесено новий засіб: майстер настройки безпеки (Security Configuration Wizard – SCW. Мають місце незначні проблеми з SCW. У одному з наданих посилань (KB 896742), Microsoft заявляє: “Для підвищення безпеки сервера Exchange 2003 рекомендується виконати дії, описані в керівництві Microsoft Exchange Server 2003 Security Hardening Guide. Рекомендації цього керівництва слід виконувати, замість використання майстра настройки безпеки”. Насправді, Руководство по повышению безопасности сервера Exchange 2003 – прекрасний інформаційний ресурс. У ньому розташована вся необхідна для підвищення безпеки сервера Exchange інформація. SCW працює з серверами Exchange і його легше використовувати, ніж шаблони безпеки Exchange-сервера.

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

У наступній таблиці  приведені всі шаблони безпеки і відповідні ним ролі серверів.

Роль сервера

Опис

Шаблон безпеки

Внутрішній сервер Exchange 2003

Сервер для доступу до поштових скриньок і загальних каталогів. При використанні POP, IMAP4 або NNTP використовується і відповідний накопичувальний шаблон

Основний шаблон Windows Server 2003 (Enterprise Client) Exchange_2003-Backend_V1_1.inf

Зовнішній сервер Exchange 2003

Звичайні для всіх зовнішніх серверів настройки; Відключені всі протоколи; для роботи сервера повинен застосовуватися певний протокол.

Основний шаблон Windows Server 2003 (Enterprise Client) Exchange_2003-Frontend_V1_1.inf

HTTP-сервер Exchange 2003

Виділений зовнішній сервер для HTTP; використовується для програм Outlook Web Access, Outlook Mobile Access, Exchange Server ActiveSync і WEBDAV

Основний шаблон Windows Server 2003 (Enterprise Client) Exchange_2003-Frontend_V1_1.inf Exchange_2003-HTTP_V1_1.inf

POP3-сервер Exchange 2003

Виділений зовнішній сервер для POP3 або доданий на внутрішній сервер Exchange 2003

Основний шаблон Windows Server 2003 (Enterprise Client) Exchange_2003-Frontend_V1_1.inf Exchange_2003-POP3_V1_1.inf

IMAP4 – сервер Exchange 2003

Виділений зовнішній сервер для IMAP4 або доданий на внутрішній сервер Exchange 2003

Основний шаблон Windows Server 2003 (Enterprise Client) Exchange_2003-Frontend_V1_1.inf Exchange_2003-IMAP4_V1_1.inf

NNTP-сервер Exchange 2003

Доданий на внутрішній сервер Exchange 2003

Основний шаблон Windows Server 2003 (Enterprise Client) Exchange_2003-Backend_V1_1.inf Exchange_2003-NNTP_V1_1.inf

SMTP-сервер Exchange 2003

Виділений шлюз з виходом в Інтернет для SMTP або сполучень

Основний шаблон Windows Server 2003 (Enterprise Client) Exchange_2003-Frontend_V1_1.inf Exchange_2003-SMTP_V1_1.inf

Керівництво по захисту сервера Exchange 2003 слід вивчити разом з Руководством по защите сервера Windows Server 2003, оскільки деякі з шаблонів є загальними.

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

Рис.1. Структура організаційної одиниці з додатковими організаційними одиницями сервера Exchange

Якщо не використовуються деякі з ролей (що вірно для більшості організацій),  можна комбінувати ролі в єдиній організаційній одиниці, оскільки політики безпеки адитивні.

ISA-сервер

Якщо є потреба в публікації служб Exchange в Інтернеті, ISA-сервер – це перший помічник в цій справі. ISA-сервер і сервер Microsoft Exchange розроблені для спільної роботи в мережі для підвищення безпеки системи обміну повідомленнями.

В оточенні Exchange-сервера ISA-сервер контролює трафік внутрішньої мережі і витікаючі з'єднання з системи обміну повідомленнями. Весь вхідний трафік до серверів Exchange, наприклад, до застосувань Microsoft Office Outlook Web Access, RPC поверх HTTP від клієнтів Microsoft Office Outlook, Outlook Mobile Access, POP3 і IMAP4, обробляються ISA-сервером.

          Рис. 2. Мережа з ISA-сервером

Крім всіх функцій безпеки, які ISA-сервер додає в мережу, головна перевага полягає в тому, що зовнішні сервери Exchange можуть більше не розташовуватися в DMZ (більш того, Microsoft не рекомендує таке розташування), а ресурси Exchange-серверів захищені від атак.

Захист від атак Відмови в обслуговуванні (Denial of Service - DOS)

Атака Відмови в обслуговуванні (Denial-of-Service - DOS) характеризується спробами хакерів припинити використання ресурсів легальними користувачами. Прикладами служить спроба переповнювання мережі, із-за якої мережевий трафік легальних користувачів порушує роботу служб певної системи.

Хоча від DoS-атак зазвичай важко захиститися, в сервері Exchange є настройки, які допомагають протистояти подібним атакам. Більшість з цих настройок доступні через консоль управління Exchange System Manager, а якщо бути точнішим, через властивості віртуального SMTP-сервера.

Ось настройки SMTP, які допомагають боротися з DoS-атаками:

  •  Максимальна кількість одержувачів повідомлення. Exchange-сервер повертає відправникові повідомлення, що перевищило максимальну кількість одержувачів, звіт про недоставляння (Non-delivery report - NDR).
  •  Максимальний розмір повідомлення. Найбільший розмір повідомлення, яке може пропустити віртуальний сервер.
  •  Максимальна кількість повідомлень на з'єднання. Досягши вказаного числа повідомлень система розриває з'єднання.
  •  Максимальний розмір сесії. Найбільший розмір повної транзакції за одну SMTP-сесію.

Фільтр повідомлень, що настроюється

Фільтр повідомлень (Intelligent Message Filter - IMF), що настроюється, був вперше представлений в 2004 році як доповнення до сервера Exchange 2003. Сьогодні ця версія не підтримується, вона була замінена версією 2.

IMF – це один з механізмів сервера Exchange, який дійсно може зменшити кількість небажаної пошти рекламного змісту (Unsolicited Commercial Email - UCE), отримуваною організацією. Фільтр заснований на характеристиках мільйонів повідомлень, і тому може точно оцінити вірогідність того, що вхідне повідомлення є спамом.

Рис. 3. Топологія Exchange-сервера з включеним фільтром IMF

Фільтр IMF встановлюється на сервери Exchange, що приймають вхідні повідомлення з Інтернету для їх перевірки.

Оскільки робота фільтру заснована на вірогідності того, що повідомлення є спамом, IMF оцінює повідомлення по властивості Рівень вірогідності спаму (Spam Confidence Level - SCL). Дана оцінка зв'язується з повідомленням при відправці його на інші Exchange-сервери.

Адміністратор встановлює два пороги, які визначають спосіб обробки повідомлень з різним SCL фільтром IMF: шлюзовий поріг, який відповідає за дію з повідомленням, чий рівень вищий за рівень даного порогу, і поріг сховища повідомлень. Якщо рівень SCL повідомлення вище або рівний значенню шлюзового порогу, фільтр виконує вказану дію. Якщо рівень повідомлення нижче значення шлюзового порогу, повідомлення відправляється в поштову скриньку одержувача на сервері Exchange. У сховищі поштових скриньок при рівні SCL повідомлення вище значення порогу сховища повідомлень, повідомлення поміщається в каталог Junk E-mail (Небажана пошта) користувача замість каталогу Inbox (Вхідні).

На стороні клієнта, Microsoft Office Outlook  і Microsoft Office Outlook Web Access для сервера Exchange, користувачі самі створюють список надійних відправників, від яких вони завжди хочуть приймати повідомлення, а також список блокованих відправників, від яких вони завжди хочуть відхиляти повідомлення.

Рис. 4. Потік повідомлень при роботі фільтру IMF і функції фільтрації Exchange-сервера

 

Антивірус

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

Одним з основних кроків по захисту системи обміну повідомленнями від вірусів є підготовка антивірусної стратегії. У антивірусну стратегію повинні входити навчання користувачів, установка антивірусного програмного забезпечення на всіх необхідних пристроях (на брандмауерах, SMTP-шлюзах, на кожному з Exchange-серверів і на кожному клієнтському комп'ютері), а також необхідність перевірки актуальності антивірусних програм. При виборі програмного забезпечення важливо враховувати здатність програми поширювати оновлення, такі як нові файли підписів, на клієнтські комп'ютери і сервери без втручання користувача. Таким чином, зменшується відповідальність користувача і помилки, викликані людським чинником.

У Exchange-сервер не вбудований захист від вірусів, але є основа для виробників антивірусного програмного забезпечення для розробки рішень для Exchange-серверів: Virus Scanning Application Programming Interface (VSAPI) 2.5 (Програмний інтерфейс застосувань антивірусного сканування 2.5).

Одним з поширених методів для передачі вірусів, яким користуються творці вірусів, є включення вірусу у вкладення. Для захисту від таких вірусів Outlook і Outlook Web Access надають наступні функції блокування вкладень:

  •  Функції блокування вкладень Outlook. В Outlook 2002 і вище вбудована функція блокування вкладень, яка блокує більшість очевидних типів файлів, таких як .exe, .bat, і .vbs.
  •  Функції блокування вкладень Outlook Web Access. В Exchange 2000 Service Pack 2 включена можливість блокування вкладень за типом файлу і MIME-типу в OWA. У OWA 200x функція блокування вкладень включена за умовчанням.

Недавно Microsoft придбала компанію Sybari, відому своїм антивірусним і антиспамовим пакетом Sybari Antigen. Версія даного продукту вбудована в програми Microsoft.

Захист від підробки адрес

Підробка адрес - один з методів, який використовують спамери. У RFC 2821, що визначає протокол SMTP, ясно сказано, що “Пошта, що відправляється по протоколу SMTP, по суті своїй, незахищена. Навіть звичайний користувач може безпосередньо спілкуватися з одержуючими або ретранслюючими SMTP-серверами, а також створювати повідомлення, які можуть ввести в оману наївного одержувача, який вважатиме, що повідомлення прийшли від когось іншого”. SMTP не вимагає підтвердження особи відправника. У Exchange-сервер є функціональність, що захищає від підробки адрес.

За умовчанням сервер Exchange забезпечує оригінальний метод представлення SMTP-повідомлення і не вирішує адресу відправника, якщо представлення анонімне. Якщо оригінальне повідомлення було прийняте без аутентифікації, Exchange позначає його як не аутентифіковане, і адреса відправника не вирішується в ім'я з глобального списку адрес (поле From (Від)), а замість цього повідомлення показується одержувачеві у форматі SMTP (наприклад, rui@msexchange.org).

Іншим можливим методом є настройка віртуального SMTP-сервера для виконання зворотного перегляду DNS для вхідних повідомлень. При цьому підтверджується IP-адреса, а повністю визначене доменне ім'я (FQDN) поштового сервера відправника порівнюється з доменним ім'ям, вказаним в повідомленні.

Проте для зворотного перегляду DNS існують деякі обмеження:

  •  IP-адрес відправника може не знаходитися в зоні зворотного перегляду DNS або ж сервер відправника має декілька імен для однієї IP-адреса, не всі з яких доступні для зворотного перегляду DNS.
  •  Зворотний перегляд DNS дає Exchange-серверу додаткове навантаження.
  •  Зворотний перегляд DNS вимагає, щоб Exchange-сервер міг зв'язуватися із зонами зворотного перегляду для домена відправника.

Виконання зворотного перегляду reverse DNS для кожного повідомлення може вилитися в значне зниження продуктивності із-за збільшення часу очікування.

Захист клієнтів

Сервери – це ще не все. Оскільки Exchange – це розподілене застосування типу “клієнт/сервер”, важливо в стратегії захисту враховувати і клієнтів. Особливо слід врахувати наступне:

  •  Обмежити набір клієнтів тільки тим, що необхідне. При визначенні стратегії управління ризиками дізнатися, які клієнти необхідні і обмежити функціональність Exchange-сервера тільки ними. Наприклад, для використання клієнтів POP3 або IMAP4 спочатку необхідно включити дані служби на сервері Exchange. Також можна обмежити, які версії Outlook можуть з'єднуватися з серверами.
  •  Переконатися, що план установки оновлень виходить за межі операційних систем на комп'ютерах користувачів. Використовувати актуальні і виправлені версії програмного забезпечення клієнтів і регулярно перевіряти їх оновлення.

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

Завжди оновлювати антивірусний захист клієнтів.

Використовувати нові функції безпеки Outlook: блокування вкладень, фільтрація небажаної пошти, відключення відправки сповіщень.

Захист повідомлень

Хоча компанія Microsoft випустила документи з даного питання (Руководство по защите сообщений Exchange-сервера), тут буде надана основна інформація, а потім можна прочитати і все керівництво повністю.

Протокол SMTP не був розроблений захищеним. Тому, для посилення протоколу SMTP функціями безпеки з'явився стандарт захищених багатоцільових розширень електронної пошти (Secure/Multipurpose Internet Mail Extension - S/MIME). S/MIME надає дві служби захисту: цифровий підпис і шифрування повідомлень. Обидві служби є ядром безпеки повідомлень S/MIME, вони дають можливість використання аутентифікації, підтвердження достовірності і цілісності даних і гарантують конфіденційність.

Хоча сервер Exchange підтримує багато клієнтських програм, не всі з них підтримують S/MIME. Сервер Exchange надає повну підтримку не тільки клієнтам MAPI, але і протоколам електронної пошти Інтернет POP3 і IMAP4, якщо клієнт підтримує S/MIME версії 2 або 3.

У повнофункціональній системі обміну повідомленнями на базі сервера Exchange існує три ланки, які і складають повний ланцюг системи:

  •  Сервер Exchange;
  •  Клієнт електронної пошти;
  •  Інфраструктура відкритого ключа (PKI).

Сервер Exchange відповідає за доставку і зберігання повідомлень S/MIME. Клієнт електронної пошти і PKI надають функції цифрових підписів і шифрування. Варто використовувати всі три компоненти, не обмежуватися настроюванням Exchange-сервера на підтримку S/MIME (до речі, за умовчанням Exchange-сервер налаштований на підтримку S/MIME).

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

  •  Шифрувати вміст і вкладення витікаючих повідомлень;
  •  Додавати в повідомлення цифровий підпис;
  •  При відправці підписаних повідомлень посилати їх відкритим текстом;
  •  Запрошувати підтвердження безпеки для всіх підписаних повідомлень S/MIME.

Слід пам'ятати, що S/MIME знижує продуктивність, як клієнтів, так і серверів, тому варто використовувати його обережно.


 

А также другие работы, которые могут Вас заинтересовать

4049. Исследование движения электронов в электростатическом поле 33.5 KB
  Исследование движения электронов в электростатическом поле Цель работы Определение зависимости смещения электронного пучка на экране осциллографа от величины напряжения на отклоняющих пластинах. Расчет чувствительных отклоняющих пластин осцилл...
4050. Исследование апериодического разряда конденсатора. Определение емкости конденсатора 77.5 KB
  Исследование апериодического разряда конденсатора. Определение емкости конденсатора Цель работы: Определение зависимости силы тока от времени при разряде конденсатора через сопротивление. Нахождение емкости конденсатора. Рисунок Рабочие...
4051. Исследование гальванического элемента тока 253.5 KB
  Исследование гальванического элемента тока Цель работы. Целью данной работы является определение связи между силой тока в цепи гальванического элемента тока и падением напряжения на внешнем участке цепи. Расчет на основании этих данных величин...
4052. Определение удельной электрической проводимости жидкости 226 KB
  Определение удельной электрической проводимости жидкости Изучение основных характеристик электрического тока. Изучение аналогии между электростатическим полем и стационарным электрическим полем. Определение удельной электрической проводимости жидкос...
4053. Отношения и их свойства 185 KB
  Отношения и их свойства Бинарное отношение R на конечном множестве Требования на множество – те же, что и раньше (в нем не должно встречаться повторяющихся элементов, кроме того, оно должно быть упорядочено по возрастанию)....
4054. Написание программы для работы с видеопамятью 73.5 KB
  Постановка задачи Написать программу, которая будет работать с видеопамятью. Можно выполнить любое из приведенных ниже заданий. Независимо от конкретного задания программа должна работать резидентно. Текст, присутствовавший на экране до запуска п...
4055. Актуальные аспекты в творчестве Ю.А. Лаврикова 37 KB
  Актуальные аспекты в творчестве Ю.А. Лаврикова. В вышедшей в 1989 году книге Интенсификация производства и проблемы управления трудом, Юрий Александрович Лавриков провел параметрический анализ производства переходного периода. Этот переходный пери...
4056. Принцип наследования. Создание иерархии классов. Классы и модули 46.5 KB
  Принцип наследования. Создание иерархии классов. Классы и модули. Задание: Создать иерархию графических классов в соответствии с рисунком. Описания классов оформить в отдельном модуле. Для создания данной программы, нам нужно обязательно созда...
4057. Дееспособность несовершеннолетних. Несовершеннолетние в области трудового, жилищного права 60.5 KB
  Лекция. Дееспособность несовершеннолетних. Несовершеннолетние в области трудового, жилищного права Гражданское законодательство о несовершеннолетних Гражданский кодекс Российской Федерации является основным источником гражданских прав, законных инте...