Сервер в кармане, или просто о сложном!

Авторизация Squid в домене Windows 2003

Обновлено: 13.09.2025
Теги: Настройка прокси Squid

Введение

Многие небольшие организации используют домены Windows для управления учетными записями пользователей. Но далеко не все устанавливают у себя платные решения на ISA Server, Kerio WinRoute или др. Также можно сказать, что многие небольшие организации привлекают (за неимением своего) стороннего специалиста для настройки доступа в интернет с возможностью контроля доступа сотрудников (кто-что скачал и т.п.). В таких случаях часто имеет место настройка Squid на базе Linux / FreeBSD.

Удобство работы, простота и доступность Squid привлекает к себе многих, но как разрешить ходить в интернет только определенным сотрудникам, причем, желательно, поудобнее этим процессом управлять?

Вариант 1: настроить Squid на фильтрацию по IP-адресу. В небольшом офисе из 2-5 машин это может быть удобным, но если машин 20 и более? Все равно будет ротация машин (замена на новые, сотрудники могут меняться местами и пр.). При этом неизбежно для одного и того же человека IP-адрес будет меняться. Поэтому это хоть и простой вариант, но не самый удобный.

Вариант 2: уж коль мы вначале статьи решили, что наша сеть с контроллером домена Windows 2003, намного удобнее управлять доступом в интернет, управляя учетными записями пользователей из домена. Проблема в том, что Squid, хоть и поддерживает эту возможность, реализация ее не совсем очевидная, по крайней мере, вы уже должны были не раз и не два встретить на формах кучу вариантов, причем часто в обсуждении пишут о больших сложностях. Особенно, что касается внедрения авторизации через samba. Я сам, пролистав несколько таких руководств с кучей листингов и скриптов, отказался от мысли сразу ломиться в бой. Вместо этого я решил разделить задачу на два этапа, причем максимально проще и без скриптов по 50 строк каждый: 

1 этап: проверка работы авторизации squid в домене;

2 этап: внедрение этого способа в рабочий squid.

Проверка авторизации Squid в домене Windows 2003

Для начала проверим, как вообще работает авторизация Squid в домене Windows. Нам будет нужен файл "squid_ldap_auth". В зависимости от операционной системы прокси-сервера, этот файл может быть в разных местах, у меня в CentOS он находиться по адресу:

/usr/lib/squid/squid_ldap_auth

 Теперь создадим отдельное организационное подразделение в домене Windows 2003:

В русском варианте примерно тоже самое, только вместо "Organization Unit" будет "Подразделение".

Создадим в этом подразделении двух пользователей: SquidWebAccess (пароль "squid") и testuser (пароль "12345"). Права для этих пользователей - минимальные.

Пользователь SquidWebAccess нужен для того, чтобы от его имени Squid мог обращаться к контроллеру домена для проверки существования других пользователей. Естественно, пароль от этого пользователя должен быть неизвестен пользователям вашей сети.

Пользователь testuser - это имитация реального пользователя.

На этом этапе возникнет вопрос - а с чего это в уже настроенной структуре пользователей домена с отработанными политиками безопасности и пр. делать отдельного пользователя в новом OU, а не использовать текущие учетные данные? Ответ: можно использовать и те учетные записи, которые уже настроены. Но при этом теряется малая часть гибкости: если надо будет запретить пользователю доступ к интернет (за провинность, например), в моем случае не придется отключать его основную учетную запись домена. Я просто отключу учетную запись для доступа в интернет. Можно спорить, что удобнее, что нет. Мне удобнее разделить доступ в интернет от доступа к файлам и пр.

Заходим на прокси-сервер (где Squid) и вводим команду (в одну строку, у меня разделены символом \):

/usr/lib/squid/squid_ldap_auth -v 3 -R -D SquidWebAccess@domain.local -w squid \
-b "ou=InternetUsers,dc=domain,dc=local" -f "sAMAccountName=%s" 192.168.1.2

где

считаем, что домен называется "domain.local"

-D SquidWebAccess@domain.local - полное имя пользователя для возможности Squid сравнить введенные данные пользователя с теми, которые мы задали пользователю testuser

-w squid - пароль пользователя SquidWebAccess

-b "ou=InternetUsers,dc=domain,dc=local" - полный путь до места хранения учетных записей пользователей для доступа в интернет. Заметьте, что использовать свои учетные записи (в т.ч. учетную запись администратора домена) для доступа в интернет не выйдет! Можете это считать дополнительной опцией безопасности.

192.168.1.2 - ip-адрес контроллера домена Windows 2003.

После выполнения команды вводим:

testuser 12345

В ответ должны получить OK. Если нет, то ищем, описать все возможные варианты проблем - задача нереальная.

Если все OK, то переходим ко второму этапу: внедряем авторизацию squid в домене уже в самом прокси-сервере Squid, а не в тестовом варианте.

Авторизация Squid в домене Windows 2003

Для настройки авторизации в Squid, нам нужно изменить только squid.conf.

# LDAP-авторизация
# В одну строку, или разделяйте символом \

auth_param basic program /usr/lib/squid/squid_ldap_auth -v 3 -R -D SquidWebAccess@domain.local -w squid \
  -b "ou=InternetUsers,dc=domain,dc=local" -f "sAMAccountName=%s" 192.168.1.2

auth_param basic children 5
auth_param basic realm Web-Proxy
auth_param basic credentialsttl 1 minute

acl ldap-auth proxy_auth REQUIRED

http_access allow ldap-auth
http_access allow localhost

http_access deny all  

Остальные настройки Squid трогать не надо. Перезапустите Squid:

/sbin/service squid restart
Stopping squid: ........[ OK ]
Starting squid: ........[ OK ]

 Наслаждайтесь :) Про подсчет трафика с учетом такой авторизации напишу позже.


Скорость перебора паролей на CPU и GPU

Обновлено: 13.09.2025
(с) Иван Голубев, http://www.golubev.com
29 мая 2009 г.
«косметическая» правка 14 августа 2009 г.

Вычисления на GPU в последнее время стали очень популярными во всех областях, где есть возможность их использовать. Одним из таких направлений является криптография, более узко – подбор / перебор паролей. К сожалению, реальные результаты работы (как обычно это и бывает) приукрашаются в маркетинговых целях, так что становится не очень ясно, какой на самом деле выигрыш от использования GPU в этой области.

Длинные объяснения заканчиваются краткими выводами (которые, вероятно, и стОит прочитать при первом ознакомлении с этой статьёй).

На что тратится время при переборе паролей.

Если с десять лет назад каждый разработчик пытался придумать какой-то свой, оригинальный алгоритм шифрования (но, так как почти никто не был экспертом в области криптографии, подавляющее большинство таких «оригинальных» алгоритмов ломались в момент), то теперь с этим стало гораздо проще. Практически везде используются проверенные и стандартные схемы.

Для шифрования сначала необходимо преобразовать пароль в ключ заданного вида и размера (этап хэширования), а потом уже с помощью этого ключа собственно зашифровать данные (с помощью любого надёжного алгоритма вроде AES).

Для хэширования ещё совсем недавно массово использовался MD5, но (после обнаружения уязвимостей в алгоритме) его довольно быстро заменил SHA1. С SHA1 в данный момент уже тоже не совсем всё гладко (сложность нахождения коллизии составляет примерно 2^63, а недавно ещё и заявили о снижении этого числа до 2^52), но при использовании его в каком-нибудь «обрамлении» вроде PBKDF2 сложность (а, точнее, легкость) нахождения коллизии уже не так важна.

Один очень важный момент: при проверке паролей определяющей чаще всего является именно скорость хэширования, а не скорость шифрования. Практически везде сейчас используется так называемое «key strengthening», то есть усиление ключа путём добавления сложности на этапе генерации пароль -> ключ. Вместо одного преобразования SHA1 можно выполнить 10000, подавая результат первой итерации как вход на вторую и т.д. Для валидных паролей, которые собственно проверяются один раз, разница незаметна – генерится ключ 0.01 мс или 10 мс совсем не важно. А вот для задачи перебора паролей, когда проверяются миллиарды комбинаций, это уже очень ощутимо. Если, например, какой-то пароль можно подобрать за месяц, то он явно не стойкий. Однако, если использовать схему «усиления ключа» с дополнительными 10000 итераций, то на подбор того же самого пароля уйдёт уже не месяц, а 830 лет, что переводит пароль в разряд довольно устойчивых.

Алгоритм PBKDF2, описанный в RFC 2898, сейчас является одним из самых популярных для «key strengthening» и используется во многих приложениях. Рекомендуемый минимум итераций в нём составляет 1000 (а одна итерация требует выполнения двух SHA1_Transform действий, о которых ниже).

В некоторых случаях для проверки валидности пароля вообще не надо расшифровывать файл. Например, появившееся в WinZip 9 сильное шифрование на основе AES 128 & 256 bit на самом деле до AES доходит только в случае абсолютной правильности проверяемого пароля. Во всех остальных случаях выполняется только PBKDF2, который в свою очередь использует только SHA1. В RAR 3.x до AES доходим после 262144 итераций SHA1. Так что на фоне такого количества SHA1 инициализация и расшифровка нескольких байт с помощью AES занимает мизерные доли процентов от общих вычислений. В MS Office 2007 используется 50 000 итераций SHA1, в WPA, как и в WinZip, PBKDF2, но уже с количеством итераций 4096.

В PDF9 Adobe сильно промахнулся с новым алгоритмом, взяв одну итерацию SHA256 вместо 50-ти MD5 + 20x RC4, что ускорило скорость перебора паролей по сравнению с предыдущей версией практически на два порядка. Но валидация пароля после хэширования не требует никакого шифрования, так что и тут важна только скорость SHA256.

Правильный алгоритм шифрования делает невозможным сокращение пространства перебора для ключей. То есть, чтобы найти, например, 128-ми битный ключ надо перебрать 2^128 == 3.4 * 10^38 вариантов. Если допустить, что один компьютер перебирает один миллиард вариантов в секунду, у нас есть миллиард компьютеров и мы располагаем миллиардом лет, то за это время мы сможем проверить всего лишь 10^9 * 10^9 * 10^9 * 60 с * 60 м * 24 ч * 365.25 д ~= 3.16 * 10^34 вариантов, меньше 1/10000 требуемого диапазона.

Пример неудачного алгоритма шифрования: в классическом zip используются 96-ти битные ключи. Несмотря на прошедшие уже 20 лет с момента создания алгоритма, эти ключи до сих пор невозможно перебрать «в лоб». Однако, имея часть незашифрованного файла, можно провести так называемую plaintext attack, при этом сложность перебора упадёт с 2^96 всего до 2^38, что составляет всего пару часов работы для современного компьютера.

Все «сильные» алгоритмы шифрования (AES, Blowfish, etc) не позволяют провести plaintext атаку и не позволяют сократить пространство перебора. Так что единственная возможность получить доступ к зашифрованным файлам – знать правильный пароль.

