В номере редактор английской версии


Анатомия компрометации FreeBSD (часть 1-я)



Pdf просмотр
страница6/7
Дата19.11.2016
Размер4.58 Mb.
Просмотров1857
Скачиваний0
1   2   3   4   5   6   7
Анатомия компрометации FreeBSD (часть 1-я)
www.bsdmag.org
43
также схемы локальной сети с IP-адресами на столе и паролями, прилепленными к мониторам. Если вы всех доверяете у себя в компании — это просто замечательно, но чем больше людей работает, тем сложнее становится доверять каждому. Однажды меня чуть физически не избил один менеджер, когда я отказался ему дать администраторские пароли на несколько серверов, несмотря на то, что ему был предложен неограниченный доступ к нужным ему ресурсам, но под его личной учетной записью.
Это не прошло даром, и в конце обнаружилось, что он скачивает пиратский софт с каких-то странных мест. Давайте людям доступ к системам только предварительно выяснив «зачем иименно?», и если есть подозрение отвечайте отказом. Если действительно потребуется, уточняйте с более старшим менеджером, но по умолчанию, решение должно быть таким.
Следующая категория относится к «внешнему миру». Существуют разные типы хакеров с самыми различными намерениями (см. Таблицу 4). Я разбил их на различные категории, т.к. для разных атак нужны свои инструменты, уровни компрометации и т.п. В действительности же, есть только «хорошие парни» и «плохие парни», однако я пытаюсь сказать здесь следующее — степень нежелательности всех атак находится под тем или иным вопросом, однако самое важное — степень серьезности атаки. С «детскими» атаками проще работать (конечно, при условии, что не были заменены пароли и данные не стерли), в то время как с тяжелыми и серьезными атаками на вашу организацию, устроенную конкурентом или политической силой, с целью вытащить секреты, будет подпадать под совершенно другую категорию.
Кому-то придется переустанавливать сервер, другим же потребуется вовлечь специальные структуры и провести полный аудит. Грустно это признавать, но для индивидуального предпринимателя или малого бизнеса в этом вопросе нет практически никакой пользы от спецслужб. Вот представьте себе картину
— вы приходите в милицию заявить о том, что вы пострадали от вируса типа «Мелисса». Обратят ли на вас внимание? А если вы большая компания, или связана политически с какой-то партией, или же являетесь правительственным агенством — шансы быть услышанным вырастают в разы (см. инцидент с
EDF Greenpeace в Табл.3).
Большинство организаций относятся к попыткам взлома как — «Это не наша проблема». Совсем недавно пришло подложное письмо от одного крупного банка — я заинтересовался, а сам поддельный сайт, на который ссылается письмо, всё еще работает?
К моему удивлению, оказалось, что да. Будучи примерным сетевым гражданином, я обратился в службу поддержки банка. На что мне ответили, что у них нет специалиста по безопасности, работающего по выходным. Интернет-провайдеры и интернет-бизнесы
— также отдельная история. Я уже забыл количество моих обращений к ним по поводу спама и вредоносных электронных писем идущих с их адресов. Обычный их ответ — «И что?». Поэтому здесь больше поднимается не аспект безопасности, а больше вопрос репутации компании.
Адаптируемся к ментальному подходу
«Администратор, нацеленный на
безопасность»
Я привел 10 заповедей как для стороны администраторов, так и для хакеров (см. Табл. 1 и
Табл. 2), т.к. важно знать, как думает другая сторона.
Таблица 3. Ссылки
Название
Сайт
ФБР поместило бэкдор в OpenBSD
http://www.theregister.co.uk/2010/12/15/openbsd_backdoor_claim
На фирму EDF наложен штраф за взламывание компьютеров Greenpeace http://www.ft.com/cms/s/0/78f3b452-0c70-11e1-8ac6-00144feabdc0.html
Подмена шелл-оболочки после взлома http://www.madirish.net/node/237
MUH
http://muh.sourceforge.net/
Process faker http://packetstormsecurity.org/search/files/?q=process%20faker
Metasploit framework http://metasploit.com
Wireshark http://www.wireshark.org
Nmap http://nmap.org
Backtrack Linux http://www.backtrack-linux.org

