вторник, 30 сентября 2008 г.

Безопасность для чайника. Часть 3.

Части один и два и четыре.

image 11. Не делайте расшаренные папки с разрешениями для чтения всем. Никогда нет image уверенности, что Вы не выложите туда что-то, что не должно быть доступно самому широкому кругу лиц. Если Вы создали такую папку, то будьте бдительны по отношению к ее содержанию.

11а. (Примечание Владимира Безмалого)

Не делайте простой общий доступ к файлам и папкам. Это позволит вам сделать парольный доступ к содержимому общей папки и вы всегда будете знать кому и что вы разрешили. Если разрешили парольный доступ, то по окончании сеанса смените этому пользователю пароль.

12. Никогда, повторяю, никогда не делайте расшаренные папки с разрешениями на запись. Даже у хороших людей могут завестись вирусы, которыми они с удовольствием с Вами поделятся.

13. Если Вы сделали запись в общую папку доступной для всех... Что ж... Я провел эксперимент: выставил компьютер с такой папкой в свою домовую сеть. В течении часа там лежал первый вирус. Через сутки их было три. =)

14. В свете предыдущих пунктов встает необходимость использовать онлайн (мы для простоты считаем, что эти сервисы заслуживают доверия. Если Вы считаете иначе, то для Вас услуги фельдъегерской службы =) ) сервисы для обмена файлами. Будьте осторожны и помните, что я написал здесь. Правило 11 работает и в этой ситуации.

15. Открывать онлайн службу на запись так же нельзя. Пусть человек, который хочет передать Вам данные, откроет Вам к ним доступ на чтение.

16. Если Вы все-таки нарушили правила и Вам записали долгожданный файл... Проверьте его антивирусом до того, как открыли. Еще лучше, дайте ему вылежаться сутки-другие и проверьте еще раз. Что объяснить, image зачем, я расскажу Вам мини-историю. В процессе исследований (давайте назовем это так =) ) по одному спамерскому письму я скачал к себе (на специально для этого созданную виртуальную машину). Антивирус определил, что в этом файле только через несколько часов.

Продолжение следует.

понедельник, 29 сентября 2008 г.

Безопасность для чайника. Часть 2.

Итак, продолжаем разговор.

image 6. Ваш антивирус и firewall не должны быть отключены никогда. Ни при каких обстоятельствах. Два исключения: компьютер выключен или сломался. В самых исключительных случаях можно попробовать их отключить, когда Вы не подключены ни к какой сети и не используете никаких внешних носителей. И то… Лучше быть параноиком. =)

Итак, с активной защитой разобрались. Давайте теперь поговорим о пассивной защите, а я бы ее даже назвал проактивной.

7. Ваш пароль должен быть сложным. Реально сложным. Пароль Qq12345678 формально удовлетворяет требованиям безопасности, но он не сложный. V^0bdsdsct%s*.9jNkXr?Vf4 – сложный. Его сложно запомнить, но еще сложнее подобрать. Общее правило – не меньше 8 символов и как можно больше различных групп символов в пароле.

8. Пароль должен быть сложным не только у пользователя, под которым Вы работаете. Всем пользователям Вашей системы нужно назначить сложные пароли.

9. Я даже говорить не буду про пустые пароли. =)

10. Работайте из под обычного пользователя. Не администратор. Не Power User. Под Vista это просто – спасибо UAC. Поверьте, при нормальных приложениях UAC будет доставать только при настройке ОС и установке приложений. При штатном использовании это происходит очень редко. Вы можете спорить, можете не спорить, но это работает.

И снова продолжение следует… =)

Часть 1

Часть 3

Часть 4

пятница, 26 сентября 2008 г.

Безопасность для чайника.

image Ну, или для домашнего пользователя. Паша Нагаев как-то просил сделать такую штуку. Написать свод правил для пользователей, которые совсем не обязательно далеки от мира компьютеров вовсе, но которые не имеют зашитой на подкорку паранойи. Что нужно делать и что не нужно делать, чтобы снизить вероятность подцепить какую-нибудь гадость, потерять важные данные или не выложить свои личные данные открыто в интернете. Полностью исключить такую вероятность, конечно же, не удастся, но снижение такой вероятности уже стоящая цель. Я не уверен, что кто-то из целевой аудитории прочитает сие творение, но чем черт не шутит… =)

Возможно, кто-то спросит, насколько методы, которые я сейчас приведу действенны. Ну… Если я вспомню все, то это будет действенный набор. У меня последний живой вирус на компьютере был, не упомню уже когда. =)

Итак, приступим.

1. Антивирус на новый компьютер должен быть установлен первым. До архиватора.image Даже до FAR’а. Даже до установки обновлений. Желательно не подключаясь к сети.