Вывод: используемый алгоритм шифрования практически никак не влияет на скорость перебора паролей. Хороший алгоритм просто обеспечивает невозможность подбора ключа «в лоб». А вот уже для перебора паролей главным является именно преобразование пароля в ключ, а за это отвечают алгоритмы хэширования (MD5, SHA1), а не алгоритмы шифрования (AES, Blowfish).

Значение «количество итераций» мало что говорит.

MD5, SHA1 (и его потомки в виде SHA256, 384, 512) очень похожи. На входе есть состояние хэша (128 бит для MD5, 160 бит на SHA1) и блок данных размером в 512 бит (64 байт). На выходе, после операции хэширования, получаем новое состояние хэша. Это сердце алгоритма, функция обычно называется MD5_Transform, SHA1_Transform, etc.

Важно заметить, что размер блока является константой, всегда хэшируются именно 64 байта. Если подать на вход 1 байт, то он будет дополнен до 64 путём добавления нулей, символа-терминатора и 8-ми байтового значения длины блока. То есть, подать отдельно на вход хэш-функции 64 раза по 1 байту или один раз 64 байта – абсолютно одинаково в плане скорости обработки (не считая того, что при подаче 64 байт придётся символ-терминатор и значение длины обрабатывать уже в следущем блоке).

Для некоторых алгоритмов пишется количество итераций как количество вызовов функции по обновлению хэша. Но не всякое обновление ведёт к вызову Transform функции. Данные накапливаются в буфере и отдаются на Transform блоками по 64 байта. Например для RAR 3.x количество итераций равно 262144, но количество обрабатываемых блоков будет равно ((длина_пароля * 2 + 8 + 3) * 262144) / 64. Что, например, для паролей длиной в 4 символа составит 77824 (+ещё 17 дополнительных блоков для создания IV для AES).

Для алгоритма PBKDF2 требуется на каждую итерацию обработать 2 блока плюс ещё 2 для инициализации. Иными словами, для проверки одного пароля WinZip/AES (где количество итераций равно 1000) надо выполнить 2002 операции SHA1_Transform.

В Office 2007 используется 50 000 итераций и обрабатывается блок в 20 байт. Но подаются эти байты каждый раз отдельно, поэтому выходит именно 50 000 вызовов SHA1_Transform, а не 50000*20/64 = 15 625.

Что даёт приведение количества итераций к количеству блоков для Transform? Так как время вычисления хэша не зависит от данных в блоке и является константой, зная время хэширования одного блока и количество блоков, можно легко посчитать общее время хэширования. Также легко оценить, насколько быстрее или медленнее разные алгоритмы генерации паролей относительно друг друга.

Например, на основе рассчётов выше выходит, что скорость перебора паролей WinZip/AES в ~39 раз быстрее, чем 4-х символьных паролей в RAR 3.x. А скорость перебора паролей для Office 2007 в 25 раз ниже, чем для WinZip/AES. Точность этих вычислений, конечно, приблизительная. Для сложных алгоритмов инициализации блока данных (как в RAR 3.x) такая оценка может давать заметную ошибку. Но в большинстве случаев достаточно знать только порядок величины, а не абсолютное значение.

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

Насколько быстро можно хэшировать?

Теперь нас интересует вопрос, насколько же быстро можно обработать один 64-х байтный блок данных. Операции, используещиеся в Transform функции, самые простейшие – логические OR, XOR, NOT, AND, арифметическое сложение, сдвиги. Все действия производятся над 32-х битными целыми. Один блок данных легко помещается в кэш L1 любого из современных процессоров, так что скорость работы с памятью, её размер, размер L2 или RPM дискового накопителя не играет никакой роли. Иными словами, скорость перебора находится в прямой зависимости от скорости целочисленного ALU и практически никак не зависит от всего остального. У какого же из современных процессоров с этим лучше всего?

Процессоры.

Так как хэширование разных паролей никак не зависит друг от друга, то очень выгодно использовать какой-нибудь SIMD набор инструкций для их параллельной обработки. Лучше всего подходит SSE2 (хотя и от «старого» MMX до сих пор есть польза), позволяющий выполнять какую-либо операцию сразу с четырьмя 32-х битными операндами. В своем первом воплощении в Pentium 4 со скоростью работы SSE2 инструкций было не всё гладко (например, пересылки регистр->регистр стоили 6 тактов, а выполнение OR всего 2), но уже тогда выигрыш от их применения был вполне ощутимым. В данный же момент реализация SSE2 в Intel Core архитектуре просто великолепна: можно выполнить 3 операции за такт, причём результат будет готов уже на следующем такте (latency == 1 такт). То есть, пиковая производительность у Core составляет 12 операций с 32-х битными целыми за такт. Хотя не все операции можно выполнять на этой пиковой скорости.

Несмотря на появление новых ревизий ядра, перехода с 65nm на 45nm и, наконец, выхода Core i7, никаких заметных изменений в целочисленном ALU не произошло. Поэтому Core i7 работает практически также, как и его 65nm предок Core 2. Производительность зависит только от частоты, поэтому, например, Q6600 разогнанный до 3-х Ггц (что является вполне обычной практикой) будет ровно на 3/2.66 = 12.7% быстрее, чем Core i7 920 на штатной частоте (не считая turbo burst). Стоимость же Core i7, включая материнскую плату и память DDR3 заметно выше, чем у «старых» систем на Core 2 65/45nm.

Ситуация с AMD несколько хуже. Даже сейчас существует ещё довольно много систем с процессором Athlon XP. В своё время он очень хорошо конкурировал с P4, но вот SSE2 в нём нет. В архитектуре K8 AMD сделала поддержку SSE2, но в самом примитивном виде: 128-ми битные инструкции разбивались на две половинки и запускались на 64-х битном ALU. Что приводило к тому, что разницы между MMX кодом и SSE2 практически не было.

С появлением K10 (или Phenom) AMD наконец сделала поддержку SSE2 более достойным образом, однако Core 2 она заметно уступает. K10 может выполнить до 2-х операций с 4-мя 32-х битными целыми за такт, а результат операции будет готов только через такт (latency == 2 такта). То есть, пиковая производительность составляет 8 операций с 32-х битными целыми за такт. Что это означает в плане сравнения K10 vs Core 2: процессор от AMD будет в среднем в 1.5 раза медленнее, если мы сможем выстроить инструкции таким образом, чтобы latency не была лимитирующим фактором. В некоторых алгоритмах, учитывая ограниченное количество XMM регистров, сделать это очень непросто, а то и невозможно.

С другой стороны, не все операции Core 2 может выполнять на уровне «три за такт». Сложений можно выполнить только два, а сдвигов вообще один. K10 же умеет сдвигать два XMM регистра за такт, но уже с latency в 3 такта. Поэтому реальное соотношение производительности Core 2 vs K10 плавает где-то в районе 1.25-2x. K10 всегда медленней на задачах, которые зависят только от скорости SSE2 ALU, но может быть быстрее на алгоритмах со множеством чтений из памяти и отсутствием логических операций.

Phenom II, появившийся не так давно, отличается от просто Phenom'а гораздо меньше, чем Core i7 от Core 2 45nm. Но стоит, конечно, дороже.

Важно заметить, что в данный момент использование SSE2 является обязательным при параллельной обработке данных. Логическая операция над 32-х битным регистром или над 128-ми битным xmm регистром, содержащим четыре 32-х битных значения, выполняется за абсолютно одинаковое время. Считать на Core 2 без SSE2 это всё равно что взять GPU и отключить на нём ¾ всех потоковых процессоров.

Также, задача перебора паролей идеально распараллеливается, так как нет никакой зависимости между данными. Поэтому производительность растёт линейно в зависимости от частоты и количества ядер. Нет никакого смысла использовать «быстрый» двухядерник, если есть возможность задействовать «медленный» четырёхядерник. Иными словами, Q6600 на частоте 2.4Ггц будет работать как 4*2.4 = 9.6Ггц, а E8600 3.33 Ггц только как 3.33 * 2 = 6.66Ггц. Разница в скорости в 1.5 раза, а разница в цене примерное такая же, но в другую сторону.

Вывод: Лучшим процессором для перебора паролей в данный момент является Intel Core Quad. По соотношению цена / производительность выгоднее модели Core 2 65/45nm. Стоимость систем на Core i7 выше, а частота ничуть не лучше, чем у «старых» Core 2. Процессоры от AMD заметно отстают на SSE2 целочисленных вычислениях и при этом разница в цене между Core 2 и Phenom ничуть не компенсирует этого отставания. SSE2 обязательно к употреблению, иначе возможности современных процессоров просто не раскрыть.

Так всё-таки насколько быстро можно хэшировать?

Подробные рассчёты затрагивают слишком много деталей и требуют отдельной статьи, поэтому рассмотрим кратко только MD5. MD5_Transform состоит из 64 итераций. В каждой итерации используются похожие операции. Подробное описание можно найти, например тут – http://en.wikipedia.org/wiki/MD5.

Очень грубо скорость по количеству используемых операций можно оценить так:

 

Intel Core

F

G

H

I

Логические (L)

4

4

3

4

Сложение (A)

4

4

4

4 + CMP

Сдвиги (S)

2

2

2

2

Пересылки (M)

2

2

2

1

Возможное группирование инструкций

SAL

SAL

AML

AML

SAL

SAL

AML

AML

SAL

SAL

AML

AM.

SAL

SAL

AML

ACL

256 / 4 = 64

тактов на один блок

4 * 16

4 * 16

4 * 16

4 * 16

 

Ради сравнения – то же самое для AMD K10:

 

AMD K10

F

G

H

I

Логические (L)

4

4

3

4

Сложение (A)

4

4

4

4 + CMP

Сдвиги (S)

2

2

2

2

Пересылки (M)

2

2

2

1

Возможное группирование инструкций

SA

SA

AM

AM

LL

LL

SA

SA

AM

AM

LL

LL

SA

SA

AM

AM

LL

L.

SA

SA

AM

AL

CL

LL

376 / 4 = 94

тактов на один блок

6 * 16

6 * 16

5.5 * 16

6 * 16

 

Конечно такая оценка не учитывает много разных факторов, однако подходит чтобы быстро понять, насколько быстро теоретически можно выполнять MD5_Transform. Опытные же результаты, как обычно, выглядят похуже. Но не так уж сильно:

MD5_Transform 72 такта в 64-х битном режиме.

MD5_Transform 90 тактов в 32-х битном режиме.

MD5_Transform в простейшей реализации на SSE2 при обработке всего 4-х блоков за раз 128 тактов.

SHA1_Transform 175 тактов в 32-х битном режиме, 162 такта в 64-х битном.

С SHA256 точного значения нет (так как используется SHA256 значительно реже), но SHA256_Transform займёт как минимум 425 тактов. Присутствие значительного бОльшего количества сдвигов и сложений скорее всего увеличит это значение.

Использование 64-х битного режима позволяет задействовать в два раза больше XMM регистров, что, в свою очередь, помогает решить проблемы с latency. Особенно сильно это влияет на MD5, где операций очень мало, так что постоянно приходится ждать результаты предыдущих вычислений, если обрабатывать всего 4 блока данных за раз.