12/2011 44
БЕЗОПАСНОСТЬ
Самим большим врагом является собственное самодовольство. Как я это выяснил с одной своей старой системой на базе FreeBSD 6.1, и которая была взломана. Она была подключена к интернету и были проведены длительные мероприятия по защите ее с помощью файрвола, программ по проникновению, прежде чем она была сдана в реальную эксплуатацию.
Т.к. сервер достаточно старый и использовался больше как прокси и шлюз для почты, я решил не обновлять его вручную, а дождаться выхода FreeBSD 8 и заодно обновить «железо». Внутренний голос говорил мне, что я напрашиваюсь на неприятности, особенно при использовании стандартного Apache 1.3, но на нем никакие сайты не размещались, кроме стандартной страницы. Я также был загипнотизирован мантрой
«Пока работает — не трожь», т.к. бесперебойная работа сервера была важна. Я также знал, что моя почтовая подсистема находится в безопасном состоянии
(отправка и получение почты непосредственно провайдеру, на конкретный IP-адрес), и имеется только один непривилегированный аккаунт к SSH, к тому же последний слушал на нестандартном порту, а у аккаунта был сложный пароль. Сервер периодически сканировался на наличие руткитов и т.п., а сам IP- адрес, выданный провайдером, был динамическим.
Я проверял те запросы, что отправляются на веб- сервер, запрашивая несуществующие страницы, но выяснял со всей дотошностью из-за ограниченности во времени, и потому, что не было видно явно заданного образца в таких запросах. С прицелом на будущее, мне надо было добавить скрипты в систему, которые автоматически блокировали бы те IP-адреса, что запрашивают несуществующие страницы.
Несколько недель назад я начал испытывать проблемы с моим широкополосным подключением, и через некоторое роутер совсем перестал работать.
Он был выдан моим провайдером, поэтому я не мог его обновить. В итоге я заменил его на резервный и проверяя его работу, через команду netstat обнаружил незапланированный трафик на IRC-сервер в Венгрии.
Т.к. мои родные были подключены к интернету, то я не особенно этим озаботился. Но потом проверил внутреннюю сеть и ... соединение было установлено не
Таблица 4. Причины, из-за которых взламывают
Тип хакера
Стиль поведения (Modus Operandi)
Этический хакер в «белой шляпе»
Входит в системы просто для развлечения/обучения. Разрушений не наносит.
Системный администратор и автор программы уведомляется в частном порядке о найденной уязвимости. Может рассказать об эксплойте в широкой печати, если видит, что к угрозе относятся спустя пальцы.
«Детский» атакующий
Скачивает эксплойты из сети и запускает их над публичными или частными серверами.
Действует ради самоутверждения, и не заботится о рисках своего обнаружения
(например, о раскрытии IP-адреса) и рисках атакуемых систем. Обычно атаки выглядят как DoS — Denial of Service (т.к. перегружает сервер пустыми запросами).
Обычные хакеры и спамеры
Потенциально связаны с преступным миром. Хотят заполучить максимальное количество машин, насколько это возможно, т.к. их быстро раскрывают. Используют многовекторную атаку, начиная с вредоносного письма и заканчивая подменой сайтов и их компрометация. Заинтересованы во многих деяниях — от сбора адресов электронной почты и номеров кредиток, до атак типа DoS. Большинство атак может быть ограничено за счет общей концепции безопасности, не связанной с эксплойтами вида 0day.
Ворующие трафик
Используют системы в качестве устройств для атак вида «человек-в-середине».
Либо же для прикрытия незаконной деятельности. Количество увеличивается за счет развития беспроводной сети WiFi / Bluetooth. Сетевой эквивалент телефонного фрикинга.
Хакер в «черной шляпе»
Хочет получить доступ к специфическим коммерческим или личным секретам, паролям, чтобы умышленно нанести вред системе / данным. Отслеживает определенную жертву. Профессиональный уровень эксплойта, будет задействовать любой или все возможные векторы атак для получения преимущества (например, вредоносные письма / кейлоггеры / социальный инжиниринг / скрыток наблюдение
/ сетевые сниферы / телефонная прослушка и т.д.). Не нужно путать с обычными хакерами, которые работают на объем — здесь целенаправленная атака. Пример — червь Stuxnet.