2. Первое, что нужно сделать, установив антивирус – обновить его базы. (сеть не забудьте подключить ;) )

3. Антивирус должен быть обновлен максимально часто. Обычно достаточно для этого оставить настройки автообновления по-умолчанию. Не обновленный антивирус равнозначен его отсутствию. Это не шутка. Только за истекший год я неоднократно копировал к себе ради интереса файлы, которые антивирус распознавал только на следующий день. Что уж тут говорить, о защите, не обновленной полгода.

4. Вместе с антивирусом должен быть установлен и настроен сетевой экран (firewall). Так как неопытный пользователь вряд ли настроит firewall правильно (увы, это действительно не всегда просто), то нужно выбирать инструмент, который имеет встроенный профиль, делающий компьютер почти невидимкой в сети. Stealth-режим или еще что-нибудь в этом роде. Не буду рекомендовать какой-нибудь конкретный, чтобы не сочли рекламой. У меня firewall, интегрированный с антивирусом понятно какой фирмы, а дома справляется с задачей встроенный firewall Vista. image

5. Обновляйте свой компьютер. Неважно, Vista это, XP или Linux. Если есть возможность – обновляйтесь. Обновляйте не только ОС, обновляйте также и приложения – в них совокупных уязвимостей больше, чем в ОС. В Windows это делается просто, насколько я знаю, в мире разнообразных Linux за последние несколько лет это тоже стало не сложно.

Продолжение следует…

Часть 2

Часть 3

Часть 4

четверг, 25 сентября 2008 г.

SDDL: Учимся описывать безопасность. Часть 2.

SecurityВ прошлом выпуске я рассказал, как строится строка SDDL, так что мы теперь можем что-то прочитать на этом замечательном языке.
Пример 1:
В том самом посте, в котором я обещал написать этот (кстати, есть статья знаний, которая более полна, чем мой пост), я приводил такую строчку:
O:BAG:SYD:(A;;0x1;;;<SID>)
Это один  из самых простых примеров, так что с него и начнем.
1.    O:BA – владелец, в данном случае BA = Built-in Administrators
2.    G:SY первичная группа. SY = Local System
3.    D:(A;;0x1;;;<SID>): DACL
    a.    Тип ACE: A = Allow
    b.    Флаги ACE: пусто (;;)
    c.    Разрешения: 0x1 = GR = Generic Read (да-да, разрешения можно представлять и в виде цифровой строки, я об этом говорил в самом начале)
    d.    Object Type: пусто (;;)
    e.    Inherited Object Type: пусто (;;)
    f.    Trustee: наш SID, который мы искали в том посте.
Итого мы имеем объект, владельцем которого является группа администраторов, а разрешения на нее имеет только пользователь, определенный SID’ом, и только на чтение.
Пример 2:

 image
Как здесь прекрасно видно, мы смотрим SDDL строку, назначенную папке c:\temp. Ее текстовое представление:
O:BAG:DUD:PAI(D;CINP;FA;;;LG)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)
Как видите, строка весьма длинная (на самом деле, она весьма короткая, обычно больше, но я специально сделал что покороче =) ), то есть, в отличие от предыдущего примера придется попотеть.
Но приступим:
1.    O:BA – владелец, как и в предыдущем случае это группа Built-in Administrators.
2.    G:DU – Domain Users.
3.    O:BAG:DUD:PAI(D;CINP;FA;;;LG)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;FR;;;BU) – DACL
    a.    P = SDDL_PROTECTED – наследование от контейнеров выше этого заблокировано
    b.    AI = SDDL_AUTO_INHERITED – наследование разрешено вниз, но не вверх, так как выставлен флаг P. На самом деле PAI как раз обычно встречается там, где просто заблокировано наследование
    c.    (D;CINP;FA;;;LG)
        i.    Тип ACE: D = Deny – без комментариев
        ii.    Флаги наследования: CINP
            1.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
            2.    NP = NO PROPAGATE: только непосредственные «дочки объекта» будут получать эту ACE
        iii.    Разрешения: FA = Full Control
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: LG = Local Guest
    d.    (A;OICI;FA;;;SY)
        i.    Тип ACE: Allow
        ii.    Флаги наследования: OICI
            1.    OI  = OBJECT INHERIT – дочерние объекты, которые не являются контейнерами наследуют эту запись
            2.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
        iii.    Разрешения: FA = SDDL_FILE_ALL – все разрешено
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: SY = Local System
    e.    (A;OICI;FA;;;BA)
        i.    Тип ACE: Allow
        ii.    Флаги наследования: OICI
            1.    OI  = OBJECT INHERIT – дочерние объекты, которые не являются контейнерами наследуют эту запись
            2.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
        iii.    Разрешения: FA = SDDL_FILE_ALL – все разрешено
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: BA = Built-in Administrators
    f.    (A;OICI;FR;;;BU)
        i.    Тип ACE: Allow
        ii.    Флаги наследования: OICI
            1.    OI  = OBJECT INHERIT – дочерние объекты, которые не являются контейнерами наследуют эту запись
            2.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
        iii.    FR = FILE GENERIC READ – эквивалент Read
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: BU – Built-in Users
Все просто. На самом деле бывают более запутанные случаи (скорее уж бывают такие, более запутанные сплошь и рядом), но и с ними Вам помогут справиться следующие материалы:
http://msdn.microsoft.com/en-us/library/aa379567.aspx - основа основ - MSDN. Стартовая страница для серьезного разбирательства. Здесь самые подробные материалы.
http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx - «Словарик».
И сообщение в блоге, которое я нашел в процессе подготовки этой статьи:
http://blogs.technet.com/askds/archive/2008/04/18/the-security-descriptor-definition-language-of-love-part-1.aspx
http://blogs.technet.com/askds/archive/2008/05/07/the-security-descriptor-definition-language-of-love-part-2.aspx
Здесь все то же самое, но чуть более подробно, местами, чем у меня. Нашел бы раньше – просто перевел бы.