Теоретические и практические результаты.

Ну и наконец сводная таблица, ради которой всё и затевалось. Сравнение скоростей для различных видов паролей. Были использованы:

Скорость замерялась на одном ядре Intel Core 2 Q6600 @ 2.4Ггц, ATI HD4850 на штатной частоте 625Мгц, nVidia GTX 260 /w 192SP тоже на штатной частоте 1.242Ггц.

 

Алгоритм

Количество блоков

Требуется тактов

Теоретическая скорость

Практическая скорость

ATI HD4850

x

GTX 260

x

RAR 3.x

passlen = 4

(4 * 2 + 11) * 4096 + 17 = 77841 x SHA1

13 622 175

176

160(ARCHPR)

168 (crark)

3120

19.5

2080

12.4

RAR 3.x

passlen = 6

(6 * 2 + 11) * 4096 + 17 = 94225 x SHA1

16 489 375

145

134 (ARCHPR)

2625

19.5

1695

12.6

WinZip AES

(1000 + 1) * 2 = 2002 x SHA1

350350

6850

6700

135K

20.1

-

-

WPA

(4096 + 1) * 2 * 2 = 16388 x SHA1

2867900

836

820

14К

17

9800

12

MS Office 2007

50005 x SHA1

8750875

274

94

-

-

3300

37.5

PDF9

1 x SHA256

-

-

5.09M

-

-

74.4M

14.6

MD5 single hash

1 x MD5 * (45/64)

51

47M

44.5M

891M

20

563M

12.7

 

Как видно, соотношение скоростей на GPU к скорости на CPU довольно однообразное. ATI HD4850 примерно в 20 раз быстрее одного ядра Q6600 на частоте 2.4Ггц, GTX 260 примерно в 12 раз. Значение 37.5 для Office 2007 появилось только из-за неоптимизированного CPU кода (забавно что для Office 2007 используется SSE2, но настолько неудачно, что лучше бы вообще не использовался). Скорость перебора на GPU зависит только от частоты работы ALU (всё как с CPU), скорость памяти и объём ничего не значат. Зная разницу в частоте и количество SP можно довольно точно оценить производительность разных GPU одного семейства.

Сравнивать напрямую по цене CPU и GPU довольно глупо – видеокарта не может работать самостоятельно, да и CPU тоже. Системы с двумя и более процессорами сразу уводят нас на другой уровень цен, в то время как нет никакого экономического смысла рассматривать эти (серверные) процессоры с большим L2 кэшем для задач перебора паролей. С GPU же ограничивающим фактором является количество PCI-E разъёмов на материнской плате. На самых простейших платах он всего один, на большинстве – два. Материнские платы с 4-мя разъёмами уже довольно редки. Причём нужно не только 4 разъёма, но ещё и место под сами карты – занимают-то они обычно 2 слота. 4 раза по 2 слота встречается, судя по всему, только у MSI K9A2 Platinum. Есть 6-ти слотовый P6T6 WS Revolution, но там могут поместиться только «одинарные» карты.

Похоже, собрать систему с 4-мя ATI HD4870x2 невозможно в принципе (неплохое описание всех возникающих проблем тут: http://forums.guru3d.com/showthread.php?p=2862271). Системы с 4-мя двойными nVidia картами существуют (например http://fastra.ua.ac.be/en/specs.html), но проблем и там хватает. Начиная с мощного блока питания и корпуса, куда можно всё нормально поместить и заканчивая установкой драйверов.

В итоге получается такой список с точкой отсчёта производительности на 4-х ядрах Q6600 на частоте 2.4Ггц:

 

Название

Частота, кол-во ядер

Соотношение

Цена CPU или GPU

Общая цена системы

E2160

1.8 x 2

0.38x

?

<$300

Q6600

2.4 x 4

1x

$220

~$600

nVidia 8600 GT

1.188 x 32

0.5x

?

~$650

nVidia 9800 GT

1.242 x 112

1.75x

$120

~$720

ATI HD4770

0.75 x 640

5x

$100

~$700

ATI HD4850

0.625 x 800

5x

$120

~$720

nVidia GTX295

1.242 x 240 x 2

7.5x

$500

~$1200

ATI HD4870x2

0.75 x 800 x 2

12x

$400

~$1100

4x ATI HD4770

0.75 x 640 x 4

20x

$400

~$1200

2x ATI HD4870x2

0.75 x 800 x 2 x 2

24x

$800

~$1600

4x nVidia GTX295

1.242 x 240 x 2 x 4

30x

$2000

>$3000

TACC1441 FPGA

?

2.4x

$4000

~$4500

 

Для систем с медленными GPU (вроде 8600 GT) имеет смысл считать производительность как CPU+GPU (что тут сделано не было). Для быстрых же GPU процессор будет загружен дополнительными рассчётами и синхронизацией задач, так что считать дополнительно на нём просто не имеет смысла. В некоторых случаях четырёхядерного процессора может и не хватить для систем с 8-ю GPU.

Как видно, самым интересным решением в плане цена/производительность является связка из 4-х HD4770. Однако, опять же, требуется материнская плата, где можно разместить 4 такие карты – несмотря на то, что HD4770 одночиповая карта, система охлаждения занимает дополнительный слот.

TACC1441 приведён для примера в качестве «железного» решения. Это плата на основе FPGA, поддерживается ПО от AccessData (http://www.forensic-computers.com/TACC1441.php). Как видно, никакой конкуренции современным GPU он составить не может.

Осталась одна «маленькая» проблема – практическое полное отсутствие ПО для карт ATI. Карты от nVidia поддерживаются в ElcomSoft's Distributed Password Recovery, а вот с ATI пока всё совсем плохо.

Вывод: прирост в производительности от использования одного GPU примерно 4х-5ти кратный по сравнению с современной четырёхядерной системой. Карты от ATI заметно быстрее при той же цене, однако для них практически нет ПО. При росте количества GPU в системе нелинейно растут проблемы – появляется потребность в мощном блоке питания, специальном корпусе, эффективной системе охлаждения и т.д.

А почему такой маленький прирост?!

TACC1441 обещает 60-ти кратный прирост. EDPR декларирует 100x и 200x. Почему же тут получилось «только» 30? Ответ прост: маркетологи и пиарщики тоже работают. Сравнивая неоптимизированный CPU код на системе начального уровня с top решением на 4xGTX295 можно получить совершенно потрясающий результат. Например такой: E2160 1.8Ггц vs 4xGTX295 для документа MS Office 2007 в EDPR == прирост в 229 раз!

Вывод: всегда полезно думать самому.

Какие пароли можно считать стойкими?

 

Алгоритм

Длина

Набор символов

Количество вариантов

Время перебора на «обычной системе» Q6600 + HD4770

Время перебора на системе 4xGTX295

Время перебора на суперкластере 100x 4xGTX295

RAR 3.x

4

Латинские маленькие + большие + цифры + спецсимволы

96^4 = 84934656

7.6 часов

1.5 часа

45 сек

RAR 3.x

6

Латинские маленькие + большие + цифры + спецсимволы

96^6 = 782757789696

8 лет

1.33 лет

5 дней

WPA

8

Латинские маленькие + большие + цифры

62^8 = 218340105584896

495 лет

82 лет

300 дней

WinZip 9+

8

Латинские маленькие + большие + цифры

62^8 = 218340105584896

51 год

8.5 лет

31 год

 

Вывод: неутешительный для brute-force атаки. При правильно выбранном пароле из 8-ми символов подобрать его в осмысленное время просто невозможно.

Настройка 3proxy: пример

Обновлено: 13.09.2025
Теги: 3proxy Настройка прокси

Автор: Kirill Lopuchov, lopuchov at mail ru

Источник: 3proxy.ru, SECURITYVULNS.RU

Довольно часто перед системным администратором встает задача предоставить доступ к Internet ресурсам группе пользователей (небольшой офис,Internet кафе). Данную задачу можно решить несколькими способами, это настройка на Internet шлюзе:

  • proxy сервера
  • службы NAT (трансляция сетевых адресов)
  • раздать каждому пользователю реальный IP адрес

Давайте рассмотрим первый самый простой способ подключения, это proxy сервер традиционно для таких целей применяется популярный proxy Squid, но не всегда бывает необходимость в столь тяжеловатой программе :), да и в squid отсутствует такие иногда необходимые вещи как SOCKS4/5 сервер, TCP/UP порт маппинг. Поэтому вторым номером хочется представить вашему вниманию PROXY сервер, по названием "3proxy" адрес сайта http://3proxy.ru/ разработанный нашим программистом из г. Нижний Новгород. Одним из главных его достоинств мне кажется это компактность и высокая переносимость. Код сервера написан так, что легко компилируется как для Win9x/2000/XP так и для Linux и FreeBSD.

Возможности 3proxy

Сервер поддерживает следующие возможности:

  • HTTP(S) proxy
  • FTP over HTTP proxy
  • SOCKS4/5 proxy
  • POP3 proxy
  • TCP & UDP маппинг портов
  • листы доступа к различным службам и адресам
  • ограничение пропускной способности канала каждого пользователя (чтобы пользователь не съел весь канал, качая кучу файлов в несколько потоков :) )
  • ограничение трафика пользователя на день, неделю и месяц
  • ведение журналов через ODBC (по моему такого нет ни в одном proxy) и syslog и т.д
  • авторизацию пользователей ко всем proxy службам по имени и паролю или по ip адресам

К недостаткам можно отнести это отсутствие кэширования информации :-|. Но в с последнее время Inernet контент становится все более динамическим (то есть не поддающийся кэшированию) и может быть для кого-то экономия в 25% трафика за счет его кэширования не будет столь критична. Для тех кому все же критична, автор предлагает пока использовать цепочку из 2х серверов и в качестве кэша такие сервера как wwwoffle или им подобные, либо ждать появления поддержки кеша в 3proxy :)

Установка 3proxy

# wget http://3proxy.ru/current/3proxy.tgz
# tar -xvzf 3proxy.tgz
# cd 3proxy
# make -f Makefile.unix
# mkdir /usr/local/3proxy
# mkdir /usr/local/3proxy/logs
# mkdir /usr/local/3proxy/stat
# copy 3proxy /usr/local/3proxy
# copy 3proxy.cfg.sample /usr/local/3proxy/3proxy.cfg
# chown -R nobody:nogroup /usr/local/3proxy

Далее приведу небольшой пример конфигурационного файла 3proxy.cfg с комментариями, более подробную информацию по конфигурированию можно найти файле 3proxy.cfg.sample или в HowTo http://3proxy.ru/howtor.asp и FAQ http://3proxy.ru/faqr.asp.

Конфиг 3proxy

-------------3proxy.cfg-------------
# ВНИМАНИЕ !! не должны быть пробелов
# перед любыми опциями конфигурации !!

# ip адрес DNS сервера провайдера или локального
nserver 127.0.0.1
timeouts 1 5 30 60 180 1800 15 60

# создаем двух пользователей vasia и petia
# и назначаем им пароли 24555 , 14656 и 45455 соответственно
users vasia:CL:24555
users petia:CL:14656
users vova:CL:45455