Анатомия компрометации FreeBSD (часть 1-я)
www.bsdmag.org
45
оттуда. Изолировав сервер, я проверил на наличие все необычные процессы командами ps и top. Оказалось, что всё пусто. Моим следующим шагом был запуск tcpdump и выяснилось любопытное. Трафик был только исходящим, уходил раз в минуту. Зацепку дала команда lsof, т.к. оказались неизвестные открытые файлы в директории /tmp, с правами www-data. А у меня на сервере не было какой-либо страницы, что писала бы файлы. Действительно, оказалось, что было проведено muh-инфицирование и активность скрыта с помощью Process Faker. Хакер запустил процесс, который запускал IRC-сервер с правами веб-сервера.
А для надежности, поместил запуск этого процесса в crontab, чтобы при перезагрузке машины ничего не изменилось. В виду того, что владелец файлов был www-data, стало ясно, что Apache — это слабое звено в цепочке. А сам доступ был получен через порт 80, возможно через POST-команду и подмену шелл- оболочки. В целом, крайне запутанный хак. К счастью, судя по логам, хакеру не удалось удачно подключиться к IRC-серверу, и никакие данные не потерялись.
Удаление записи из crontab, а также файлов из /tmp, разрешило проблему — сервер нормально работает.
Apache же я отключил до перехода на новую систему.
В конце этого анализа, и чтобы подчеркнуть 4-ю заповедь (Табл. 1) — процитирую Catherine Aird. «Если вы не можете быть хорошим примером, тогда вам придется выступать серьезным предупреждением для остальных». Надеюсь, мой опыт окажется полезным для всех.
В следующих выпусках
Мы рассмотрим на эффективные стратегии по улучшению безопасности, а также на сами инструменты, включая сниферы пакетов и сканеры портов, ловушки, а также на правила файрвола, которые помогут ограничить атаки на Apache. Мы также рассмотрим некоторые инструменты проверки на уязвимость, на проникновение и попробуем воссоздать muh-атаку на тестовый сервер. Посмотрите на Табл. 3, в которой перечислены более-менее известные утилиты.
Специальная справка
Информация, приведенная в этих статьях, предназначена для системных администраторов, чтобы помочь им в улучшении своей безопасности.
Тестирование и обнаружение уязвимостей на своих собственных персональных площадках абсолютно легально в Великобритании, но в других частях света законодательство можеть быть иным. Работодатели могут наложить дисциплинарное взыскание, либо же провести юридические действия против своих сотрудников, если такие инструменты будут использованы в рабочей обстановке без разрешения.
Используя же их против третьей стороны без разрешения, не только считается неэтичным, но и противозаконно во многих странах. Автор и журнал не оправдывают неэтический или нелегальный хакинг.
Об авторе
Rob Sommerville неравнодушно относился к технологиям с детства. Ярый сторонник открытых систем с середины восьмидесятых, он проработал во многих корпоративных секторах, включая финансовый, автомобильный, авиаиндустрии, правительственный и
СМИ. Был во множестве ролей - начиная от технической службы поддержки, системного администратора, разработчика и заканчивая системным интегратором и
IT-менеджером. Вышел из мира CP/M и газоразрядных ламп, однако хранит паяльник под рукой, на всякий случай.

12/2011 46
БЕЗОПАСНОСТЬ
Укрепляем BSD
По умолчанию, серверы BSD являются более защищенными, нежели другие операционные системы. Но они, однако, требуют небольших изменений, чтобы быть переведенными в промышленную эксплуатацию.
с помощью уровней безопасности
Вы узнаете…
• Как настраивать уровень безопасности на операционных системах класса BSD.
• Как использовать chflags для разблокирования конфигурации системы и лог-файлов.
О чем вы должны знать…
• Об основные приемах при работе в командной строке BSD.
• Основах работы sysctl.
У
ровни безопасности — это один из тех инструментов, что может быть использован для поддержания состояния системы на должной отметке.
В этой статье раскрывается как сконфигурировать уровни безопасности посредством securelevel для
OpenBSD, FreeBSD, NetBSD и DragonFlyBSD.
Назначение функции уровня безопасности заключается в ограничении возможностей ядра, в зависимости от выбираемого уровня. По умолчанию, полная функциональность во все BSD-ядра включена, включая возможность производить изменения на этапе старта системы. Изменения проводятся в соответствии с настройками в файле rc.conf. Уровень безопасности может быть повышен в работающей системе, но понизить получится только из однопользовательского режима, либо перезагрузившись. Во FreeBSD, очевидно, опция REGRESSION вкомпилирована в ядро, так, чтобы можно было задействовать значение sysctl для понижения уровня безопасности.
Настройки этого уровня совпадают практически для всего семейства BSD. В Листинге 1 приведены начальные значения для каждой операционной системы: FreeBSD 8.2, OpenBSD 5.0, NetBSD 5.1,
DragonFlyBSD 2.10.
Самой отличительной системой является Open-
BSD, в которой уровень безопасности по умолчанию равен 1. Другие же три системы находятся по умолчанию в незащищенном режиме. В OpenBSD и
NetBSD применяются одинаковые настройки, также как и в паре FreeBSD / DragonFlyBSD. На уровне со значением -1, все устройства/файлы/память можно читать и писать в них. Как указывается в man-справке, эти настройки во FreeBSD, NetBSD и DragonFlyB-
SD должны быть изменены на нужные. Файловые свойства могут быть усилены с помощью утилиты
Листинг 1. Следующие значения
используются при старте каждой
системы.
FreeBSD 8.2
kern.securelevel: -1
OpenBSD 5.0
kern.securelevel=1
NetBSD 5.1
kern.securelevel = -1
DragonFlyBSD 2.10
kern.securelevel: -1