вторник, 23 сентября 2008 г.

SDDL: Учимся описывать безопасность.

image Я уже дважды обещал рассказать о страшных и жутко непонятных строках вида D:(A;;CCLCSWLOCRRC;;;AU), то есть о SDDL (Security Descriptor Definition Language). Но сначала, конечно же, о том, что это такое и зачем это нужно. Думаю, многим известно, что практически к каждому объекту в современном мире Windows прикреплен некий Security Descriptor, который описывает параметры безопасности, связанные с данным объектом, как то: кто владеет объектом, кто и каким образом может получить доступ к объекту, и что об этом доступе следует записать в журнал аудита. Security Descriptor представляет из себя некую бинарную строку, которую человеку читать можно, но сложно. Для того, чтобы облегчить чтение дескриптора, возможно и был придуман этот язык SDDL. Впрочем, для языка эта структура слишком проста – научиться «разговаривать» на этом языке достаточно просто, хотя и не слишком-то необходимо. А вот читать его и писать на нем хотя бы со словарем я считаю полезным. Иногда еще встречаются ситуации, когда это умение облегчает жизнь. Например, команды SC sdshow/sdset используют именно его. В этом же формате умеет выводить разрешения на объекты файловой системы cacls (Vista и выше) и Get-ACL (PowerShell). Да и мой пост, с которого все это началось, тоже делает такое умение полезным.

Итак, приступим. Представим себе, что мы встретились-таки со строкой вида, указанного выше. Благодаря тому, что Вы прочитали весь предыдущий поток сознания, Вы уже в курсе, что это можно прочесть. Понятное дело, что, раз это можно читать, то можно и разбить на некоторые секции, скажем, «смысловые группы». Этими группами являются:

1. Заголовок (Header). Он содержит флаги, показывающие, как данная строка соотносится с наследованием. То есть, разрешено ли оно, или нет, а также – что именно и как наследуется.

2. DACL (D:) – список собственно разрешений

3. SACL (S:) – список атрибутов аудита

4. Primary Group (G:) – оставлена для совместимости. Не используется до тез пор, пока Вы не работаете с Services for UNIX/Mac.

5. Owner (O:) – отображает владельца объекта.

Соответственно, каждый элемент заголовка сопровождается группой двухсимвольных лексем или SID’ом.

Владелец и Primary Group само собой отображаются в виде SID. Некоторые хорошо известные SID’ы отображаются как акронимы. Например, BA = Built-in Administrators. DACL & SACL представляют из себя строки, которые в свою очередь тоже состоят из различных кусков. Эти куски, заключенные в круглые скобки – ACE, которые (Вы мне не поверите!!! =) ) также дробятся на части. Эти части уже неделимы (разве что на те самые лексемы), отделяются точкой с запятой и содержат следующие параметры:

- Тип ACE (Allow, Deny, AUdit)

- Флаги ACE (наследование и настройки аудита)

- Разрешения

- Тип объекта (в виде GUID)

- Унаследованный тип объекта

- Trustee (кто бы сказал, как это нормально перевести ;). В общем это участник безопасности - пользователь, группа, и так далее)

В общем-то, все не так уж сложно: если иметь под рукой словарь, ссылку на который я дам позже – в следующем выпуске, в котором мы рассмотрим пару примеров чтения дескриптора.