# лог файл со списком запросов пользователей
# будет создаваться каждый день новый
log /usr/local/3proxy/logs/3proxy.log D
logformat "%d-%m-%Y %H:%M:%S %U %C:%c %R:%r %O %I %T"

# внешний интерфейс
# (через который будут уходить запросы от сервера)
external 0.0.0.0

# ip адрес интерфейса на котором будут приниматься
# запросы от клиентов
internal 172.16.0.1

# устанавливаем тип авторизации по имени и паролю
auth strong
# разрешаем доступ к портам 80,8080-8088
allow * * * 80,8080-8088
# расскоментировать секцию parent если у вас есть прокси верхнего
# уровня и заменить ip,порт,имя пользователя и пароль на свои занчения
# parent 1000 http 192.168.0.1 8080 username passwd
# allow *
# запускаем службу HTTP proxy на порту (3128 и
# -n c отключенной NTLM авторизацией)
proxy -p3128 -n

# ограничиваем толшину канала для каждого
# пользователя vasia и petia в 20000 bpsv # а для vova 10000 bps
bandlimin 20000 vasia,petia
bandlimin 10000 vova

# запускаем сервер от пользователя nobody
# (возможно в вашей ОС uid и gid пользователя nobody
# будут другими для их определения воспользуйтесь коммандой id nobody)
setgid 65534
setuid 65534
------------------------------------

После того как мы создали конфигурационный файл сервера , запускаем 3proxy командой:

/usr/local/3proxy/3proxy /usr/local/3proxy/3proxy.cfg

Настройка повторителя (репитера) для беспроводной сети WiFi с поддержкой WPA/WPA2-PSK

Обновлено: 13.09.2025
Теги: WiFi WDS

Введение

ВАЖНО!

28.10.2011: статья написана в декабре 2009 года. С тех пор (сейчас октябрь 2011) кое-что поменялось в этом мире. Появились новые модели репитеров WiFi, например, Asus RT-N12. С точки зрения принципиальных вещей, статью просмотреть все же стоит, просмотрите комментарии. Ведь кроме появления новых моделей и ухода старых, максимум поменялись кнопочки настройки повторителя. Суть осталась прежней. Отчасти это следствие того, что это все еще территория, не охваченная жесткими стандартами. Поэтому оборудование лучше брать одного производителя. Я начал работать с Asus и пока не жалел. Это не говорит о том, что сеть на основе других точек доступа, например, D-Link DWL-2100AP, будет хуже.

28.02.2012: эту статью я дополнял несколько раз, поэтому те, кто попадает сюда, смотрите сразу конец статьи: дополнения.

Первое название статьи: "Распределенная беспроводная сеть WDS. Настройка WiFi повторителя (репитера)".

Но как я выяснил позже, WDS в реализации базовых прошивок от Asus не поддерживает WPA/WPA2.

Поддержка WPA2-PSK возможна только при использовании точек доступа/маршрутизаторов в режиме повторителя (repeater или URE). Либо надо прошивать в DD-WRT и ей подобные.

Комментарий специалиста службы тех. поддержки Asus:

WDS используется , в случае когда нет возможности соединить точки с помощью кабеля.
У WDS есть слабые стороны как уменьшается скорость работы по WiFi т.к. для связи между точками используется один и тотже канал, проблема совместимости между разными производителями, шифрование только WEP.

URE это повторитель сигнала, сигнал повторяется без какой либо обработки по аналогии с проводным повторителем - хабом, когда принятый пакет просто повторяется во все порты, или с антеным крабом, когда входной сигнал повторяется в два или более выходов.

WDS работает на основе мак адресов по аналогии с сетевым коммутатором - свитчем, поэтому в WDS необходимо прописывать мак адреса соседей.

Поэтому название статьи я поменял на "Настройка повторителя (репитера) для беспроводной сети WiFi с поддержкой WPA/WPA2-PSK".

В этой статье описывается способ расширения зоны действия беспроводной сети на основе оборудования Asus класса дом/малый офис. Например, Asus WL-320gE и Asus WL-520gU. Статья написана по мотивам настройки конкретной сети в квартире в условиях плохого приема. Т.е. все нижеизложенное работает, причем стабильно.

Часто в небольшом, но и не в маленьком помещении (офис, квартира с множеством бетонных стен, двухэтажные помещения) сигнал от одного маршрутизатора недостаточно силен, чтобы уверенно покрыть все пространство. В таких случаях становиться необходимым настроить усилитель (он же репитер, повторитель) WiFi сигнала.

Одним из вариантов решения проблемы может быть установка отдельных маршрутизаторов в соседних помещениях, с разными сетями. В этом случае разрозненные участки сети смогут выходить в интернет на хорошей скорости, но при этом не смогут взаимодействовать друг с другом. Для домашней WiFi сети вариант приемлемый, но не для офиса.

Итак, нам нужно, чтобы на всем пространстве офиса была стабильная сеть WiFi. Для этого нам нужно иметь два устройства – маршрутизатор WiFi и точку доступа WiFi с функцией повторителя (repeater).

Справка (Википедия): Wireless Distribution System (WDS) — технология, позволяющая расширить зону покрытия беспроводной сети путем объединения нескольких WiFi точек доступа в единую сеть без необходимости наличия проводного соединения между ними (что является обязательным при традиционной схеме построения сети). Отличительной чертой технологии по сравнению с другими решениями является сохранение MAC адресов клиентов сети.

 Рис. 1 Общая схема сети WDS

Оборудование

Отмечу, что реализация функции WDS у разных производителей может отличаться, поэтому лучше всего использовать в качестве опорных пунктов распределенной беспроводной сети устройства одного производителя.

Для примера возьмем широко распространенные маршрутизатор Asus WL-520gU и точку доступа Asus WL-320gE.

Точка доступа Asus WL-320gE работает в режимах точки доступа, беспроводного клиента, беспроводного моста, ретранслятора и беспроводного маршрутизатора. Нас будет интересовать возможность использовать точку доступа как ретранслятор.

Страница описания на сайте Asus: http://ru.asus.com/Product.aspx?P_ID=VmvALkGKZLlRjzeR
 

Маршрутизатор Asus WL-520gU поддерживает WDS. Эта информация доступна на сайте ru.asus.com.

Страница описания на сайте Asus:http://ru.asus.com/product.aspx?P_ID=cOWUB0XOSysr4sBM

Настройка маршрутизатора Asus Wl-520gU

Маршрутизатор Asus WL-520gU в нашем примере будет подключен к проводному провайдеру интернет и будет являться шлюзом для всех остальных компьютеров в сети.

Настройка маршрутизатора осуществляется через веб-интерфейс и не представляет никакой сложности.

Адрес маршрутизатора Asus WL-520gU в локальной сети пусть будет 192.168.1.1. Также он будет являться сервером DHCP в локальной сети (хотя в сети могут быть и другие DHCP-серверы). Нас это не должно сильно волновать. Главное – чтобы маршрутизатор и точка доступа не были бы серверами DHCP одновременно.

Настройку соединения с провайдером я опущу, т.к. у всех это будет по-разному.

Приведу настройки WiFi-сети и опций для возможности использования WDS.

  • Меню Wireless -> Interface:

    SSID: yourNetworkName
    Channel: 10
    Wireless Mode: Auto, установлена галочка 54g Protection
    Auth. mode: WPA-Personal
    WPA-Encryption: TKIP
    Network Key Rotation Interval: 0
  • Меню Wireless -> Bridge:

    AP Mode: Hybrid
    Channel: 10
    Connect to APs in Remote Bridge List: Yes (у меня при этом сам список Remote Bridge List не содержал ни одного mac-адреса)
  • Меню Wireless -> Advanced:

    Enable AfterBurner: Disabled
    Hide SSID: No (думаю, можно поиграться и сделать Yes, но реально на безопасность сети скрытие SSID не повлияет - лучше пароль придумайте похитрее.)
  • Меню System Setup -> Operation Mode:

    Выбрать режим Home Gateway

Настройка точки доступа Asus Wl-320gE как повторителя

Точка доступа в нашей сети будет иметь адрес 192.168.1.2. Как уже было сказано выше, DHCP-сервер на этой точке доступа должен быть выключен.

  • Меню IP Config -> LAN:

    IP: 192.168.1.2
    Mask: 255.255.255.0
    Gateway: 192.168.1.1
  • Меню Wireless -> Interface:

    SSID: yourNetworkName
    Wireless Mode: Auto (галочка на 54g Protection почему-то не установлена)
    Auth. mode: WPA-PSK/WPA2-PSK
    WPA/WPA2-Encryption: TKIP
    …
    Network Key Rotation Interval: 0
  • Меню Wireless -> Advanced:

    Hide SSID: No
    Set AP Isolated: No
    …
    Mode: URE
    Настройки URE:
    SSID: yourNetworkName
    Auth. mode: WPA/WPA2-PSK
    WPA/WPA2-Encryption: TKIP
    Network Key Rotation Interval: 0

Нюансы

Открытый SSID

Думаю, что многие обратят внимание на то, что в приведенных настройках SSID сети не скрыт. Это можно считать недостатком. Но этому есть объяснение. Сеть настраивалась у заказчика, который не ставит максимальную безопасность во главе угла, но вот простоту добавления новых устройств требовал. С этим могут столкнуться многие. Если вы не админ конкретной сети, то по десять раз объяснять, как добавить КПК или новый ноутбук к сети надоест очень быстро. По этой причине я не могу сказать, насколько удобна в работе распределенная сеть со скрытым SSID.

WPA vs. WPA2

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

Фильрация по MAC-адресам

Я не настраивал фильтрацию по MAC-адресам точек доступа, по соображениям, похожим на изложенные в п.1 - мне не нужны лишние проблемы с конфигурированием. Кроме того, сеть была домашней и не требовала особых мер безопасности. P.S. Что касается WiFi в офисе - я вообще против этого. Правда, бывает, что иначе и не сделать.

Итог

Вот и все. Учитывая, что настройку распределенной беспроводной сети последний раз я делал год назад, прошу не ругать меня за отсутствие каких-либо деталей или присутствие опечаток. Как всегда, комментарии приветствуются. Еще раз отмечу, при использовании прошивок от Asus для использования шифрования WPA/WPA2 нельзя настраивать WDS. Надо настраивать повторитель сигнала основного маршрутизатора.