Укрепляем BSD с помощью уровней безопасности
www.bsdmag.org
47
chflags, как проиллюстрировано в Листинге 2.
Уровень безопасности может быть повышен за счет обновления с помощью утилиты sysctl значения для переменной kern.securelevel, как показано в Листинге
3.
Вывод команды chflags для систем For FreeBSD, Net-
BSD и DragonFlyBSD, которые находятся на первом уровне безопасности, аналогичен ситуации с Open-
BSD, т.е. когда она уже находится на стандартном для нее первом уровне. Применение флага schg для конфигурационных файлов, позволяет заблокировать их изменение, и тем самым сохранить целостность системы. Такую же операцию можно произвести и над лог-файлами. Во FreeBSD и DragonFlyBSD можно ограничить загрузку и выгрузку из памяти модулей ядра. Это повлияет на работу утилит kldload и kldun- load.
Другой важной стороной является то, как реализованы уровны безопасности внутри jail- контейнеров FreeBSD. Контейнер внутри может использовать более высокое значение, даже если сам хост использует более низкое. Данная особенность позволяет хосту искусно манипулировать нужными файлами даже находящими внутри jail-контейнера.
Листинг 2. Следующие значения используются при старте каждой системы.
Следующие команды применяются в семействе систем BSD для выставления флагов
sappnd и schg (соответственно, «system append-only» и «system immutable»). Обратите
внимание, как на этом фоне выделяется OpenBSD — она не позволяет изменить эти
флаги, т.к. по умолчанию находится на первом безопасном уровне.
Выставляем флаги schg и sappnd в системах FreeBSD,
NetBSD и DragonFlyBSD
freebsd# ls test.conf freebsd# chflags schg test.conf freebsd# ls -lo total 2
-rw-r----- 1 root wheel schg 22 Nov 16 12:00 test.
conf freebd# rm -rf test.conf rm: test.conf: Operation not permitted freebsd# chflags noschg test.conf freebsd# rm -rf test.conf freebsd# ls freebsd# freebsd# echo “LogEntry: Test” >> test.log freebsd# wc -l test.log
1 test.log freebsd# chflags sappnd test.log freebsd# ls -lo total 2
-rw-r--r-- 1 root wheel sappnd 15 Nov 16 12:24 test.
log freebsd# echo “LogEntry: Test” >> test.log freebsd# wc -l test.log
2 test.log freebsd# rm -rf test.log rm: test.log: Operation not permitted freebsd# chflags nosappnd test.log freebsd# rm -rf test.log freebsd# ls freebsd#
Работаем с флагами schg и sappnd в OpenBSD
# ls test.conf
# chflags schg test.conf
# ls -lo total 4
-rw-r--r-- 1 root wheel schg 11 Nov 16 11:23 test.
conf
# rm -rf test.conf rm: test.conf: Operation not permitted
# chflags noschg test.conf chflags: test.conf: Operation not permitted
# echo “LogEntry: Test” >> test.log
# wc -l test.log
1 test.log
# chflags sappnd test.log
# echo “LogEntry: Test” >> test.log
# wc -l test.log
2 test.log
# rm -rf test.log rm: test.log: Operation not permitted
# chflags nosappnd test.log chflags: test.log: Operation not permitted