понедельник, 22 сентября 2008 г.

Платформа 2009: начато голосование за доклады.

image Оно все-таки началось. Все, кто пойдут на мероприятие или будут смотреть его в прямом эфире или в записи могут проголосовать за доклады, которые они желают увидеть и услышать. Я даже настоятельно рекомендую это сделать, потому что это прекрасная возможность определить то, что будет рассказано и показано на Платформе.

В числе прочих затесалось и четыре моих темы, которые я мог бы и желаю рассказать. Три из них уже видела и слышала аудитория Московского MCP Клуба (впрочем, я не буду читать слово в слово, добавлю в них кое-что – Андрей Бешков подсказал пару идей), а четвертый будет нов даже для них. Так что голосуйте, если желаете послушать эти выступления в моем исполнении. Впрочем, если даже и не пожелаете – меня можно будет найти в секции “Спроси Эксперта”. =)

Мои доклады, которые уже известны узкой аудитории:

NAP: Введение в здоровую сеть.

Windows 2008 AD DS: Что нового?

Построение систем высокой доступности для начинающих.

И новый доклад:

Введение в ForeFront Threat Management Gateway.

четверг, 18 сентября 2008 г.

Новый подход к назначению разрешений на файловую систему в Win2008/Vista

Мне не так давно (ага, годика пол назад ;) ) поступил вопрос от тогда еще совсем не MVP Александра Станкевича – частого участника посиделок у Паши Нагаева, теперь уже MVP и всегда хорошего человека и специалиста. Вопрос звучал как-то так: «а почему теперь на многих папках в Windows есть пары разрешений для одного и того же объекта и одного и того же участника безопасности?». Я долгое время не мог добраться до ответа, но, в процессе подготовки к выпуску своего поста об SDDL, который скоро опубликую, наткнулся на, как мне кажется, ответ.

Если говорить сначала о самом вопросе, то вот что имеется в виду:

image

Как видно, здесь есть две записи для каждого пользователя/группы. Если же заглянуть внутрь, то окажется, что одна предоставляет права на саму папку, а вторая уже описывает права на подобъекты и наследование этих прав

 

 

 

image image .

Собственно, это и есть ответ (IMHO) на поставленный вопрос: Двойная запись служит для разделения управления разрешениями собственно папки и ее содержимого. То есть одна запись описывает разрешения на саму папку, а вторая те разрешения, которые наследуют от нее дочерние объекты. Разница в данном конкретном случае такая:

image

Как видно, на саму папку не выдано право изменения подпапок, изменения разрешений и take ownership, в то время, как вторая запись, описывающая поддерево дает полный доступ. В чем плюс? Не дается лишних прав на подобъекты (или наоборот, на сами объекты), унифицируется работа с разрешениями, да и вообще удобнее, если уж приспичит поковырять там что-то. В общем, я, пожалуй, перейму и для себя – надо будет попробовать именно так выдавать пермиции.

В общем, мне кажется, что я ответил на вопрос (кстати, спасибо, Stanky, сам я внимания и не обратил ;) )

понедельник, 8 сентября 2008 г.

Угрозы приватности: только ли от спецслужб и организаций нужно ждать подвоха?

На западе (у нас это пока не так актуально, то есть актуально, но, тем не менее, мало кого интересует) сейчас  многие очень пекутся о приватности и защите частной жизни от вторжения в нее государства, организаций и частных лиц. Что, впрочем, мешает оному вторжению очень мало. Да, можно запретить организациям использовать свою видеосъемку без разрешения запечатленных, установить строгий контроль над силовыми ведомствами в области прослушки и слежки. Но что, скажите на милость, можно предпринять против соседского мальчишки, который с помощью приобретенного "по случаю" чувствительного микрофона записал не только топот таракана по столу, но и разговоры соседей за стеной и выложил запись в своем дневнике? (а обсуждали соседи, скажем, как поедут отдыхать, оставив квартиру без присмотра). Или просто прохожего, который сфотографировал что-то на ходу и так же где-то разместил? А в это что-то по невероятной случайности попали Вы и, скажем, рекрутер конкурентов (которого Вы и знать то не знаете, потому что работа у Вас замечательная, и менять ее никакого желания нет). От этого защиты нет. И не будет, наверное. Просто следствие все повышающейся доступности и мобильности разнообразных средств, могущих Вас абсолютно незаметно и без спроса запечатлеть.

З.Ы. Для любителей поспорить: да, ситуации надуманные и утрированные. Однако, возможные. Кроме того, это сообщение вообще из разряда "мысли вслух" о том, что опасаться следует не только неправомерного государственного надзора.