вторник, 20 апреля 2010
понедельник, 19 апреля 2010
Политика использования MS IE в установке-по-умолчанию MS Server 2008 R2 полностью совпадает с моим видением этого продукта: Он есть. Он кое-как работает. Пускать его в интернет НЕЛЬЗЯ.
HP-шники со своим ML100 G6 совсем с дубу рухнули - ни на офсайте, ни уж тем более на диске с дровами НЕТ драйвера видеоадаптера для 2008 R2 x64, при том, что этот самый R2 - официально рекомендованная для этого сервера ОС. Впрочем, для 2008 x86 их тоже нет. Зато они есть для ML110 G5. Даже работают. Моральby HP - "гую фтопку, ставьте CORE-ку", видимо.
Переход от FreeBSD (IPFW+DeleGate) к Windows XP + Traffic Inspector - полный отвал башки и вынос мозга. Хрен знает, на что и для кого эта прога рассчитана - для SOHO - слишком замудоглючна, для ENT-сегмента прокси-сервер-шлюз на вынь ХрюХрю как-то даже... не смешно. Впрочем, в качестве биллинг-системы для домашней сети или там какой-нибудь семейной гостиницы, наверное, сгодится...
HP-шники со своим ML100 G6 совсем с дубу рухнули - ни на офсайте, ни уж тем более на диске с дровами НЕТ драйвера видеоадаптера для 2008 R2 x64, при том, что этот самый R2 - официально рекомендованная для этого сервера ОС. Впрочем, для 2008 x86 их тоже нет. Зато они есть для ML110 G5. Даже работают. Мораль
Переход от FreeBSD (IPFW+DeleGate) к Windows XP + Traffic Inspector - полный отвал башки и вынос мозга. Хрен знает, на что и для кого эта прога рассчитана - для SOHO - слишком замудоглючна, для ENT-сегмента прокси-сервер-шлюз на вынь ХрюХрю как-то даже... не смешно. Впрочем, в качестве биллинг-системы для домашней сети или там какой-нибудь семейной гостиницы, наверное, сгодится...
пятница, 16 апреля 2010
Определившись со списком доступных служб хакер переходит к следующему, последнему перед собственно "атакой" этапу - попытке определения версий ОС и установленного ПО.
С версией конкретных программ все может быть как очень просто так и очень сложно - большинство сетевых служб при установлении соединения выдают т.н. информационный баннер с указанием поддерживаемых возможностей, номера версии (Хорошо если только самой программы, а то ведь и ОС спалить могут )) - этого, собственно, достаточно.
Что с этим можно сделать? Прежде всего, посмотреть настройки службы, очень может быть, что там есть что-либо, определяющее формат "приветствия" (VersionAddendum в SSH, Version в named.conf BIND'а и пр.), иногда этого достаточно - чаще нет. Бывает, что информация о версии жестко зашивается при компиляции программы, стоит ли затевать возню с пересборкой - решать вам.
Дополнительно можно соорудить "хитрую ловушку для слонопотамов" - открыть на файрволле несколько портов, принадлежащих каким-нибудь заведомо небезопасным службам и подвесить на них "Банник"(ТМ). Соорудить оный можно самостоятельно при помощи, например, inetd+TCPWrappers+IPFW, или воспользоваться уже готовым - например, portsentry из ./ports/security. Кстати, готовые "сторожки" вполне могут помочь и в случае -sS сканирования (См. выше), но злоупотреблять ими не стоит (Ибо какие-то ресурсы они все-таки жрут сами по себе, да и организовать с их помощью DOS-атаку вполне реально.), и полностью полагаться на них нельзя (Возможностей по смене IP даже у "среднезавалящего" хакера более, чем достаточно).
Определение версии ОС - штука куда более интересная. Обратимся, опять же к документации nmap нам доступны следующие методы:
- TCP Sequence generation (SEQ, OPS, WIN, and T1)
- ICMP echo
- TCP explicit congestion notification (ECN)
- TCP tests (T2–T7)
Проще всего опять же с ICMP echo - он у нас уже забанен
.
С Т2-Т7 все тоже не слишком сложно: 3,5,6,7 тесты требуют доступных закрытых портов, которых у нас, опять же, уже нет, 2й - повторяет уже "зарубленное" TCP NULL-сканирование, 4ый надежно отсекается statefull правилами.
Остаются Sequence generation и ECN. В 8ке вроде как имеется sysctl, ответственный за это самое "congestion notification", но скажу честно - не проверял.
T1 - пожалуй самая большая проблема. Опять же, "рубить" SYN-пакеты мы не имеем права, ничего "особо криминального" они не содержат, а методов "анализа последовательности" у ipfw нет. Тупик? М-мммм... не вполне. Помешать проведению теста мы, может и не сможем, но "спутать" его результаты - вполне. Для этого устанавливаем net.inet.ip.random_id в единицу и наблюдаем результаты (Мою 7_3 nmap радостно определил как то ли OpenBSD, то ли Free в диапазоне с 6й по 8ю) - не идеально, но приемлемо.
С версией конкретных программ все может быть как очень просто так и очень сложно - большинство сетевых служб при установлении соединения выдают т.н. информационный баннер с указанием поддерживаемых возможностей, номера версии (Хорошо если только самой программы, а то ведь и ОС спалить могут )) - этого, собственно, достаточно.
Что с этим можно сделать? Прежде всего, посмотреть настройки службы, очень может быть, что там есть что-либо, определяющее формат "приветствия" (VersionAddendum в SSH, Version в named.conf BIND'а и пр.), иногда этого достаточно - чаще нет. Бывает, что информация о версии жестко зашивается при компиляции программы, стоит ли затевать возню с пересборкой - решать вам.
Дополнительно можно соорудить "хитрую ловушку для слонопотамов" - открыть на файрволле несколько портов, принадлежащих каким-нибудь заведомо небезопасным службам и подвесить на них "Банник"(ТМ). Соорудить оный можно самостоятельно при помощи, например, inetd+TCPWrappers+IPFW, или воспользоваться уже готовым - например, portsentry из ./ports/security. Кстати, готовые "сторожки" вполне могут помочь и в случае -sS сканирования (См. выше), но злоупотреблять ими не стоит (Ибо какие-то ресурсы они все-таки жрут сами по себе, да и организовать с их помощью DOS-атаку вполне реально.), и полностью полагаться на них нельзя (Возможностей по смене IP даже у "среднезавалящего" хакера более, чем достаточно).
Определение версии ОС - штука куда более интересная. Обратимся, опять же к документации nmap нам доступны следующие методы:
- TCP Sequence generation (SEQ, OPS, WIN, and T1)
- ICMP echo
- TCP explicit congestion notification (ECN)
- TCP tests (T2–T7)
Проще всего опять же с ICMP echo - он у нас уже забанен
.С Т2-Т7 все тоже не слишком сложно: 3,5,6,7 тесты требуют доступных закрытых портов, которых у нас, опять же, уже нет, 2й - повторяет уже "зарубленное" TCP NULL-сканирование, 4ый надежно отсекается statefull правилами.
Остаются Sequence generation и ECN. В 8ке вроде как имеется sysctl, ответственный за это самое "congestion notification", но скажу честно - не проверял.
T1 - пожалуй самая большая проблема. Опять же, "рубить" SYN-пакеты мы не имеем права, ничего "особо криминального" они не содержат, а методов "анализа последовательности" у ipfw нет. Тупик? М-мммм... не вполне. Помешать проведению теста мы, может и не сможем, но "спутать" его результаты - вполне. Для этого устанавливаем net.inet.ip.random_id в единицу и наблюдаем результаты (Мою 7_3 nmap радостно определил как то ли OpenBSD, то ли Free в диапазоне с 6й по 8ю) - не идеально, но приемлемо.
четверг, 15 апреля 2010
После обнаружения в анализируемой сети активных хостов атакующий переходит к следующему этапу - попытке определить список доступных сетевых служб на целевой машине. Для этого используется т.н. технология "сканирования портов".
Наиболее распространены следующие типы сканирования:
- сканирование "полусоединением", оно же stealth, tcp syn и пр.
- сканирование с нестандартной установкой tcp-флагов
- UDP-сканирование
Для решения специфических задач (Определение правил брандмауэра, обход брандмауэра, сканирование нестандартных систем и пр) могут так же использоваться TCP ACK сканирование, сканирование Мэймона и TCP-window сканирование.
Проще всего справиться со сканированием с нестандартной установкой флагов:
ipfw add deny all from any to any tcpflags syn,fin,ack,psh,urg,rst - NULL-scan
ipfw add deny all from any to any tcpflags !syn,!fin,!ack,!psh,!urg,!rst XMAS-scan
ipfw add deny all from any to any not established tcpflags fin FIN-сканирование.
UDP-сканирование само по себе штука не простая - открытые порты почти всегда (Зависит от службы) не отвечают на запрос, фильтруемые порты не отвечают тем более, а закрытых портов при правильно настроенном файрволле у нас просто нет ).
Увы, самый простой, самый быстрый и самый надежный способ (Используемый nmap'ом по умолчанию) заблокировать практически невозможно: syn-пакет является частью легитимного процесса установления соединения. В процессе подобного сканирования _можно_ обнаружить две аномалии - резкое увеличение пакетов с rst-флагом приходящих с одного адреса и большое количество попыток установления соединения. Теоретически, это можно использовать для попытки обнаружения сканирования, но на практике все не так просто. Используя ipfw можно попытаться ограничить число одновременных попыток соединения, но поможет это мало - даже последовательный перебор всех 65535 портов занимает порядка 20 секунд, пытаться "ускорить" этот процесс - нет особого смысла. Попытка обнаружить аномальное увеличение RST-пакетов с помощью IDS так же не приведет к успеху, т.к. установление соединений с закрытыми портами будет заблокировано межсетевым экраном и собственно увеличения - не произойдет.
Таким образом, можно с уверенностью сказать, что атакующий _получит_ список запущенных на целевой машине сетевых служб, и с этим мало что можно сделать.
Наиболее распространены следующие типы сканирования:
- сканирование "полусоединением", оно же stealth, tcp syn и пр.
- сканирование с нестандартной установкой tcp-флагов
- UDP-сканирование
Для решения специфических задач (Определение правил брандмауэра, обход брандмауэра, сканирование нестандартных систем и пр) могут так же использоваться TCP ACK сканирование, сканирование Мэймона и TCP-window сканирование.
Проще всего справиться со сканированием с нестандартной установкой флагов:
ipfw add deny all from any to any tcpflags syn,fin,ack,psh,urg,rst - NULL-scan
ipfw add deny all from any to any tcpflags !syn,!fin,!ack,!psh,!urg,!rst XMAS-scan
ipfw add deny all from any to any not established tcpflags fin FIN-сканирование.
UDP-сканирование само по себе штука не простая - открытые порты почти всегда (Зависит от службы) не отвечают на запрос, фильтруемые порты не отвечают тем более, а закрытых портов при правильно настроенном файрволле у нас просто нет ).
Увы, самый простой, самый быстрый и самый надежный способ (Используемый nmap'ом по умолчанию) заблокировать практически невозможно: syn-пакет является частью легитимного процесса установления соединения. В процессе подобного сканирования _можно_ обнаружить две аномалии - резкое увеличение пакетов с rst-флагом приходящих с одного адреса и большое количество попыток установления соединения. Теоретически, это можно использовать для попытки обнаружения сканирования, но на практике все не так просто. Используя ipfw можно попытаться ограничить число одновременных попыток соединения, но поможет это мало - даже последовательный перебор всех 65535 портов занимает порядка 20 секунд, пытаться "ускорить" этот процесс - нет особого смысла. Попытка обнаружить аномальное увеличение RST-пакетов с помощью IDS так же не приведет к успеху, т.к. установление соединений с закрытыми портами будет заблокировано межсетевым экраном и собственно увеличения - не произойдет.
Таким образом, можно с уверенностью сказать, что атакующий _получит_ список запущенных на целевой машине сетевых служб, и с этим мало что можно сделать.
среда, 14 апреля 2010
... тему или немного о, собственно, безопасности.
Первое, что делает хакер перед атакой - определяет цель. В сети 4 294 967 296 IPv4 адресов (Плюс-минус лапоть в виде зарезервированных для спец. использования подсетей) и понять, какой из них тебе нужен не так-то просто. В случае, если система оказывает какие-либо услуги внешним клиентам (Web-сервер, SMTP-сервер и пр) "прятаться" в общем-то, не имеет смысла и этот пост можно смело пропустить, а вот если речь идет, например, о корпоративном шлюзе скрыть сам факт его существования - не самая плохая идея.
Каким образом это можно сделать? Открываем раздел документации NMAP, посвященный процессу обнаружения хостов и смотрим, каким образом это самое "обнаружение" может производиться:
- при помощи ICMP-запросов различного типа (-sP -PE -PP -PM)
- при помощи посылки tcp-пакетов с установленными флагами SYN/ACK на некоторые порты
- при помощи посылки udp-пакетов на некоторые порты
- пингование с помощью ARP
- пингование с помощью IP-протокола
По первому пункту все ясно - тупо дропаем icmptypes 8,14,18 (Ай-яй-яй! Нарушаем rfc 1122/792, ну да Кришна с ним.) и не беспокоимся. Вообще, про ICMP еще будет, причем достаточно много.
Второй пункт несколько сложнее - мы _в принципе_ не можем блокировать пакеты с установленным SYN'ом, но - мы можем закрыть наиболее часто употребляющиеся при сканировании порты (-PS22,25,80 -PA21,23,80,3389 - что-то вроде), перенеся соответствующие службы куда-нибудь подальше. Про 25/80 я уже говорил - прятать их обычно нет никакого смысла, 23 - малоактуален, 21 - уже гадательно, 3389 на *nix-машине маловероятен, а вот 22-ssh закинуть куда-нибудь "повыше" (При помощи директивы listenaddress addr:port в sshd_config) - самое оно.
С UDP для атакующего тоже все не просто - явный "отклик" дают только "закрытые" порты, которых в случае правильно настроенного firewall'а у нас просто не должно быть.
ARP-сканирование по большому счету имеет смысл только в локальной сети и защищаться от негодолго и уныло в общем-то нет необходимости
А вот с -PO и впрямь могут возникнуть проблемы, хотя задропаный исходящий icmptypes 3 частично помогает, плюс кое-что (IPv6, SCTP и пр.) можно "выпилить" при компиляции ядра.
Первое, что делает хакер перед атакой - определяет цель. В сети 4 294 967 296 IPv4 адресов (
Каким образом это можно сделать? Открываем раздел документации NMAP, посвященный процессу обнаружения хостов и смотрим, каким образом это самое "обнаружение" может производиться:
- при помощи ICMP-запросов различного типа (-sP -PE -PP -PM)
- при помощи посылки tcp-пакетов с установленными флагами SYN/ACK на некоторые порты
- при помощи посылки udp-пакетов на некоторые порты
- пингование с помощью ARP
- пингование с помощью IP-протокола
По первому пункту все ясно - тупо дропаем icmptypes 8,14,18 (Ай-яй-яй! Нарушаем rfc 1122/792, ну да Кришна с ним.) и не беспокоимся. Вообще, про ICMP еще будет, причем достаточно много.
Второй пункт несколько сложнее - мы _в принципе_ не можем блокировать пакеты с установленным SYN'ом, но - мы можем закрыть наиболее часто употребляющиеся при сканировании порты (-PS22,25,80 -PA21,23,80,3389 - что-то вроде), перенеся соответствующие службы куда-нибудь подальше. Про 25/80 я уже говорил - прятать их обычно нет никакого смысла, 23 - малоактуален, 21 - уже гадательно, 3389 на *nix-машине маловероятен, а вот 22-ssh закинуть куда-нибудь "повыше" (При помощи директивы listenaddress addr:port в sshd_config) - самое оно.
С UDP для атакующего тоже все не просто - явный "отклик" дают только "закрытые" порты, которых в случае правильно настроенного firewall'а у нас просто не должно быть.
ARP-сканирование по большому счету имеет смысл только в локальной сети и защищаться от него
А вот с -PO и впрямь могут возникнуть проблемы, хотя задропаный исходящий icmptypes 3 частично помогает, плюс кое-что (IPv6, SCTP и пр.) можно "выпилить" при компиляции ядра.
вторник, 13 апреля 2010
... firewall'ах (На примере IPFW) - вдруг кому интересно? ))
Основные требования к правилам межсетевого экрана - читаемость и производительность. Если первое более-менее понятно (Кому не понятно - откройте дефолтовый rc.firewall FreeBSD и никогда, никогда, НИКОГДА не повторяйте то, что там увидите!), то со вторым надо разобраться чуть по-подробней.
От чего зависит производительность firewall'а? От количества операций сравнения, которые производит межсетевой экран над полученными в результате анализа пакета данными. Оно, в свою очередь, определяется количеством правил, которое проходит пакет и числом критериев, по которым производится сравнение.
Для примера возьмем несколько достаточно стандартных правил из Handbook'а:
Что мы видим? Любой пакет, направленный "к нам" будет последовательно сравниваться с правилами, предназначенными для "исходящих" пакетов (0-299) и только потом дойдет до правил, предназначенных собственно для обработки пакетов "входящих", кроме того, в каждом правиле предусмотрена проверка "направления движения" пакета и интерфейса, через который он "движется". Не-по-ря-док.
Что тут можно сделать? Например, разделить поток трафика...
... примерно таким образом:
При этом а) входящим пакетам не придется проходить сравнения с правилами предназначенными для пакетов исходящих и б) собственно операции сравнения можно значительно упростить т.к. "направление движения" и "интерфейс" мы проверяем при этом самом "делении". Как только в дело вмешается nat + расположенные на самом сервере службы таким простым делением обойтись уже не удастся - я лично делю трафик на (входящий-исходящий), (внутренний интерфейс-наружный интерфейс), (адресованный серверу - транзитный), в ряде случаев к последней "дележке" добавляются еще broadcast и multicast трафик, но это требуется не слишком часто. Единственное требование, нужное для выполнения этого "фокуса" - _явная_ нумерация всех правил в списке, что определенным образом затрудняет сопровождение скрипта.
Можно еще скомпоновать несколько правил "в одно":
$cmd 00200 allow tcp from any to any 80,443,25,110 setup keep-state
Не следует забывать, что подобная организация правил упрощает сопровождение-управление скрипта и затрудняет тонкую "донастройку" правил, но "группировать" подобным образом "однотипные" протоколы можно и нужно.
Для того, чтобы все это не превратилось в нечитаемую мешанину изgoskipto рекомендуется:
- Нумеровать правила с шагом хотя бы в 10 (Но в 100, как собственно и установлено по дефолту - лучше. Мало ли...).
- Отделять логические блоки правил друг от друга при помощи комментариев, в которых _обязательно_ указывать что это за блок, и в каком числовом диапазоне он расположен ("#######Обрабатываем входящий трафик 0-32500#####:" - примерно так).
- Не экономить на "внутритекстовых" комментариях.
Основные требования к правилам межсетевого экрана - читаемость и производительность. Если первое более-менее понятно (Кому не понятно - откройте дефолтовый rc.firewall FreeBSD и никогда, никогда, НИКОГДА не повторяйте то, что там увидите!), то со вторым надо разобраться чуть по-подробней.
От чего зависит производительность firewall'а? От количества операций сравнения, которые производит межсетевой экран над полученными в результате анализа пакета данными. Оно, в свою очередь, определяется количеством правил, которое проходит пакет и числом критериев, по которым производится сравнение.
Для примера возьмем несколько достаточно стандартных правил из Handbook'а:
Что мы видим? Любой пакет, направленный "к нам" будет последовательно сравниваться с правилами, предназначенными для "исходящих" пакетов (0-299) и только потом дойдет до правил, предназначенных собственно для обработки пакетов "входящих", кроме того, в каждом правиле предусмотрена проверка "направления движения" пакета и интерфейса, через который он "движется". Не-по-ря-док.
Что тут можно сделать? Например, разделить поток трафика...
... примерно таким образом:
При этом а) входящим пакетам не придется проходить сравнения с правилами предназначенными для пакетов исходящих и б) собственно операции сравнения можно значительно упростить т.к. "направление движения" и "интерфейс" мы проверяем при этом самом "делении". Как только в дело вмешается nat + расположенные на самом сервере службы таким простым делением обойтись уже не удастся - я лично делю трафик на (входящий-исходящий), (внутренний интерфейс-наружный интерфейс), (адресованный серверу - транзитный), в ряде случаев к последней "дележке" добавляются еще broadcast и multicast трафик, но это требуется не слишком часто. Единственное требование, нужное для выполнения этого "фокуса" - _явная_ нумерация всех правил в списке, что определенным образом затрудняет сопровождение скрипта.
Можно еще скомпоновать несколько правил "в одно":
$cmd 00200 allow tcp from any to any 80,443,25,110 setup keep-state
Не следует забывать, что подобная организация правил упрощает сопровождение-управление скрипта и затрудняет тонкую "донастройку" правил, но "группировать" подобным образом "однотипные" протоколы можно и нужно.
Для того, чтобы все это не превратилось в нечитаемую мешанину из
- Нумеровать правила с шагом хотя бы в 10 (Но в 100, как собственно и установлено по дефолту - лучше. Мало ли...).
- Отделять логические блоки правил друг от друга при помощи комментариев, в которых _обязательно_ указывать что это за блок, и в каком числовом диапазоне он расположен ("#######Обрабатываем входящий трафик 0-32500#####:" - примерно так).
- Не экономить на "внутритекстовых" комментариях.
понедельник, 12 апреля 2010
Поставил вместо isc-dhcpd 3.1.3 (С обновлением от 27 марта, ага) его же версии 3.0.7_5. Запустил с теми же конфигами. Возрадовался, ибо работает. Решил разобраться чуть-глубже, стартанул tcpdump -i lo0 -w ./3.0.7_5, записал дамп происходящего. Снес 3.0.7_5, воткнул обратно 3.1.3, злорадно запустил tcpdump... и обломался! ЭТА СВОЛОЧЬ НАЧАЛА НОРМАЛЬНО ОБНОВЛЯТЬ ОБРАТНУЮ ЗОНУ!!!
Снес-почистил-ребутнул-поставил-запустил... обновляет. Скопировал конфиги на другую виртуальную машину, запустил... работает! Без всякого копирования нарисовал всю схему по новой на свободной ВМке - тоже работает.
Сижу в раздумьях и сомненьях - "то ли лыжи не едут, то ли я ..."(Ц).
Буду утешаться тем, что скилл установки-настройки BIND'а поднялся на пару пунктов. На будущее - копирнул себе стартовые скрипты от 3.1.3 и сорцы от 4.1.1, буду пользоваться ими...
Снес-почистил-ребутнул-поставил-запустил... обновляет. Скопировал конфиги на другую виртуальную машину, запустил... работает! Без всякого копирования нарисовал всю схему по новой на свободной ВМке - тоже работает.
Сижу в раздумьях и сомненьях - "то ли лыжи не едут, то ли я ..."(Ц).
Буду утешаться тем, что скилл установки-настройки BIND'а поднялся на пару пунктов. На будущее - копирнул себе стартовые скрипты от 3.1.3 и сорцы от 4.1.1, буду пользоваться ими...
пятница, 09 апреля 2010
... не растет кокос" - редкое ощущение: НЕ хочется работать. Есть пара действительно интересных задачек, но решать их нет ни малейшего желания. Хочется... странного.
"Пойду, полежу - может пройдет"(С)
"Пойду, полежу - может пройдет"(С)
среда, 07 апреля 2010
... т.е. о граблях(ТМ).
FreeBSD 7_3.
DNS. Зона прямого просмотра. Зона обратного просмотра. Файл с ключом. named-checkconf. named-checkzone. OK
DHCP. update-style interim. Зоны, primary 127.0.0.1; ключ. isc-dhcpd start. ОК.
Проверяем клиента - ipconfig /release - ipconfig /renew. Получаем адрес. nslookup <имя> - получаем IP. nslookup ip - получаем... ничего не получаем.
Лезем в логи - offer/ack, forward проапдейтили, TXT + A создали, TXT удалили, а с revers'ом - таки ой: "dhcpd: unable to add reverse map from <> to <> timed out".
В логах BIND'а чуть интересней:
client 127.0.0.1 updating zone бла-бла-бла ОК
client внешний адрес update 'x.x.x.in-addr.arpa/IN' denied.
Шо за нафиг? Прямую зону обновляем через 127.0.0.1, а обратную - через собственно интерфейс? Резво лезу в dhcpd.conf - нет, и там, и там стоит обращаться к 127.0.0.1. Странно. Запускаю tcpdump -i lo0, делаю release-renew на клиенте - думаю, может, это он, зар-раза за обновлением пополз, на DHCPD наплевав? Не-а!!! Запрос на обновление прямой зоны идет через 127.0.0.1 от, собственно, 127.0.0.1, а запрос на обновление зоны обратного преобразования идет через 127.0.0.1 же, но src-addr там именно что адрес реального интерфейса!
Для проверки меняю у зоны обратного преобразования update-policy на allow-update { адрес интрефейса }, проверяю - пашет. Меняю на 127.0.0.1 - нихтЪ. Ставлю вместо адреса ключ - опять нихтЪ. Запускаю nsupdate -k <ключ>, server = 127.0.0.1, делаю обновление - проходит.
"От такая вот загогулина"(С). Оно, конечно, и без зоны обратного просмотра прожить можно, да и на всю бОшку инсекьюрные апдейты по IP-адресу нормально пашут, но, блин, интересно же! Полдня вокруг железки с бубном плясал, так ничего и не добился. Думаю завтра качнуть с isc.org сорцы 4_1_1 вместо 3х из портов и попробовать скрестить ежа с ужом...
Вся жизнь - борьба!
FreeBSD 7_3.
DNS. Зона прямого просмотра. Зона обратного просмотра. Файл с ключом. named-checkconf. named-checkzone. OK
DHCP. update-style interim. Зоны, primary 127.0.0.1; ключ. isc-dhcpd start. ОК.
Проверяем клиента - ipconfig /release - ipconfig /renew. Получаем адрес. nslookup <имя> - получаем IP. nslookup ip - получаем... ничего не получаем.
Лезем в логи - offer/ack, forward проапдейтили, TXT + A создали, TXT удалили, а с revers'ом - таки ой: "dhcpd: unable to add reverse map from <> to <> timed out".
В логах BIND'а чуть интересней:
client 127.0.0.1 updating zone бла-бла-бла ОК
client внешний адрес update 'x.x.x.in-addr.arpa/IN' denied.
Шо за нафиг? Прямую зону обновляем через 127.0.0.1, а обратную - через собственно интерфейс? Резво лезу в dhcpd.conf - нет, и там, и там стоит обращаться к 127.0.0.1. Странно. Запускаю tcpdump -i lo0, делаю release-renew на клиенте - думаю, может, это он, зар-раза за обновлением пополз, на DHCPD наплевав? Не-а!!! Запрос на обновление прямой зоны идет через 127.0.0.1 от, собственно, 127.0.0.1, а запрос на обновление зоны обратного преобразования идет через 127.0.0.1 же, но src-addr там именно что адрес реального интерфейса!
Для проверки меняю у зоны обратного преобразования update-policy на allow-update { адрес интрефейса }, проверяю - пашет. Меняю на 127.0.0.1 - нихтЪ. Ставлю вместо адреса ключ - опять нихтЪ. Запускаю nsupdate -k <ключ>, server = 127.0.0.1, делаю обновление - проходит.
"От такая вот загогулина"(С). Оно, конечно, и без зоны обратного просмотра прожить можно, да и на всю бОшку инсекьюрные апдейты по IP-адресу нормально пашут, но, блин, интересно же! Полдня вокруг железки с бубном плясал, так ничего и не добился. Думаю завтра качнуть с isc.org сорцы 4_1_1 вместо 3х из портов и попробовать скрестить ежа с ужом...
Вся жизнь - борьба!
вторник, 06 апреля 2010
Вот кто бы объяснил владельцам навороченных торговых центров, что хорошая "магазинная логистика" это не "Когда ты платишь народу в два раза меньше", а "Когда у тебя _нет_ очередей". Взяли, оладушек, моду - в час пик из десяти касс работает хорошо, если шесть, очередь отсюда и до... до, в общем. Делаешь замечание администратору - минут через... несколько могут открыть еще одну. А могут и не открыть, ага.
Казалось бы, чего проще - написать над одной-двумя кассами - "Всем, у кого меньше 4-5-6 покупок с оплатой за наличный расчет - сюда!", поставить "светофор", сигнализирующий о длине очереди у каждой кассы, у кассы, предназначенной для тележек поставить отдельного упаковщика - и проходимость сразу же возрастет! Ей-ктулху, своими глазами видел - увы, не в Екатеринбурге. Здесь предпочитают "проверенные методы" советской еще эпохи.
Такое ощущение, что на весь город - один приличный магазин, и тот - "Монетка". В остальных продавцы ведут себя так, будто клиенты вечно хотят от них "странного" - ну там, чтобы на товарах были ценники, рядом с прилавками - кульки для упаковки, стационарные сканеры штрих-кодов _работали_ и пр.
Повбывал бы, натурально.
Казалось бы, чего проще - написать над одной-двумя кассами - "Всем, у кого меньше 4-5-6 покупок с оплатой за наличный расчет - сюда!", поставить "светофор", сигнализирующий о длине очереди у каждой кассы, у кассы, предназначенной для тележек поставить отдельного упаковщика - и проходимость сразу же возрастет! Ей-ктулху, своими глазами видел - увы, не в Екатеринбурге. Здесь предпочитают "проверенные методы" советской еще эпохи.
Такое ощущение, что на весь город - один приличный магазин, и тот - "Монетка". В остальных продавцы ведут себя так, будто клиенты вечно хотят от них "странного" - ну там, чтобы на товарах были ценники, рядом с прилавками - кульки для упаковки, стационарные сканеры штрих-кодов _работали_ и пр.
Повбывал бы, натурально.
понедельник, 05 апреля 2010
... в третий раз переписать основной firewall'ьный скрипт - ибо "читаемость" входит в противоречие с "простотой парсинга".
Медитирую на фразу "совершенство недостижимо", думаю странное ).
Медитирую на фразу "совершенство недостижимо", думаю странное ).
пятница, 02 апреля 2010
... написать ли мне еще немного о классических (По сеансовый уровень включительно) firewall'ах "вообще", сказать пару-тройку слов конкретно про ipfw, перейти к application level proxy, или написать чуть-чуть об организации DNS в доменах MS AD и не только?
Ладно, пока суть-да-дело, напишу-ка я о... ноутбуках. В общем-то, о том, что свой букварь я купил уже м-ммм... два года назад, и с тех пор "софтострой" так и не сподвиг меня на апгрейд я уже писал. Похоже, фирма Интел победила Майкрософт "за явным преимуществом" - не самое мощное железо двухлетней давности вполне прилично тянет ОС последнего поколения с "довеском" в виде пары виртуальных машин. Конечная станция "Золотой век"? Не-а.
Итак, что способно сподвигнуть меня на замену железа:
- Мобильный интернет уровня той же Йоты (Ну или хотя бы Sky-Link'а), ОПСОСную USB-пипирку не предлагать . Конечно, дело это не (с)только "железячное" (Intel собственно, уже )) - н-но...
- Увеличенный хотя бы до 8-ми (Но десять - лучше!) часов срок автономной _работы_ (Не "включил и ждешь", а именно _работаешь_).
- Доступные SSD с прогнозируемой (Или просто увеличенной ДО) надежностью работы. Гигов 160 со скоростью записи под 200 за нормальные деньги и я ваш.
- Качественные изменения интерфейса Честно говоря, предполагаемые multitouch-планшетки не кажутся мне особенно удобными именно для _работы_, но в сочетании с первыми пунктами - чем черт не шутит?
Ладно, пока суть-да-дело, напишу-ка я о... ноутбуках
. В общем-то, о том, что свой букварь я купил уже м-ммм... два года назад, и с тех пор "софтострой" так и не сподвиг меня на апгрейд я уже писал. Похоже, фирма Интел победила Майкрософт "за явным преимуществом" - не самое мощное железо двухлетней давности вполне прилично тянет ОС последнего поколения с "довеском" в виде пары виртуальных машин. Конечная станция "Золотой век"? Не-а.Итак, что способно сподвигнуть меня на замену железа:
- Мобильный интернет уровня той же Йоты (Ну или хотя бы Sky-Link'а
), ОПСОСную USB-пипирку не предлагать . Конечно, дело это не (с)только "железячное" (Intel собственно, уже )) - н-но...- Увеличенный хотя бы до 8-ми (Но десять - лучше!) часов срок автономной _работы_ (Не "включил и ждешь", а именно _работаешь_).
- Доступные SSD с прогнозируемой (Или просто увеличенной ДО) надежностью работы. Гигов 160 со скоростью записи под 200 за нормальные деньги и я ваш
.- Качественные изменения интерфейса Честно говоря, предполагаемые multitouch-планшетки не кажутся мне особенно удобными именно для _работы_, но в сочетании с первыми пунктами - чем черт не шутит?
четверг, 01 апреля 2010
... ошибки (?) при написании firewall'ов:
Первая - исключение из рассмотрения одного из проходов. "Слева у меня диск С и справа у меня диск С, ну я один и удалил"(С), ага. Зачем описывать в правилах два прохода - "замышим" все на выходе в интернет и будем жить, да. В лучшем случае трафик делится на "входящий" и "исходящий" без указания интерфейсов - т.е. дважды проходит _один и тот же_ набор правил, а в худшем - просто ставится что-то вроде ipfw add allow all from any to any via <внутренний интерфейс>.
Пошло все это, как мне кажется с весьма умных людей, которые решали достаточно специфические задачи (Интернет-провайдинг) в достаточно специфических условиях (ОЧЕНЬ большой объем трафика, отсутствие каких-либо "дополнительных" служб на сервере, практически одинаковый уровень безопасности "внутренней" и "наружной" сетей и пр), охотно приводимые ими примеры отлично работали, хорошо читались, охотно комментировались и, как следствие, получили широкое распространение.
"Куда крестьяне, туда и обезьяне", ага. Увы, в "корпоративных" (Малый-средний бизнес, где все еще "в ходу" подобные "самоделки") решениях условия-требования несколько другие: "наружная" и "внутренняя" сеть обладают разными уровнями безопасности, "внутренняя" сеть, кто бы там что не думал, _НЕ_ является "абсолютно безопасной" (Т.е. решение с разрешением _всего_ трафика на внутреннем интерфейсе является категорически неприемлемым), сам брандмауэр может предоставлять внутренним пользователям дополнительные услуги (DNS-сервер, различные proxy и пр) - так что экономить на "головоемкости" не следует, и "мой тоби совет" - контролировать надо _оба_ прохода трафика, причем правила контроля "в общем случае" должны быть _разные_.
Вторая распространенная ошибка - использование nat'а в качестве stateful фильтра. Казалось бы, и там и там мы контролируем src port/addr - dst port/addr, создаем динамические правила с ограниченным сроком жизни - "... What's the difference?"(C). Увы, в большинстве современных реализаций nat'а она все-таки есть. Более-менее контроль состояния обеспечивает т.н. symmetric nat (Навскидку - pf), остальные реализации (Port restricted, addr restricted, full clone nat) допускают те или иные вольности с прохождением трафика (Из любви к истине скажем, что делается это не просто так - наиболее "безопасная" реализация nat'а, равно как и statefull filtering сам по себе, создают значительные проблемы ряду протоколов (Пиринговые сети, STUN и пр)).
Если посмотреть еще чуть-чуть глубже, например, набрав во FreeBSD'шной консоли sysctl net.inet.ip.fw мы увидим:
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300
что stateful фильтрация контролирует _все_ стадии "жизни" tcp-соединения, создавая целый _ряд_ динамических правил с разным временем жизни, чем известные мне реализации nat'а (Совершенно справедливо, ибо не барское это дело) не озадачиваются. Ergo - на nat надейся, а "контролем состояния" не пренебрегай, как бы геморройно это ни было в том же ipfw . Впрочем, чрезмерно увлекаться подобным контролем тоже не стоит - записи в таблице состояний, записи в таблице nat'а, энное количество правил + два прохода трафика = потенциальная уязвимость к (D)DOS атакам. На мой взгляд, имеет смысл использовать контроль состояния на выходе из firewall'а, а на внутреннем интерфейсе можно применять классическую пакетную фильтрацию образца 80х годов... впрочем, по этому поводу я все еще думаю, ибо "совершенство приходит с опытом"
Первая - исключение из рассмотрения одного из проходов. "Слева у меня диск С и справа у меня диск С, ну я один и удалил"(С), ага. Зачем описывать в правилах два прохода - "замышим" все на выходе в интернет и будем жить, да. В лучшем случае трафик делится на "входящий" и "исходящий" без указания интерфейсов - т.е. дважды проходит _один и тот же_ набор правил, а в худшем - просто ставится что-то вроде ipfw add allow all from any to any via <внутренний интерфейс>.
Пошло все это, как мне кажется с весьма умных людей, которые решали достаточно специфические задачи (Интернет-провайдинг) в достаточно специфических условиях (ОЧЕНЬ большой объем трафика, отсутствие каких-либо "дополнительных" служб на сервере, практически одинаковый уровень безопасности "внутренней" и "наружной" сетей и пр), охотно приводимые ими примеры отлично работали, хорошо читались, охотно комментировались и, как следствие, получили широкое распространение.
"Куда крестьяне, туда и обезьяне", ага. Увы, в "корпоративных" (Малый-средний бизнес, где все еще "в ходу" подобные "самоделки") решениях условия-требования несколько другие: "наружная" и "внутренняя" сеть обладают разными уровнями безопасности, "внутренняя" сеть, кто бы там что не думал, _НЕ_ является "абсолютно безопасной" (Т.е. решение с разрешением _всего_ трафика на внутреннем интерфейсе является категорически неприемлемым), сам брандмауэр может предоставлять внутренним пользователям дополнительные услуги (DNS-сервер, различные proxy и пр) - так что экономить на "головоемкости" не следует, и "мой тоби совет" - контролировать надо _оба_ прохода трафика, причем правила контроля "в общем случае" должны быть _разные_.
Вторая распространенная ошибка - использование nat'а в качестве stateful фильтра. Казалось бы, и там и там мы контролируем src port/addr - dst port/addr, создаем динамические правила с ограниченным сроком жизни - "... What's the difference?"(C). Увы, в большинстве современных реализаций nat'а она все-таки есть. Более-менее контроль состояния обеспечивает т.н. symmetric nat (Навскидку - pf), остальные реализации (Port restricted, addr restricted, full clone nat) допускают те или иные вольности с прохождением трафика (Из любви к истине скажем, что делается это не просто так - наиболее "безопасная" реализация nat'а, равно как и statefull filtering сам по себе, создают значительные проблемы ряду протоколов (Пиринговые сети, STUN и пр)).
Если посмотреть еще чуть-чуть глубже, например, набрав во FreeBSD'шной консоли sysctl net.inet.ip.fw мы увидим:
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300
что stateful фильтрация контролирует _все_ стадии "жизни" tcp-соединения, создавая целый _ряд_ динамических правил с разным временем жизни, чем известные мне реализации nat'а (Совершенно справедливо, ибо не барское это дело
) не озадачиваются. Ergo - на nat надейся, а "контролем состояния" не пренебрегай, как бы геморройно это ни было в том же ipfw . Впрочем, чрезмерно увлекаться подобным контролем тоже не стоит - записи в таблице состояний, записи в таблице nat'а, энное количество правил + два прохода трафика = потенциальная уязвимость к (D)DOS атакам. На мой взгляд, имеет смысл использовать контроль состояния на выходе из firewall'а, а на внутреннем интерфейсе можно применять классическую пакетную фильтрацию образца 80х годов... впрочем, по этому поводу я все еще думаю, ибо "совершенство приходит с опытом"
среда, 31 марта 2010
... ну или очередные грабли - это уж кому как . Как запрячь в одну упряжку осла и трепетную лань совместить в одном ipfw'шном ruleset'е stateful filtering и kernel nat написано в handbook'e. Чего там _не_ написано (Не удивлюсь, если оный sysctl появился уже _после_ выхода статьи, а "поправить" ни у кого руки не дошли) - sysctl net.inet.ip.fw.one_pass надо ставить в нуль, иначе работать пример не будет. Внимание, вопрос! Можно ли нафантазировать stateful ruleset с one_pass=1 и nat?
Ответ
. Как Ответ
вторник, 30 марта 2010
... хороших программистов, искренне недоумевающих, зачем всякие "быдлокодеры"(ТМ) пытаются натянуть контрацептив на глобус используют реляционные СУБД там, где надо и где не надо (Вот ей-ктулху, каждый раз вижу попытку запихнуть OpenLDAP в какой-нибудь MySQL -и не знаю, плакать, или смеяться), я плохой программист системный администратор подобными вопросами не задаюсь, ибо знаю ответ(ы) . Если кому интересно - SQL чуть ли не единственный распространенный декларативный язык программирования, более того, из всего "подмножества" известных мне языков, он является едва ли не самым "человеческим" (Знающий английский язык человек вполне способен _правильно_ понять конструкцию вида select <> from table <> where <>, даже не будучи знакомым с SQL)
Чего я НЕ знаю - так это нафига, ну нафига использовать в качестве рСУБД MySQL, а? Я бы понял, продолжай народ пихать embedded 4-ку, так ведь нет! База на две таблицы, apache с СУБД на одном компе через 127.0.0.1 общаются, а туда же - подавай им 5.1...
Вот чем им всем sqlite не нравится, а? Отличная производительность, достаточный для 995% проектов набор возможностей, практически полное отсутствие потребности в администрировании, встроенная поддержка во всех распространенных языках программирования и прочие "радости бытия", так ведь нет... Не-по-ни-ма-ю.
. Если кому интересно - SQL чуть ли не единственный Чего я НЕ знаю - так это нафига, ну нафига использовать в качестве рСУБД MySQL, а? Я бы понял, продолжай народ пихать embedded 4-ку, так ведь нет! База на две таблицы, apache с СУБД на одном компе через 127.0.0.1 общаются, а туда же - подавай им 5.1...
Вот чем им всем sqlite не нравится, а? Отличная производительность, достаточный для 9
понедельник, 29 марта 2010
... над "шайтанамой" в очередной раз не пришлось. Отдохнул, подумал, открыл исходники, подумал, закрыл исходники, подумал еще чуть-чуть, подвесил на модуль аутентификации SUID, проверил - работает! Этой зар-разе и впрямь не хватало прав на чтение /etc/master.passwd - аутентификация на удаленных серверах проходила "на ура" а локальная - таки ой ).
С одной стороны - "самдурак", мог бы и пораньше допереть, с другой - в рассчете на таких вот дураков можно было и какую-нибудь отладку прикрутить...
UPD А pam_group таки не заработал. От слова "совсем". Выкрутился при помощи родного winbind'ового require_membership_of='SID' и доменных групп. Вот правда лочить пользователя при помощи net rap groupmember delete <группа> <пользователь> -U <администратор> как-то очень уж... /не может подобрать слово/, а если учесть, что пароль этим net'ям мне удалось передать только с помощью expect...
Думаю нехорошее.
С одной стороны - "самдурак", мог бы и пораньше допереть, с другой - в рассчете на таких вот дураков можно было и какую-нибудь отладку прикрутить...
UPD А pam_group таки не заработал. От слова "совсем". Выкрутился при помощи родного winbind'ового require_membership_of='SID' и доменных групп. Вот правда лочить пользователя при помощи net rap groupmember delete <группа> <пользователь> -U <администратор> как-то очень уж... /не может подобрать слово/, а если учесть, что пароль этим net'ям мне удалось передать только с помощью expect...
Думаю нехорошее.
пятница, 26 марта 2010
При помощи кувалды напильника и божьей какой-то матери прикручиваю к проксюку аутентификацию. Номинально - все великолепно, проксюк поддерживает pam, но делает он это м-ммм... в общем, круче "английских ученых"(ТМ) "голландских программистов"(ТМ) могут быть только программисты японские. Из четырех функциональных классов (auth, account, passwd, session) поддерживается только auth да и с тем происходит нечто странное:
Требуется осуществить аутентификацию доменных пользователей, и предоставить части из них доступ в сеть интернет. Ок. Ставим samba'у с поддержкой AD, конфигуряем (Workgroup, REALM, password server, idmap'ы), джойним (net ads join -U <> -S <>), проверяем - wbinfo -u. Работает. Правим nsswitch.conf, проверяем через id <имя> - тоже работает.
Пишем pam'овский файл в одну строчку - auth required pam_winbind.so. Настраиваем проксюк. Проверяем через браузер. Работает.
Добавляем проверку принадлежности к группе - auth required pam_group.so group=internet. Создаем группу, добавляем в нее доменного пользователя, проверяем через браузер - не работает. Хм. Странно. На всякий случай явно ставим winbind enum users/groups в smb.conf - проверяем через getent group. Работает. Браузер - нихтЪ.
"Для упрощения ситуации" - плюем на доменных пользователей. Закидываем локального user'а в группу internet, меняем pam_winbind.so на pam_unix.so, проверяем - упс!
Гхм. Копируем pam'овский файл, например, в su. Проверяем. Как ни странно, su с этими настройками пашет. Копируем обратно, докидываем к unix.so опцию debug. Запускаем, смотрим в debug.log - видим даже не фигу, а вообще черте-что и с боку бантик: pam_winbind.so у которого опции 'debug' нет и не было исправно в логах гадил (Скомпилен так, похоже) а pam_unix.so молчит как кошка об забор, что уж совсем ни в какие ворота.
Многагуглю думаю.
Требуется осуществить аутентификацию доменных пользователей, и предоставить части из них доступ в сеть интернет. Ок. Ставим samba'у с поддержкой AD, конфигуряем (Workgroup, REALM, password server, idmap'ы), джойним (net ads join -U <> -S <>), проверяем - wbinfo -u. Работает. Правим nsswitch.conf, проверяем через id <имя> - тоже работает.
Пишем pam'овский файл в одну строчку - auth required pam_winbind.so. Настраиваем проксюк. Проверяем через браузер. Работает.
Добавляем проверку принадлежности к группе - auth required pam_group.so group=internet. Создаем группу, добавляем в нее доменного пользователя, проверяем через браузер - не работает. Хм. Странно. На всякий случай явно ставим winbind enum users/groups в smb.conf - проверяем через getent group. Работает. Браузер - нихтЪ.
"Для упрощения ситуации" - плюем на доменных пользователей. Закидываем локального user'а в группу internet, меняем pam_winbind.so на pam_unix.so, проверяем - упс!
Гхм. Копируем pam'овский файл, например, в su. Проверяем. Как ни странно, su с этими настройками пашет. Копируем обратно, докидываем к unix.so опцию debug. Запускаем, смотрим в debug.log - видим даже не фигу, а вообще черте-что и с боку бантик: pam_winbind.so у которого опции 'debug' нет и не было исправно в логах гадил (Скомпилен так, похоже) а pam_unix.so молчит как кошка об забор, что уж совсем ни в какие ворота.
Многа
четверг, 25 марта 2010
... к предкам. Всего-то две шестидневных недели (Вторая с двенадцатичасовым рабочим днем) и меня почитай, хоронить можно - а они так (Оу, нет! Не "так", далеко не "так"!) всю жизнь работали! Спасибо соввласти за 5*8, в общем ).
Оффтоп: кто-нибудь знает рецепты салатов с морской капустой? Самой "душманской", консервированной? "Что-нибудь" я, конечно, и сам "насооружаю", не впервой, но...
Оффтоп: кто-нибудь знает рецепты салатов с морской капустой? Самой "душманской", консервированной? "Что-нибудь" я, конечно, и сам "насооружаю", не впервой, но...
среда, 24 марта 2010
... без особого шума и пыли вышла FreeBSD 7_3. Читаю расширенные release notes и просто-таки душа радуется:
- Ну, изменения в ядре меня особо не колышат, хотя сетвой стек JAIL'ов... впрочем, за этим в 8-ку ). Пофисенный баг планировщика радует, но оно и так патчилось
- boot loader с поддержкой zfs - м-ммм... для меня не шибко актуально, но все равно - "спасибо" )
- из hw support'а заинтересовал только пофикшенный баг ipmi и то "теоретически"
- в network'е интересного чуть побольше - починили TCP segmentation offloading в fxp-драйвере, и! (Не успел пожаловаться, ага!) пофиксили багу с whatchdog timeout'ом для xl
- запузырили поддержку vlan в GENERIC-ядро, нарисовали rc-скрипты - давно пора, ага
- пофиксили охапку багов ata-драйвера
- изменили механизм балансировки gmirror'а (Будем почитать, да-ссс)
- всякая мелочь - utf-8 в man'ах, квалификаторы размера в fdisk'е (Алилуйя! Аллилуйя! Аллиллуйя!), прикрутили аутентификацию к fetch'у и прочее разное.
Ня! Буду обновляться )
- Ну, изменения в ядре меня особо не колышат, хотя сетвой стек JAIL'ов... впрочем, за этим в 8-ку ). Пофисенный баг планировщика радует, но оно и так патчилось
- boot loader с поддержкой zfs - м-ммм... для меня не шибко актуально, но все равно - "спасибо" )
- из hw support'а заинтересовал только пофикшенный баг ipmi и то "теоретически"
- в network'е интересного чуть побольше - починили TCP segmentation offloading в fxp-драйвере, и! (Не успел пожаловаться, ага!) пофиксили багу с whatchdog timeout'ом для xl
- запузырили поддержку vlan в GENERIC-ядро, нарисовали rc-скрипты - давно пора, ага
- пофиксили охапку багов ata-драйвера
- изменили механизм балансировки gmirror'а (Будем почитать, да-ссс)
- всякая мелочь - utf-8 в man'ах, квалификаторы размера в fdisk'е (Алилуйя! Аллилуйя! Аллиллуйя!), прикрутили аутентификацию к fetch'у и прочее разное.
Ня! Буду обновляться )
... на "скучность" "установочных" лекций? Пфе! Оказывается, это были так, "цветочки" - "ягодки" - это "Нормативно-правовая база обеспечения технической защиты информации"(Ц). Десять часов. Бедный мой моск!