12/2011 48
БЕЗОПАСНОСТЬ
Другой отличительной особенностью в операционных системах семейства BSD является максимальный уровень безопасности. Во FreeBSD и
DragonFlyBSD используется максимальное значение
3, что по функционалу равно второму уровню в
OpenBSD и NetBSD. Разница заключается в разном формате работы с сетевыми настройками, которые используются в OpenBSD и NetBSD на уровне 2, но не используются во FreeBSD/DragonFlyBSD. Для последних, этот фунционал располагается в третьем уровне.
Второй уровень безопасности препятствует переводу времени часов назад, или же увеличению более, чем на одну секунду вперед. Такая настройка, будучи применена вместе с флагом sappnd, позволяет вести лог-файлы не только в полной сохранности, но и быть абсолютно точными с тем временем, когда туда добавлялись новые записи событий. На третьем уровне безопасности (равному уровня 2 в отношении OpenBSD/NetBSD) уже правила файрвола нельзя будет изменить. Системный уровень нужно будет понизить, презде чем внести изменения в операционную систему. Примерный вывод команд для
OpenBSD приведен в Листинге 4.
Хотя эти функции действительно очень помогают заблокировать операционную систему на модификацию, они должны быть хорошо изучены и поняты прежде, чем вы отправите систему в реальную эксплуатацию. В книге по FreeBSD в разделе, посвященном безопасности, отмечается, что системные файлы перед загрузкой должны быть защищены — тогда применение различных уровней безопасности будет эффективным. Если же атакующий способен запустить какой-либо свой код, прежде чем уровень выставлен, то защиту можно будет обойти. Помимо этого, надо учитывать, что для обновления системы придется или же переходить в однопользовательский режим, либо выводить ее полностью из работы.
Как и любой другой инструмент безопасности, настройка уровня безопасности само по себе не является решением. Он просто предоставляет механизм поддерживания целостности работающей операционной системы. Существует ряд других, более гибких, вариантов ограничения доступа к файлам.
Например, контрольные листы доступа (access con- trol lists — ACL) и мандатный контроль доступа
(mandatory access controls — MAC). Задействуя все доступные инструменты в BSD-системах, можно содержать серверы в крайне защищенном состоянии, и на протяжении всего срока эксплуатации держать в том виде, в котором они были настроены в самом начале.
Об авторе
Michael Shirk — фанатик BSD, который работает с OpenBSD и FreeBSD более 6 лет. Он работает в сообществе безопасности и занимается поддержкой открытых продуктов по безопасности, которые работают на операционных системах семейства BSD.
В сети

FreeBSD man page for securelevel:
• http://www.freebsd.org/cgi/man.cgi?query=security&sektion=7&apropos=0&manpath=FreeBSD+8.2-RELEASE

FreeBSD Handbook warning on securelevels:
• http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL

OpenBSD man page for securelevel:
• http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel&sektion=7

NetBSD man page for securelevel:
• http://netbsd.gw.com/cgi-bin/man-cgi?secmodel_securelevel+9+NetBSD-current

DragonFlyBSD man page for securelevel:
• http://leaf.dragonflybsd.org/cgi/web-man?command=securelevel§ion=ANY

12/2011 50
ПОГОВОРИМ
Новости
Организация FreeBSD Foundation — это некоммерческая фирма, работающая на основании положения 501(c)(3) закона о доходах
США. Её цель — поддержка проекта FreeBSD, а также построение сообщества по всему миру. Она ответственна за исполнение контрактов, лицензионных соглашений, авторских прав и других законных мер, для которых требуется наличие юридического лица.
от FreeBSD Foundation
О
рганизация финансирует и управляет проектами, спонсирует различные мероприятия и саммиты разработчиков, связанные с Free-
BSD. Для разработчиков предоставляет гранты для поездок на эти саммиты, и которые иначе не могут приехать за собственный счет.
В этой статье суммируются все конференции и проекты, которые были проспонсированы
FreeBSD Foundation в 2011 году. В заключении, вы можете узнать как вы лично можете помочь фонду.
Конференции, спонсорство для поездок и
стенды на конференциях
В 2011 году Фонд спонсировал следующие BSD конференции:
• AsiaBSDCon, проводилась в Токио (Япония) с 17 по 20 марта
• BSDCan и саммит разработчиков, проводился в
Оттаве (Канада) с 11 по 14 мая
• KyivBSD, проводилась в Киеве (Украина) 24 сентября
• EuroBSDCon и саммит разработчков, проводился в Маарсене (Нидерланды) с 6 по 9 октября
• Саммит поставщиков FreeBSD, проводился в
Санта-Кларе (США) с 3 по 4 ноября
В дополнение к указанных конференциям, Фонд оплатил разработчикам проезд на следующие мероприятия:
FOSDEM: один разработчик
BSDCan: 6 разработчиков
EuroBSDCon: 6 разработчкиов
GSoC Mentor Summit: один разработчик