Дополнения

  • добавлено 19.10.11: После экспериментов с прошивкой может пригодиться статья "Восстановление прошивки Asus WL-500gP".
  • добавлено 20.10.11: До кучи: если вы решите использовать роутер, прошитый в DD-WRT (другие не пробовал, если знаете, скажите) в качестве повторителя, то вы столкнетесь с кучей неясностей и в конце если и сделаете это, то скорее всего это будет режим Repeater Bridge и вторая беспроводная сеть, на которую придется переключаться беспроводным клиентам если они будут перемещаться из одной зоны сети в другую.

    Вывод: самое простое и правильное, на мой взгляд, это использовать специальное устройство, типа описанного в этой статье выше Asus WL-320gE. Это работает. В отличие от танцев, с которыми я лично не раз и не два сталкивался.

    PS: Если кто-нибудь из посетителей сайта придерживается иного мнения или знает, как сделать нормальный повторитель WiFi из роутера, прошитого в DD-WRT или другую альтернативную прошивку - очень прошу высказываться, многим пригодится. Эту статью ежедневно просматривают куча народа - это говорит о том, что эта тема нужна и интересует многих! Давайте поможем другим советом!
  • добавлено 28.02.2012: Где-то два месяца назад я пробовал расширить зону действия сети на основе роутера Asus WL-500gP (на родной прошивке Asus) с помощью Asus RT-N12. Несмотря на заявленную возможность работать репитером, постоянно прекращался доступ в интернет в тех местах, где можно было "зацепить" и Asus WL-500gP и Asus RT-N12. Я сдал репитер Asus RT-N12 обратно в магазин. Т.к. ничего адекватного на тот момент я не нашел, на время отложил поиски. Буквально сегодня утром купил аж два роутера Asus RT-N10U (с функцией повторителя), думал выкинуть старый Asus WL-500gP, т.к. я почему-то подумал, что возможно проблема была из-за него, все-таки для него прошивка уже достаточно старая. Как же я обрадовался, когда ради эксперимента "подцепил" один из Asus RT-N10U как повторитель к существующей сети и все заработало! Учитывая довольно большое количество оргтехники, уже настроенной на работу с Asus WL-500gP, я так пока и оставил один из новых роутеров нераспечатанным. В итоге, прекрасно себя показала связка из старого роутера Asus WL-500gP и нового в режиме репитера Asus RT-N10U.

Установка Firefox в домене Windows

Обновлено: 13.09.2025
Теги: Групповые политики

Автор

Иванов Илья, http://bozza.ru, 2009

Вступление

Предыдущее название статьи: "Установка Firefox в сети Windows 2003 средствами групповой политики".

Считается, что пользователи в сети должны иметь ограниченные права и привилегии. В том числе на установку программ. Это правильно. А в вашей сети используется Firefox как основной браузер и вы уже задолбались бегать от компа к компу, вводить админские кредиты и устанавливать новые версии Firefox, выходящие с завидной регулярностью. Значительно упростить этот процесс можно с помощью домена Windows 2003, оснастки "Active Directory - Пользователи и компьютеры" и редактора групповой политики gpmc.msc.

Итак, задача: максимально упростить обновления браузера Firefox, установленного на подавляющем количестве компьютеров в сети. Исходные данные: домен Windows 2003.

Подготавливаем MSI-файл для Firefox

Думаю, что добавлю потом отдельную статью о том, откуда можно брать файлы Windows Installer вида "firefox.msi". Скажу лишь, что в нашем случае сам msi-файл и шаблон firefox.adm можно скачать отсюда.

Расшариваем какую-либо папку на сервере и даем к ней доступ юзерам на чтение, админу - полный:

расшариваем шаблон firefox.adm и firefox.msi

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

Если у вас пользователи домена уже находятся в Users или где-то еще и вы не намерены их оттуда перемещать, пропускайте следующий параграф.

Подготовка организационного подразделения (OU)

Вообще-то держать пользователей домена в Users (по-умолчанию) не рекомедуется, в т.ч. на курсах Microsoft. Поэтому мы создадим новое рганизационное подразделение (OU), к которому будем в последствии применять политику распространения Firefox.

Шаг 1: сделаем OU "OurUsers" и поместим в него пользователя "user1"

Создаем новое OU

Помещаем пользователей в новое OU

Шаг 2: Создадим отдельную политику для созданного подразделения "OurUsers"

Запускаем редактор групповой политики GPMC.MSC:

Редактор групповой политики GPMC

... и создаем связанную только с нашим OU "OurUsers" групповую политику под названием "Install Custom Software":

Создаем новый объект групповой политики

... редактируем нашу политику "Install Custom Software":

Редактируем объект групповой политики

Шаг 3: Готовим дистрибутив Firefox для развертывания в сети

В разделе "User Configuration" -> "Software settings" -> "Software Installation" щелкаем правой мышкой и создаем новый объект для установки - наш будущий инсталлятор Firefox:

Создаем новый дистрибутив

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

выбираем файл MSI

Выбираем "Assigned" (Назначенный):

Публикуем:

Публикуем установку

На этом работа с веткой "Software Installation" закончена. переходим к ветке "User Configuration" -> "Administrative Templates" и создаем новый шаблон на основе файлика firefox.adm, так же кем-то предусмотрительно скачанного ранее:

Создаем новый шаблон для Firefox

Выбираем готовый шаблон для Firefox

Ок, мы сделали новый шаблон "Firefox". Теперь отредактируем его, как нам того требуется. Настроек не так много, но минимум все-таки настроить можно - стартовая страница, адрес прокси и пр.

Редактируем параметры шаблона для Firefox

Все. С шаблонами и прочими зверями покончено. Закрываем все открытые окна на сервере (если не помешает другим задачам, естественно), Пуск -> Выполнить -> gpupdate /force

Шаг 4: Устанавливаем на клиенте свежий Firefox

Созерцаем пару секунд окно командного интерпритатора и пробуем залогиниться под учетной записью "user1" на рабочую станцию. Выполняем команду "gpupdate /force", выходим и снова залогиниваемся на рабочей станции. Запускаем на рабочей станции "Установка и удаление программ", и в окне "Установка программ" созерцаем:

Устанавливаем Firefox на клиенте

Вот! Теперь даже пользователь с ограниченными правами сможет установить уже настроенный броузер Firefox, а если Firefox уже был установлен, то он быдет обновлен до новой версии, в которой исправлены всякие недочеты и уязвимости.

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

Минусы

Нельзя не сказать о существенных минусах этого способа. Первый, и, наверное, самый существенный - описанный способ это НЕ АВТОМАТИЧЕСКАЯ УСТАНОВКА ПРОГРАММ НА ВСЕ КОМПЬЮТЕРЫ В ДОМЕНЕ. Для автоматической установки используется другой метод, думаю, позже я опишу его, а пока сам до конца не понял, как просто и четко работать с MST-файлами настроек в случае подготовки дистрибутива для автоматического развертывания в сети. Отмечу, что статей про автоматическое развертывание пакета Microsoft Office в сети домена довольно много, но попробуйте найдите хоть что-то вразумительное о том, как сделать шаблон настроек firefox.mst - и вы меня поймете.

Кстати, если вы знаете ПРОСТЫЕ И ПОНЯТНЫЕ объяснения, как подготавливать MST-файлы, ОБЯЗАТЕЛЬНО ПИШИТЕ ОБ ЭТОМ в комментариях к этой статье.

Второй минус - опять же непрозрачность подготовки шаблона firefox.adm. Признаюсь, я не успел в этом покопаться, поэтому опять же - КОММЕНТАРИИ И СОВЕТЫ ПРИВЕТСТВУЮТСЯ.

Материалы

В подготовке материала я использовал:

  1. http://frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm
  2. http://www.mednikov.ru/?p=85

и вечер собственного времени.


OpenVPN: Individual Firewall Rules for Connecting Clients

Обновлено: 13.09.2025
Теги: OpenVPN

(содержимое одной из глав книги OpenVPN: Building and Integrating Virtual Private Networks)

One striking possibility OpenVPN offers is a setup where:

  • An OpenVPN machine acts as a server that protects the company's network, admitting access for OpenVPN clients.
  • The clients are automatically assigned IPs by the server.
  • The clients are equipped with certificates, and identified and authorized by these certificates.

The scripting parameter learn-address in the server's OpenVPN configuration file will have the server execute a script whenever an authorized client connects to the VPN and is assigned an address. This parameter takes the full path to a script as an option:

learn-address /etc/openvpn/scripts/openvpnFW

In this example, the script openvpnFW will be executed each time a client is assigned an IP address and will be passed three variables by the OpenVPN server process:

  1. $1: The action taken; this may be one of add, delete, update
  2. $2: The IP assigned to the client connecting
  3. $3: The common name in the subject line of the client's certificate

Add the line learn-address /etc/openvpn/scripts/openvpnFW to your OpenVPN server configuration file and edit the file /etc/openvpn/scripts/openvpnFW to be like the following. These lines will show how to make use of these parameters in a short Linux shell script:

#!/bin/sh
LOGFILE=
DATE=`/bin/date`
echo $DATE $1 $2 $3 >> $LOGFILE

This script will only export the variables passed to the logfile, including a timestamp that is added by the command date. Stop and start your tunnel a few times. Now let's have a look at the file /var/log/openvpn/connections.log:

Mi Feb 1 04:33:53 CET 2006 update 10.99.0.3 mfeilner
Do Feb 2 04:34:33 CET 2006 update 10.99.0.3 mfeilner
Fr Feb 3 04:34:14 CET 2006 update 10.99.0.3 mfeilner
Sa Feb 4 04:34:53 CET 2006 update 10.99.0.3 mfeilner
So Feb 5 04:34:43 CET 2006 update 10.99.0.3 mfeilner

This example shows my VPN client reconnecting every day. This alone might yet be an interesting feature, if you want to keep track of your users and their VPN connections. However, we can do more. Let's add some more lines to our openvpnFW script:

if [ $1 = add ]
then
/etc/openvpn/scripts/$2.FW_connect.sh
fi
if [ $1 = delete ]
then
/etc/openvpn/scripts/$2.FW_disconnect.sh
fi

Two simple tests are run and, depending on the content of the variable $1, different firewall scripts are executed. Let's express this in brief. If the first variable passed is add, then the script /etc/openvpn/scripts/$2.FW_connect.sh is run, where $2 will be replaced by the IP of the client connecting. If for example a client mfeilner connects and is assigned the IP 10.99.0.3, then the variables passed to this script openvpnFW will be:

add 10.99.0.3 mfeilner

And the script run will be called: /etc/openvpn/scripts/10.99.0.3.FW_connect.sh.
However, if the variables passed to openvpnFW are the following:

delete 10.99.0.3

then the script /etc/openvpn/scripts/10.99.0.3.FW_disconnect.sh will be executed.

I think you have already guessed that these two scripts contain firewall rules (like iptables statements) for the client with the certificate mfeilner. Even though all of this could be done within one single script, I prefer to have the tests and firewall rules split up in several scripts.

This setup can become very powerful and fairly complex. A client that has its default route set through the tunnel can be allowed selective Internet access, simply by enabling or disabling, routing or forwarding. And access to the local servers can also be easily managed: E.g. A SAP server might only be available for road warriors from 7 am to 6 pm, whereas during the night firewall rules protect the server.


Права доступа в Linux

Обновлено: 13.09.2025
Теги: Linux

Автор grinder, источник: http://www.linuxstudio.ru

Linux

Настало время поговорить о швабре на которую наступают новички. Речь сегодня пойдет о правах доступа. И так вы садитесь за компьютер, работа не идет и в порыве вы уничтожаете случайно важные системные файлы. Или ваши знакомые или сослуживцы залезли в папку которую не должны были видеть. Или ... Ситуация я думаю знакомая. Но зато согласитесь удобно. Я сам себе режиссер, что хочу то делаю, любая программа, пользователь имеет доступ ко всем системным файлам и ресурсам, никаких ограничений. Красота. Отсюда эпидемии вирусов. Так вот в Linux всего такого нет. Почему?

Файлы в Linux имеют двух владельцев: пользователя (user owner) и группу (group owner) под которой понимается определенный список пользователей и причем владелец файла не обязательно должен быть членом группы владеющей файлом. Каждый пользователь может быть членом сразу нескольких групп одна из которых называется первичной (primary), а все остальные - дополнительными (supplementary). Это дает большую гибкость в организации доступа к определенному файлу. Совместное использование некоторым ресурсом организовать очень просто, достаточно создать новую группу и включить в нее всех кому это действительно необходимо, а если человек предположим перешел в другой отдел и уже нет необходимости в использовании данного файла. А все очень просто, необходимо просто выключить его из состава данной группы. Ну а, что делать с остальными неужели они так и не смогут хотя бы прочитать содержимое файла или их прийдется каждый раз включать и исключать из группы. А вот для всех остальных (other) которые не принадлежат ни к user owner и group owner права доступа устанавливаются отдельно и как правило самые минимальные. Обычно владельцем файла является пользователь который создал данный файл. Владелец-группа вновь создаваемого файла устанавливается равной первичной группе пользователя создавшего файл, но в некоторых версиях Unix владелец-группа наследуется от владельца-группы каталога в котором создается файл. Для изменения владельца файла используется команда chown в качестве параметров принимающая имя нового владельца и список файлов: # chown new_owner file1 file2 ...Конечно же на месте названия файла может быть и имя каталога, но при этом владелец файлов внутри каталога не изменится, для того чтобы это произошло лучше всего воспользоваться флагом -R (chown -R). При использовании данной команды (впрочем как и большинства) можно пользоваться регулярными выражениями если есть необходимость отобрать файлы удовлетворяющие определенному критерию (chown - R lys *.с). Для изменения владельца группы используется команда chgrp, синтаксис использования данной команды аналогичен предыдущей: # chgrp sales /home/sales/*. Кстати команда chown позволяет сразу установить и группу-владельца для этого необходимо сразу за именем владельца без пробелов и др. знаков поставить двоеточие и написать название необходимой группы

# chown - R sergej:gljuk *

допускается и такой вариант записи:

# chown - R :gljuk * (т.е. аналог команды chgrp).

Владение файлом определяет те операции которые тот или иной пользователь может совершить над файлом. Самые очевидные из них это изменение владельца и группы для некоторого файла. Эти операции может проделать суперпользователь и владелец файла (в производных BSD UNIX только суперпользователь). Если с первым все понятно, то например написав программу и сделать затем ее владельцем, например суперпользователя увы не получится, и хотя вариант изменения владельцем допускается варианта такого применения я честно говоря не нашел. А вот группу, если вы являетесь владельцем файла, можно изменить только на свою первичную (по умолчанию имеет то же название, как и имя соответствующего пользователя). Эти все ограничения введены по нескольким причинам, чтобы никто не мог подсунуть какой ни будь зловредный файл и для того чтобы если на компьютере установлен лимит дискового пространства для конкретного пользователя, нельзя было просто переопределив владельца превысить его.

Следующие базовые операции которые можно совершить над файлом: это доступ на чтение (Read), доступ на запись (Write) и доступ на выполнение (eXecute). Эти операции устанавливаются для каждой из трех групп пользователей раздельно. Причем проделать это может только пользователь владелец и конечно же суперпользователь. Для установки соответствующих прав используется команда chmod. Применяется она в двух формах абсолютной - когда игнорируются старые права, а безусловно устанавливаются новые, и относительной - когда к имеющимся правам добавляются/убираются другие. Абсолютная форма предполагает задание прав доступа к файлу прямым заданием его в восьмеричной форме. Для того чтобы получить полный код необходимого режима файла, необходимо просто сложить значения кодов приведенных в таблице.

 

 Восьмеричный код  Режим файла
 0001  Право на выполнение для всех
 0002  Право на запись для всех
 0004  Право на чтение для всех
 0010  Право на выполнение для группы
 0020  Право на запись для группы
 0040  Право на чтение для группы
 0100  Право на выполнение для владельца
 0200  Право на запись для владельца
 0400 Право на чтение для владельца
 1000  Включения бита сохранения задачи
 2000  Если файл выполняемый включения бита SGID
 4000  Если файл выполняемый включения бита SUID

 

Таким образом команда # chmod 755 file устанавливает следующие права доступа, это исполняемый файл, запустить его на выполнение и прочитать содержимое имеют право все (т.е. владелец, группа и остальные), а владелец дополнительно имеет право на изменение содержимого - запись. Это кстати пример задания прав классического cgi сценария.

Относительная форма команды требует конкретного указания классов доступа ('u'- владелец, ‘g'- группа, ‘o'- остальные , ‘a' -все вместе), соответствующие права доступа ('r' - чтение, ‘w' - запись, ‘x' - выполнение) и операцию которую необходимо произвести для списка файлов ('+' добавить , ‘-' удалить, ‘=' присвоить) для соответствующего списка файлов. Например команда # chmod u+w, ug+r, a+x file добавляет дополнительно к имеющимся всем право запустить файл на выполнение, группа и владелец смогут прочесть содержимое, а владелец кроме того и изменить содержание. Да и команда ‘=' относится скорее к абсолютному заданию прав доступа так как устанавливает соответствующие права вместо имеющихся.

Просмотреть соответствующие права доступа, а также владельца и группу можно с помощью команды ls -l:

[sergej@grinder sergej]$ ls -l

итого 2

drwxrwxr-x 2 sergej sergej 1024 Авг 17 09:45 bin
-rw-rw-r- 1 sergej sergej 604 Авг 22 21:07 printenv.pl

Буква ‘d' означает, что это каталог, прочерк ‘-' - обыкновенный файл, ‘l' - символическая связь, ‘b'- блочное устройство, ‘c' - символьное устройство. Исполняемый файл может быть как откомпилированной программой (для его запуска необходимо только право на выполнение) и скриптом. Чтобы запустить на выполнение последний необходимо дополнительно право на чтение, так как программа-интерпретатор должна перед этим его прочитать. Значение прав доступа для различных типов файлов также различно. Вы ведь не забыли, что все остальное: каталоги, устройства, сокеты и именованные каналы тоже являются файлами. Например для последних трех право на выполнение смысла не имеет. Для символических связей они контролируются целевым файлом. Для каталогов они имеют немного другой смысл. Каталог по своей сути файл содержащий имена всех файлов которые содержатся в данном каталоге, а также указатели на дополнительную информацию, позволяющие операционной системе производить необходимые операции. Так вот право на чтение каталога позволяет всего лишь получить только имена файлов, находящихся в данном каталоге. А вот для того, чтобы получить дополнительную информацию, необходимы право на исполнение так, как уже прийдется заглянуть в "метаданные" каждого файла. Также чтобы перейти в какой ни будь каталог (cd) (и все каталоги на пути) необходимо иметь право на выполнение. Поэтому например часто создав каталог для домашней страницы Web-сервера Apache (public_html) и при попытке открыть его http://localhost/~user_name, получаете сообщение о том, что узел не достижим одной из причин является, то что сервер просто не может прочитать содержимое соответствующего каталога и всех каталогов на пути к нему. Кстати из-за наличия этих особенностей можно добиться так называемого эффекта "dark directory". Когда есть возможность создать каталог файлы в котором доступны только если пользователь знает точно имя соответствующего файла. Давайте посмотрим, как создать такой каталог.

[sergej@grinder sergej]$ mkdir darkcat # создаем каталог

[sergej@grinder sergej]$ chmod a-r+x darkcat # устанавливает необходимые права доступа, добавляем исполнение для всех и убираем возможность чтения списка файлов

[sergej@grinder sergej]$ ls -l # маленькая проверка

d-wx-wx-x 2 sergej sergej 1024 Сен 7 15:14 darkcat

[sergej@grinder sergej]$ cp myfile darkcat # копируем файл в каталог

[sergej@grinder sergej]$ cd darkcat # переходим в каталог

[sergej@grinder darkcat]$ ls -l # пробуем прочитать список файлов

ls: .: Permission denied # вот те раз

[sergej@grinder darkcat]$ cat myfile # выводим содержимое файла на терминал

Получилось.

Право на запись для каталога позволяет изменять его содержимое т.е. удалять и записывать файлы, при этом права доступа к конкретному файлу игнорируются.

Еще один момент права на доступ проверяются в такой последовательности: суперпользователь, владелец, группа-владелец и остальные. Отсюда если вы являясь владельце забыли установить для себя право например на запись, но установили его всем остальным и не надейтесь, что сможете записать в него что-нибудь, даже если вы являетесь членом группы, просто потому, что все остальные могут, а вы являетесь владельцем. Система при запросе нужного ресурса проверит кем он запрашивается в приведенной выше последовательности и допустит только к разрешенным операциям, дальнейшая проверка прав просто проводится не будет.

Справедливости стоит отметить, что права доступа имеет не пользователь, а процесс запущенный ним. Не вдаваясь в подробности (я думаю о процессах разговор отдельный), каждый пользователь зарегистрировавшись в системе получает свою копию текущего процесса shell который имеет установленные идентификаторы RID и RGID реальные индетификаторы пользователя и первичной группы пользователя. А все процессы запущенные пользователем (дочерними), которые наследуют все переменные в том числе и RID, RGID. К чему это я собственно. У нас остались не рассмотренными три режима файла: бит сохранения задачи (stisky bit или save text mode), а также флаги SUID и SGID. Со stisky bit все просто, этот бит указывает на необходимость сохранения копии выполняющейся программы в памяти после завершения выполнения. Этот режим позволяет сэкономить время на запуске программы при частом использовании, но в современных системах применение этого режима встречается редко. А вот флаги SUID и SGID позволяют изменить (расширить) права пользователя (группы) запустившего программу на выполнение, на время выполнения программы. Как уже говорилось запущенное приложение имеют права доступа к системным ресурсам такие же, что и пользователь, запустивший программу. А установки этих флагов позволяет назначить права доступа исходя из прав доступа владельца файла. Отсюда если владельцем запущенного приложения является root, то любой независимо кто запустил данное приложение будет иметь права суперпользователя. При этом при установке флага SUID наследуется права владельца файла, а SGID - группы-владельца.

В качестве примера где может применяться это свойство рассмотрим утилиту passwd, которая позволяет изменить пользователю свой пароль. Все учетные записи и пароли (в зашифрованном виде) хранятся в файлах /etc/passwd и /etc/shadow, если предоставить право каждому пользователю на самолично вносить изменения в эти файлы напрямую, то можете представить, что это будет. И естественно вам и не кто и не даст такое право.

[sergej@grinder sergej]$ ls -l /etc/passwd /etc/shadow

-rw-r-r- 1 root root 1628 Авг 13 18:31 /etc/passwd

-r--- 1 root root 1081 Авг 13 18:31 /etc/shadow

Как видите все пользователи имеют право только на чтение файла /etc/passwd, а записывать информацию может только root (а /etc/shadow как вы видите закрыли от всех, чтобы пароли не могли подобрать). Теперь смотрим на утилиту passwd:

[sergej@grinder sergej]$ ls -l /usr/bin/passwd

-r-s-x-x 1 root root 15104 Мар 14 03:44 /usr/bin/passwd

Буква 's' означает, что установлен флаг SUID, а владельцем файла является его величество root и теперь кто бы ни запустил утилиту на выполнение, на время работы программы он временно получает права суперпользователя, т.е. произвести запись в защищенный системный файл. Естественно утилита должна (и делает это) производить изменение учетной записи только запустившего ее пользователя. Как вы понимаете требования по безопасности к программам использующим данный метод должны быть повышены. Это наверное самая большая дыра во всех Unix, потому что найдя ошибку в одной из программ использующих биты SUID/SGID можно производить любые действия не обладая при этом правами суперпользователя. А аксиома программирования говорит, что ошибки будут всегда. Поэтому сейчас где можно пытаются уйти или сильно изменить этот механизм. Да почитайте хотя бы аннотацию к большинству дистрибутивов Linux, там производитель с гордостью сообщает, что такие то программы уже не используют механизм SUID/SGID. Для установки битов SUID/SGID в символьной форме используется буква - 's', sticky bit устанавливается буквой -'t', а с помощью буквы ‘l' можно установить блокировку файла, для устранения возможных конфликтов когда несколько процессов попытаются работать с одним и тем же файлом. И еще один интересный момент.

[sergej@grinder sergej]$ ls -l /

drwxrwxrwt 25 root root 4096 Сен 8 20:08 tmp

Посмотрите, в каталоге /tmp установлен sticky bit. Зачем? Как говорилось предоставление права на запись в каталог позволяет удалять все файлы даже те владельцами которых он не является. Чтобы избежать этого устанавливается sticky bit для каталога и теперь удалить файл может только пользователь создавший его. А при установке бита SGID для каталога, все вновь созданные файлы будут теперь наследовать группу не по пользователю создавшему его, а по группе-владельцу каталога.

А теперь для чего все это собственно я вам рассказываю т.е. о наших швабрах. Представьте такую ситуацию смотрировали CDROM под root и скопировали с него файлы в домашний каталог обычного пользователь, поработали и выключили компьютер. Угадайте на следующий день вы сможете открыть там хоть один файл. Да работать мне целую неделю в Windows если да, а все потому, что владельцем файла окажется все тот же суперпользователь. Это относится и к различным конфигурационным файлам скопированным в домашний каталог (или созданным под root), процесс запущенный обычным пользователем просто не сможет его прочитать и пользоваться вы будете общесистемным, недоумевая почему не вступают в силу настройки произведенные вами. А вот еще ситуация настроили принтер утилитой princonf, под обычным пользователем не печатает. Почему? А потому, что вам не дано право на выполнение. Самый радикальный метод который я встречал в некоторых книгах выглядит так.

[root@grinder sergej]# chmod a+rwx /dev/*

Все получают право на выполнение, чтение и запись и проблема решена, причем проделав сразу для всех файлов данного каталога вы решите ее раз и на всегда. Для домашнего пользователя в принципе такое решение сойдет. Но оно как раз в духе Windows. Более культурный вариант выглядит так.

[sergej@grinder sergej]$ ls -l /dev/lp0

crw-rw-- 1 root lp 6, 0 Апр 11 17:25 /dev/lp0

Видите право на выполнение дано root и членам группы lp, отсюда если нужен принтер добавьте себя в эту группу. Либо прямым редактированием файла /etc/group (sergej:x:500:sergej,gdm,mysql,named,nobody,sound,lp), либо с помощью различных графических утилит вроде System Setting.
Зачем все это?

Например не играет звук. Смотрим.

[sergej@grinder sergej]$ ls -l /dev/dsp

crw--- 1 sergej root 14, 3 Апр 11 17:25 /dev/dsp

Получается что только пользователь sergej будет слушать музыку. Парадокс однако. Пришлось создавать группу sound и добавить в нее себя, сделать владельцем обиженного root'a, а для группы sound определить чтение. Справедливости хотелось отметить, что права доступа это заслуга не только операционной , но и файловой системы ext2. В inode файла внесена вся необходимая информация о соответствующих правах доступа.

Или например на форумах часто спрашивают как сделать чтобы ppp соединение было доступно обычному пользователю. А все просто. Не нужно ничего выдумывать. Ищем пользователя и группу которая имет доступ к этому сервису и добавляем себя любимого. В Ubuntu это группа dip.

Вот и в принципе и все. Бывшего пользователя Windows несколько раздражает такой подход когда собственноручно созданный файл нельзя даже прочитать, но зато такой подход дисциплинирует, лучше всяких запретов. По этой же причине в Linux мало приживаются вирусы, для того чтобы нанести серьезный ущерб системе нужны соответствующие права. Linux forever.

Защита сайта с помощью .htaccess и .htpasswd

Обновлено: 13.09.2025

apache защита

Автор - Голышев С.В. http://www.softtime.ru

Защита сайта средствами самого сервера Apache является одним из самых простых и в тоже время достаточно надежных способов. В этом случае Вам не нужно досконально продумывать стратегию безопасности, осуществлять ее проектирование и реализацию в коде. К тому же, для того, чтобы создать хорошую систему защиты нужно обладать достаточной квалификацией в этом вопросе. Используя встроенную защиту WEB-сервера Apache, Вы значительно упрощаете себе задачу — все, что Вы должны сделать — это выполнить несложную последовательность действий и Ваш сайт будет в достаточной мере защищен. В данной статье будут подробно описаны шаги и действия, которые Вам необходимо совершить. А в конце статьи будут приведены примеры файлов .htaccess.

Базовая аутентификация

В данной статье будет рассмотрен самый простой и доступный способ защиты — базовая аутентификация.

Замечание

Аутентификация — процесс, с помощью которого проверяется, что некто является именно тем, за кого он себя выдает. Как правило, проверка включает в себя ввод имени и пароля.

Рассмотрим, как работает базовая аутентификация.
При обращении посетителя в защищаемую директорию, сервер Apache в ответ на запрос посылает заголовок с кодом 401 (401 authentication required header). Браузер посетителя принимает заголовок с кодом 401 и выводит окно с полями для ввода имени пользователя и пароля. После ввода имени и пароля эти данные отсылаются назад серверу, который проверяет имя пользователя на предмет нахождения в специальном списке, а пароль на правильность. Если все верно, то посетитель получает доступ к ресурсу. Вместе с заголовком браузеру посылается специальной имя, называемое областью действия. Браузер кэширует не только имя и пароль, чтобы передавать их при каждом запросе, но и область действия. Благодаря этому, ввод имени и пароля в защищаемой директории осуществляется только раз. В противном случае их необходимо было бы вводить при каждом запросе к защищаемой директории. Кэширование параметров аутентификации (имя, пароль, область действия), обычно осуществляет только в пределах одного сеанса.

Замечание

При базовой аутентификации имя пользователя и его пароль передаются в сеть в открытом виде в течении всего сеанса, когда посетитель работает с защищенной директорией. Хакер может перехватить эту информацию, используя сетевой анализатор пакетов. Данный вид аутентификации не должен использоваться там, где нужна реальная защита коммерческо-ценной информации.

Замечание

WEB-сервер Apache поддерживает еще один вид защиты — digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленному по алгоритму MD5. Поэтому пароль не может быть перехвачен при сканировании трафика. Но, к сожалению, для использования digest-аутентификации необходимо установить на сервер специальный модуль - mod_auth_digest. А это находится только в компетенции администрации сервера. Также, до недавнего времени, digest-аутентификация поддерживалась не всеми видами браузеров.

Защита сайта — это просто

Для того чтобы защитить сайт, нужно выполнить следующую последовательность действий: создать файл с паролями, переписать его на сервер, создать файл .htaccess и тоже переписать его на сервер.
Для организации защиты понадобится.

  1. WEB-сайт и FTP-доступ к нему.
  2. Права на создание файлов .htpaccess и организацию защиты с помощью них.
  3. Утилита генерации паролей htpasswd.exe

Проверка работы файла .htaccess на сервере

Для того чтобы проверить есть ли у Вас права на организацию защиты с помощью файлов .htaccess создайте текстовый файл с именем .htaccess (первым символом идет точка, расширение отсутствует).

Замечание

Удобно создавать файлы .htaccess с помощью встроенного редактора в оболочках Far, WindowsCommander, TotalCommander и т.п., а также в редакторе Блокнот.

Замечание

Чтобы блокнот не подставлял автоматически расширение txt, в диалоге сохранения в выпадающем списке "тип файла" следует выбрать опцию "Все файлы".

 


Рис. Сохранение файлов .htaccess в блокноте

Перед тем как сохранить файл, впишите в него следующие строки:

Проверка работы .htaccess

AuthType Basic  
AuthName admin
require valid-user 

Затем, через FTP-доступ, перепишите файл .htaccess на сайт, в ту директорию, которую вы хотите защитить.

Замечание

Действие файлов .htaccess распространяется не только на ту директорию, где лежит файл, но и на все поддиректрии, лежащие уровнем ниже.

Далее через браузер обратитесь к этой директории. Если Вы защищаете директорию admin и переписали туда файл .htaccess, то для проверки Вам следует вписать в адресную строку браузера следующий URL: http://www.mysite.ru/admin/.

Если после этого Вам открылся запрос на ввод логина и пароля, как на рисунке ниже, то тестирование прошло успешно и можно продолжать защиту директории.

Рис. Окно ввода логина и пароля


Если вы все сделали правильно, но окошко ввода пароля не появилось, то это значит, что настройки сервера запрещают Вам использовать файлы .htaccess для защиты директорий. Для решения данного вопроса Вам следует связаться с администрацией сервера, либо использовать другой тип защиты.
После того, как было выяснено, что файлы .htaccess работают, следует удалить с сайта только что написанный тестовый файл.

Замечание

Если по каким либо причинам Вы не можете удалить файл .htaccess, то создайте пустой файл .htaccess и замените им файл, лежащий на сервере.

Создание файла с паролями .htpasswd

Файл с паролями создается утилитой htpasswd.exe. Если у Вас на машине установлен WEB-сервер Apache, то данная утилита находится в директории с установленным Apache-ем в подкаталоге bin.

Замечание

Если у Вас не установлен Apache, то утилиту htpasswd.exe можете скачать по ссылке: http://www.softtime.ru/files/htpasswd.zip.

Для работы с утилитой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают такие программы как Far, WindowsCommander и т.п. Здесь будет рассмотрена работа с командной строкой с помощью утилиты cmd, которая входит в поставку Windows 2000/XP и т.п.
Нажмите "Пуск"->"Выполнить", введите в строку ввода cmd и нажмите ОК. Вам откроется окно утилиты CMD.

Рис. Окно утилиты CMD


Далее необходимо перейти в директорию, где находится утилита htpasswd.exe. Допустим, сервер Apache установлен в директории с:/Apache2, тогда введите в командную строку команду: cd../../apache2/bin и нажмите ввод.

 


Вы перешли в директорию с:Apache2in. Теперь нужно дать команду на создание файла с паролем. Введите в командную строку следующее:

htpasswd -cm .htpasswd admin

  • -cm — это ключи для утилиты. Ключ с — указывает, что необходимо создать новый файл с паролями. Если файл с таким именем уже существует, то он будет перезаписан. Ключ m — определяет шифрование по алгоритму MD5.
    .htpasswd — имя файла с паролями (можете использовать любое имя).
    admin — имя посетителя, которому будет разрешен доступ в закрытую область сайта.

В ответ, должен появится запрос на ввод пароля и его повтор. Если все правильно, то в завершении появится сообщение: Adding password for user admin. И в директории c:Apache2in появится файл .htpasswd, к котором будет находиться строка с именем пользователя и хеш-кодом его пароля. Для того, что бы в тот же файл .htpasswd добавить еще одного пользователя следует убрать ключ -c из команды запуска утилиты htpasswd.exe

htpasswd -m .htpasswd admin

 


Замечание

Если файл с паролями не был создан, то возможно, некоторые ключи утилиты не поддерживаются в Вашей операционной системе. Например, иногда не поддерживается ключ m. В этом случае, Вам нужно ввести htpasswd -c .htpasswd admin
Для того, чтобы посмотреть ключи и параметры работы утилиты введите htpasswd.exe /? Вам будет выдано описание интерфейса.

Итак, файл с паролями создан. Теперь Вам необходимо переписать его на сервер. Файлы с паролями очень желательно класть выше корневой директории сайта — туда, куда не будет доступа посетителям.
Если это невозможно, то файлы с паролями следует обязательно защитить. Это можно сделать с помощью файлов .htaccess. Чтобы защитить файлы с паролями создайте файл со строками, представленными в следующем листинге.

Защита файлов .htpasswd

<Files .htpasswd>
   deny from all
</Files>

И положите его в ту директорию, где находится Ваш файл с паролями. Теперь посетители сайта не смогут получить к нему доступ.
Файл с паролем создан и защищен от несанкционированного доступа. Теперь необходимо создать файл .htaccess, который будет использоваться в защищаемой директории.

Создание файла .htaccess

Для защиты директории могут использоваться следующие директивы:

  • AuthType — Тип используемой аутентификации. Для базовой аутентификации эта директива должна иметь значение: Basic
    AuthName — Имя области действия аутентификации. Текст, помогающий посетителю понять, куда он пытается получить доступ. Например, может быть написано: "Private zone. Only for administrator!"
    AuthUserFile — путь к файлу с паролями (.htpasswd).
    AuthGroupFile — путь к файлу групп, если он существует.
    Require — Одно или несколько требований, которые должны быть выполнены для получения доступа к закрытой области.

Пример файла .htaccess

AuthType Basic  
AuthName "Private zone. Only for administrator!"
AuthGroupFile /usr/host/mysite/group
AuthUserFile  /usr/host/mysite/.htpasswd  
require group admins

Следует более подробно описать директивы AuthUserFile и AuthGroupFile. В них прописываются абсолютные пути к соответствующим файлам от корня сервера.

Внимание!

Относительные пути работать не будут!

Путь от корня сервера, можно узнать, спросив у администрации сервера, либо можно попробовать выяснить его самим. Для этого выполните функцию phpinfo(). На экран будет выведена фиолетовая таблица. Значение абсолютного пути от корня сервера можно посмотреть в переменных: doc_root, open_basedir, DOCUMENT_ROOT.
Директива Require определяет кому разрешен доступ к закрытой области. Например,

  • require valid-user — разрешен доступ всем прошедшим проверку
  • require user admin alex mango — разрешен доступ только посетителям с именами admin, alex, mango. Естественно, они должны пройти аутентификацию.
  • require group admins — разрешен доступ всем пользователям из группы admins

Файлы групп

Если к защищаемой области сайта должна иметь доступ большая группа людей, то удобно объединить людей в группы, и разрешать доступ, определяя принадлежность посетителя к группе.
Формат файла групп очень прост. Это текстовый файл, каждая строка, которой описывает отдельную группу. Первым в строке должно идти название группы с двоеточием. А затем через пробел перечисляются посетители, входящие в группу.

Пример файла групп

Admins: admin alex mango
Users: guest user max23

В группу Admins входят посетители с именами admin, alex, mango. А группу Users входят посетители с именами guest, user, max23.

Примеры файлов .htaccess

Доступ всем пользователям, прошедшим авторизацию

AuthType Basic  
AuthName "Private zone. Only for administrator!"
AuthUserFile  /usr/host/mysite/.htpasswd  
require valid-user

Доступ только пользователям admin и root

AuthType Basic  
AuthName "Private zone. Only for administrator!"
AuthUserFile  /usr/host/mysite/.htpasswd  
require user admin root

Доступ только пользователей из группы admins

AuthType Basic  
AuthName "Private zone. Only for administrator!"
AuthUserFile  /usr/host/mysite/.htpasswd  
AuthGroupFile /usr/host/mysite/group
require group admins

Запрет доступа только к файлу private.zip

<Files private.zip>
AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile  /usr/host/mysite/.htpasswd
require valid-user
</Files>

Xming. Подключение к X-Window Linux из Microsoft Windows

Обновлено: 11.04.2025
Теги: Linux Remote desktop

Эта статья на текущий момент устарела в том смысле, что Xming (сервер X Windows, который можно запустить на MS Windows) устарел совсем уж неприлично. Мне известны две замены: x410 (https://x410.dev, платная) и VcXsrv (Open-Source X Server for Windows, https://vcxsrv.com). На сегодня (11.04.25) на сайте доступна для скачивания версия 1.17.2.0 (файл vcxsrv-64.1.17.2.0.installer.zip, в архиве файл от 28.09.2024, в свойствах файла указана версия 1.17.2.0). Но общая суть работы не поменялась. Поэтому статью не меняю, оставлю для истории.


Запуск программ от имени администратора из-под ограниченной учетной записи

Обновлено: 13.09.2025
Теги: Windows Безопасность

Любой системный администратор сталкивался с ситуацией, когда бухгалтеру нужно поставить какую-нибудь программу, которая работает только под админом, например, банк-клиент. И часто из всех подходящих способов остается только дать админа и молиться, чтобы бухгалтерша не полезла шариться по форумам и пр. в поисках всякой полезной малвари.

Вариант создания ограниченной учетной записи и выдача пароля от админской учетной записи неудобен по нескольким соображениям:

1) Вводить пароль каждый раз будет неудобно (уж не помню, почему, но от ключа «/savecred» команды «runas» я отказался).
2) Факт владения паролем от админки(!) для бухгалтерши(!!!) открывает ей путь для волшебства. Аськи, плагины и прочие, недоступные ранее радости, теперь доступны. Естественно, это сразу отразиться на работе компьютера.

Выходом из сложившейся ситуации стала программа AdmiLink, создающая ярлык для запуска программы от имени какой-либо учетной записи, введенной ранее. Программа с русским интерфейсом, бесплатная и очень простая в использовании. Приведу цитату с сайта автора:

«AdmiLink - утилита, при помощи которой Администратор может создать ярлык, дающий возможность пользователям с ограниченными правами запускать конкретную (без возможности подмены!) программу с правами Администратора (или любого другого пользователя) без (интерактивного) ввода пароля.

Типичным применением программы AdmiLink является администрирование защищенных систем, в которых пользователь работает в основном под своей ограниченной учетной записью, и только отдельные, строго ограниченные Администратором функции запускает под Администратором, не зная его пароля и не имея возможности запускать другие, несанкционированные программы»

Запуск программ под администратором в Windows 7

Совершенно случайно (см. комментарии kpcp) я узнал, что Admilink при работе в Windows 7 может выдавать ошибку при попытке запуска созданного ярлыка для какой-нибудь программы, которую мы хотим выполнить под админом.

Выглядит это так (здесь и далее скрины и идея с oszone.net):

Происходит это из-за проблем с пресловутым "Контролем учетных записей пользователя" (User Account Control или UAC). Кто-то отключает UAC, но я не стал, все-таки лишний контроль не помешает.

Ладно, а как жить дальше-то? Решение не обычное, сразу сам бы не додумался, наверное:

Нам будет нужна утилита Elevate от Johannes Passing. Эта утилита из командной строки запустит нашу программу, которой нужны права администратора и у которой есть проблемы с поддержкой UAC:

> "C:AdminElevateReleaseElevate.exe" "C:EVERESTPORTABLEEVERESTULTIMATEPORTABLE.exe"

Выведется запрос UAC и приложение запустится от имени администратора.

Вот как это будет выглядеть в программе Admilink:

Вот так вот, желаю всем удачи! Большое спасибо автору программы и замечательной статье на oszone.net, в которой описан способ работы Admilink в Windows 7. Надеюсь, программа поможет многим!

Да, чуть не забыл, сайт программы http://www.crw-daq.ru/ или сразу руководство по установке.




Принимаю заказы на настройку серверов, mikrotik и других роутеров, точек доступа, nginx и т.п. В пределах Санкт-Петербурга возможен выезд к заказчику. См. контакты.

Squid 3proxy VPN Шифрование Почтовый сервер Mikrotik Настройка сервера Защита почты Резервное копирование Групповые политики java WDS IPFW SELinux kvm OpenVPN Виртуальные машины libvirt Mobile systemd Samba WiFi firewalld Lightsquid Remote desktop NAT Iptables Нейронные сети python Docker Софт Удаление данных Безопасность Winbox User agent Privacy Онлайн сервисы Передача данных Хостинг Dovecot Postfix VPN сервер RRDTool sendmail Rsync Linux Настройка прокси Система Windows Синхронизация Облако fail2ban SSH LetsEncrypt FreeBSD


Последние комментарии

13.06.2024 09:11 casper200
Спасибо, благодоря приведенной транскрипции, настроил проксю....
29.05.2024 17:36 bzzz
Еще нашел тут, что для парольной защиты (PSK) IPSec Xauth PSK и L2TP IPSec PSK, "Идентификатор IPSec" - это имя пользователя ...
29.05.2024 15:20 bzzz
Не уверен точно, но идентификатор IPSec - возможно, это IP-адрес сервера, или username@1.2.3.4 или FQDN-имя вашего сервера....
27.05.2024 14:55 Zahar
Здравствуйте, в Redmi Note 13 Pro после обновления просит обязательно внести Идентификатор Ipsec. Раньше это было необ...
27.05.2024 13:29 Diana
Здравствуйте
Подскажите. подключение с ПК все работает все ок. Делал по вашей мурзилке.
Но при подключе...
15.02.2024 16:53 Rost
Доброго дня! Проблема как у некоторых людей в комментвриях,что при подключении по VPN вне со снятием галочки &qu...