Новости от FreeBSD Foundation
www.bsdmag.org
51
Каждый спонсируемый, по окончании поездки, предоставляет отчет. В котором отражает, какую информацию он получил от поездки. Эти отчеты доступны на блоге Фонда:
http://freebsdfoundation.blogspot.com/.
Дирекция FreeBSD Foundation также на добровольных началах участвует в работе стендов FreeBSD, места для которых выделяют организаторы выставок.
Посещая эти мероприятия, можно обменяться ценными идеями по дальнейшему развитию проекта, а также оплатить работу Фонда. По крайнем мере один директор присутствовал в стендовой работе на конференциях:
FOSDEM — Брюссель (Бельгия), с 5 по 6 февраля
SCALE — Лос-Анджелес (США), 26 февраля
AsiaBSDCon — Токио (Япония), с 17 по 20 марта
Indiana LinuxFest — Индианаполис (США), 26 марта
FlourishConf — Чикаго (США), 2 апреля
BSDCan — Оттава (Канада), с 13 по 14 мая
SouthEast LinuxFest — Спартанбург (США), 11 июня
Ohio LinuxFest — Коламбус (США), 10 сентября
EuroBSDCon — Маарсен (Нидерланды), с 8 по 9 октября
LISA — Бостон (США), с 7 по 8 декабря
На следующий, 2012 год, запланировано участие представителей Фонда в следующих стендах:
SCALE — Лос-Анджелес (США), 21 января
NorthEast LinuxFest — Вустер (США), 17 марта
Indiana LinuxFest — Индианаполис (США), 14 апреля
BSDCan — Оттава (Канада), с 11 по 12 мая
Также ожидается, что стенды FreeBSD будут организованы и на других конференциях, которые посещались в 2011 году, сразу после назначения конкретных дат и расположений.
Финансируемые проекты разработчиков
В 2011 году Фонд запланировал потратить 125 тыс. долларов для финансирования работ. Работы на 85 тыс. долларов уже завершены, а еще 2 дополнительных проекта рассматриваются для назначения им остатка бюджета этого года. Следующие проекты достигли финала:
Поддержка IPv6 во FreeBSD и PC-BSD
Bjoern Zeeb — обладатель награды Itojun Ser- vice Award, выданную ему за работу по открытой реализации IPv6, был удостоин гранта для улучшения поддержки IPv6 в FreeBSD и PC-BSD. Этот проект был совместно профинансирован с компанией iXsys- tems — корпоративным спонсором проекта PC-BSD.
Оригинальная разработка во FreeBSD по поддержке
IPv6 (на базе кода проекта KAME) впервые появилась в версии FreeBSD 4.0 и распространена во многих коммерческих продуктах, основанных на кодовой базе FreeBSD. Перед началом проекта этого года, реализация IPv6 в стандартном коде ядра FreeBSD была опциональной. Однако, она также требовала наличия IPv4. Те прикладные программы, которые декларировались как годные к «IPv6» и работали поверх двойного стека, могли, на самом деле, некорректно работать с протоколом IPv6. Благодаря этому проекту в ядро FreeBSD и PC-BSD добавлена раздельная поддержка протоколов. И теперь эти системы можно рассматривать как идеальную площадку для тестирования как открытых, так и закрытых IPv6-программных продуктов.
Проект был завершен в свой срок, поэтому и FreeB-
SD, и PC-BSD смогли принять участие в мероприятии
— Всемирный день IPv6, 8 июня. Доступны к загрузке версии систем с поддержкой только IPv6: FreeBSD
(http://www.freebsd.org/ipv6/) и (http://pcbsd.org/IPv6).



Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал