Закрытые порты = безопасная система?

у вас нет админа, у вас тупой эникей

Наш админ на работе утверждает, что можно держать даже непропатченную систему

если оставить только самые нужные порты (80 и пр.)

Да-да. всякие уязвимости ssl безобидны, если держать открытым только 443 порт.

Линус Торвальдс считает самой безопасной ту ОС, которая отключена от сети

Нет сети — нет некоторого пласта проблем, да.

открываем https://www.owasp.org/index.php/Top_10_2013-Top_10

видим на первых местах атаки, использующие уязвимости в ПО, и только на 5м месте Security misconfiguration и только на 9м - устаревшие версии ПО. вывод - не пускайте говнокодеров на продакшн и будет вам счастье

Пользуюсь огромным количеством неподдерживаемых систем: Ubuntu 7.04, Debian 5, SUSE 10.1, Opensuse 10.2, Opensuse 11.4. Вирусов не проникает.

Ну, понятно, что непропатченный софт, рвущийся в интернет, представляет собой угрозу. Предполагаем, что интернет используют современный пропатченный браузер типа dwb/qupzilla/konqueror (или elinks без поддержки JavaScript, идущий в дистрибутиве), также пропатченный Thunderbird и самописные проги на Python3.

а, так ты про клиентскую машину? в любом случае

самописные проги на Python3

закапывай. там говнокод, поди, с дыркой на дырке (были бы у вас нормальные кодеры, вопросов не было бы таких)

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

современный пропатченный браузер типа dwb/qupzilla/konqueror

ты или клоун, или тупой)

Я про свою машину. Обновления регулярно ломают систему. На днях поставили интернет от Ростелеком с паролем, который нормально поддерживается либо в убунту (которая слишком медленно у меня ворочается), либо в старых версиях Debian. В последнем стабильном Debian, ряде дистрибутивов таких как lubuntu, стоит бажный network-manager, который не дает нормально сконфигурировать интернет («Creating object for path '/org/freedesktop/NetworkManager/...' failed in libnm-glib...» или другие сообщения). LiveCD с Debian просто не загружается. Помимо всего прочего, теперь не читаются SD-карта и не подключается смартфон на Android. Все это работало в Wheezy. Вот такие вот дела. Либо красноглазь без гарантированного результата (похоже ж на баг), либо ставь убунту со всеми вытекающими (в т.ч. и тормозами), либо ищи другой диструбутив с работающим интернетом и карточками, либо возвращай старый дистрибутив, где все это работало.

В GUI-браузерах я захожу только на пару сайтов, где SSL не требуется.

Если я всё верно понимаю, то ситуация следующая.
Вот есть некий циклический процесс, который, в том числе, работает с сетевым адаптером. То есть, сколько-то там раз в секунду этот процесс проверяет поступили ли в адаптер данные и сам шлёт данные через этот адаптер. Для процесса на этапе получения это тупо куча байт, никаких «портов» и прочего там нет. Для процесса на данном этапе, в смысле. Если чего-то пришло - эти данные перекладываются в очередь на обработку. И вот тогда уже проявляются порты/протоколы и прочее. По сути, «открытый» порт или «закрытый» означает тупо определенное действие. Принять в дальнейшую работу или отбросить. Обычно такой процесс является частью ядра ОС. Так вот, к чему я это. На любом этапе этого процесса может случиться так, что некая полученная последовательность будет обработана неправильно. С непредсказуемыми результатами. Потому что, как правило, вся обработка сводится к списку сравнений. Если совпадает с этим, то делать то. Если с тем - то делать это. Грубо говоря, ряд if then. Ошибка обработки и называется уязвимостью. Если я всё верно понимаю, конечно. Так вот, суть обновления состоит в ликвидировании вот таких нештатных срабатываний.
Если я верно понимаю, то совершенно пофиг, закрыт там порт или открыт. Ядро один хрен эти данные через себя пропускает. Просто в случае «закрытого порта» данные дальше механизма ядра не уходят.

В продолжение темы, которую уже нельзя пополнять. Наш админ на работе утверждает, что можно держать даже непропатченную систему, если оставить только самые нужные порты (80 и пр.). Звучит здраво, ведь самая большая опасность идет из интернета. Это так? Что, даже ОффтопикXP получает новую жизнь?

Ну если нет известных багов в программах, которые висят на открытых портах и в коде ядра, которое отвечает за блокировку закрытых портов, можно, конечно. Вообще уязвимостей с remote code execution, когда тупо посылают пакет и на удаленном конце система в типичном сетапе взламывается, в истории было довольно мало.

Ну, понятно, что непропатченный софт, рвущийся в интернет, представляет собой угрозу.

веб-сервер сам в интернет обычно не лезет. И плевать что там клиенты используют. Например, вот тебе списочек: http://httpd.apache.org/security/vulnerabilities_22.html

Бекдоры и с закрытыми портами вполне существуют...

CVE-2014-2523 существовала с 2.6.26, но была исправлена только в конце марта 2014 года. Ты точно уверен в свой безопасности?

Да я бы заметил, если бы меня хакнули.

Все так говорят, пока их не хакнут...

Я не совсем понял... Вы говорите о серверных машинах или о клиентских?

Если серверные - тут все просто. 80ый - перехватываем пакеты, 443 - дырки в ssl. Всякие xss. Короче, идеальная безопасность.

Если клиентские... Ну вот возьмите симметричный NAT. С точки зрения внешнего мира он выглядит, как все порты закрытые. Но народ как-то умудряется ловить всякие скринлокеры и прочую ахинею.

Закрытые порты - необходимый минимум, но явно не панацея.

Я смотрю, ты из Питера... У вас там случайно эрзент не завелся?

DCCP
Ты точно уверен в свой безопасности?

Абсолютно.

Клиентский десктоп, в частности, мой персональный локалхост (вероятность локера весьма низкая).

Я в реале из лоровцев никого не знаю.

В последнем стабильном Debian, ряде дистрибутивов таких как
lubuntu, стоит бажный network-manager

Что, там пакет ppp убили ? Что-то не верится.

Если есть доступ во внешнюю сеть, значит есть обмен данными с внешним миром (кэп). Если происходит обмен данными с внешним миром - есть угроза безопасности (кэп).

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

/usr/lib64/libvorbisenc.so.2.0.10
/usr/lib64/libFLAC.so.8.3.0
/usr/lib64/liblz4.so.1.3.0
/usr/lib64/libasyncns.so.0.3.1
/usr/lib64/libsndfile.so.1.0.25
/lib64/libwrap.so.0.7.6
/usr/lib64/libXtst.so.6.1.0
/usr/lib64/libjson-c.so.2.0.1
/usr/lib64/pulseaudio/libpulsecommon-6.0.so
/usr/lib64/libpulse.so.0.18.0
/usr/lib64/libcanberra-0.30/libcanberra-pulse.so
/usr/lib64/libXinerama.so.1.0.0
/usr/lib64/libXss.so.1.0.0
/usr/lib64/libnssckbi.so
/usr/lib64/libfreebl3.so
/usr/lib64/libnssdbm3.so
/usr/lib64/libsqlite3.so.0.8.6
/usr/lib64/libsoftokn3.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
/usr/lib64/gio/modules/libdconfsettings.so
/lib64/libattr.so.1.1.0
/lib64/libcap.so.2.24
/usr/lib64/gio/modules/libgvfsdbus.so
/usr/lib64/gvfs/libgvfscommon.so
/usr/lib64/gio/modules/libgioremote-volume-monitor.so
/usr/lib64/libsystemd.so.0.5.1
/usr/lib64/pango/1.8.0/modules/pango-basic-fc.so
/usr/lib64/firefox/browser/components/libbrowsercomps.so
/usr/lib64/libudev.so.1.6.2
/usr/lib64/firefox/components/libmozgnome.so
/usr/lib64/firefox/components/libdbusservice.so
/lib64/libnss_dns-2.20.so
/lib64/libnss_files-2.20.so
/lib64/libnss_nis-2.20.so
/lib64/libnsl-2.20.so
/lib64/libnss_compat-2.20.so
/usr/lib64/libgpg-error.so.0.15.0
/usr/lib64/libORBitCosNaming-2.so.0.1.0
/usr/lib64/libgcrypt.so.20.0.3
/lib64/libutil-2.20.so
/usr/lib64/libcrypto.so.1.0.0
/usr/lib64/libssl.so.1.0.0
/usr/lib64/libgailutil.so.18.0.1
/usr/lib64/libpopt.so.0.0.0
/usr/lib64/libxml2.so.2.9.2
/usr/lib64/libORBit-2.so.0.1.0
/usr/lib64/libbonobo-activation.so.4.0.0
/usr/lib64/libbonobo-2.so.0.0.0
/usr/lib64/libgnome-keyring.so.0.2.0
/usr/lib64/libgconf-2.so.4.1.5
/usr/lib64/libgnomevfs-2.so.0.2400.4
/usr/lib64/libgnome-2.so.0.3200.1
/usr/lib64/libart_lgpl_2.so.2.3.21
/usr/lib64/libgnomecanvas-2.so.0.3000.3
/usr/lib64/libbonoboui-2.so.0.0.0
/usr/lib64/libgnomeui-2.so.0.2400.5
/usr/lib64/gtk-2.0/2.10.0/engines/libadwaita.so
/usr/lib64/gtk-2.0/2.10.0/engines/libpixmap.so
/usr/lib64/libogg.so.0.8.1
/usr/lib64/libvorbis.so.0.4.7
/usr/lib64/libltdl.so.7.3.1
/usr/lib64/libvorbisfile.so.3.3.6
/usr/lib64/libcanberra.so.0.2.5
/usr/lib64/libcanberra-gtk.so.0.1.9
/usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so
/usr/lib64/gconv/UTF-16.so
/usr/lib64/libgraphite2.so.3.0.1
/lib64/libuuid.so.1.3.0
/usr/lib64/libXxf86vm.so.1.0.0
/usr/lib64/libxshmfence.so.1.0.0
/usr/lib64/libxcb-sync.so.1.0.0
/usr/lib64/libxcb-randr.so.0.1.0
/usr/lib64/libxcb-present.so.0.0.0
/usr/lib64/libxcb-dri3.so.0.0.0
/usr/lib64/libxcb-glx.so.0.0.0
/usr/lib64/libXdmcp.so.6.0.0
/usr/lib64/libXau.so.6.0.0
/usr/lib64/libdrm.so.2.4.0
/usr/lib64/libglapi.so.0.0.0
/usr/lib64/libgbm.so.1.0.0
/usr/lib64/libxcb-shape.so.0.0.0
/usr/lib64/libxcb-xfixes.so.0.0.0
/usr/lib64/libxcb-dri2.so.0.0.0
/usr/lib64/libharfbuzz.so.0.941.0
/usr/lib64/libICE.so.6.3.0
/usr/lib64/libSM.so.6.0.1
/usr/lib64/libX11-xcb.so.1.0.0
/usr/lib64/libxcb-util.so.1.0.0
/usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2.0
/usr/lib64/libxcb.so.1.1.0
/usr/lib64/libxcb-render.so.0.0.0
/usr/lib64/libxcb-shm.so.0.0.0
/usr/lib64/opengl/xorg-x11/lib/libEGL.so.1.0.0
/usr/lib64/libpixman-1.so.0.32.8
/lib64/libresolv-2.20.so
/usr/lib64/libpangoft2-1.0.so.0.3600.8
/usr/lib64/libpangocairo-1.0.so.0.3600.8
/usr/lib64/libgmodule-2.0.so.0.4400.1
/usr/lib64/libXcursor.so.1.0.2
/usr/lib64/libXrandr.so.2.2.0
/usr/lib64/libXi.so.6.1.0
/usr/lib64/libexpat.so.1.6.0
/lib64/libbz2.so.1.0.6
/usr/lib64/libgthread-2.0.so.0.4400.1
/usr/lib64/libXt.so.6.0.0
/usr/lib64/libX11.so.6.3.0
/usr/lib64/libstartup-notification-1.so.0.0.0
/usr/lib64/libgdk_pixbuf-2.0.so.0.3000.8
/usr/lib64/libcairo.so.2.11400.2
/usr/lib64/libpango-1.0.so.0.3600.8
/usr/lib64/libgdk-x11-2.0.so.0.2400.28
/usr/lib64/libgio-2.0.so.0.4400.1
/usr/lib64/libatk-1.0.so.0.21609.1
/usr/lib64/libgtk-x11-2.0.so.0.2400.28
/usr/lib64/libglib-2.0.so.0.4400.1
/usr/lib64/libgobject-2.0.so.0.4400.1
/usr/lib64/libdbus-1.so.3.8.11
/usr/lib64/libdbus-glib-1.so.2.2.2
/usr/lib64/libasound.so.2.0.0
/usr/lib64/libevent-2.0.so.5.1.9
/usr/lib64/libhunspell-1.3.so.0.0.0
/usr/lib64/libpng16.so.16.18.0
/usr/lib64/libXcomposite.so.1.0.0
/usr/lib64/libXfixes.so.3.1.0
/usr/lib64/libXdamage.so.1.1.0
/usr/lib64/libXext.so.6.4.0
/usr/lib64/libXrender.so.1.3.0
/lib64/librt-2.20.so
/usr/lib64/libfontconfig.so.1.8.0
/usr/lib64/libfreetype.so.6.11.4
/usr/lib64/libnssutil3.so
/usr/lib64/libnss3.so
/usr/lib64/libsmime3.so
/usr/lib64/libssl3.so
/lib64/libz.so.1.2.8
/usr/lib64/libnspr4.so
/usr/lib64/libplc4.so
/usr/lib64/libplds4.so
/usr/lib64/libffi.so.6.0.1
/usr/lib64/firefox/libxul.so
/usr/lib64/firefox/libmozsqlite3.so
/usr/lib64/firefox/libmozalloc.so
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
/lib64/libc-2.20.so
/lib64/libm-2.20.so
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6.0.20
/lib64/libdl-2.20.so
/lib64/libpthread-2.20.so
/lib64/ld-2.20.so

Уязвимость в любом из внешних компонентов = уязвимая система. И это не говоря уже про дыры в самом браузере, которые всегда есть. В этом можно убедиться по хистори ченджлога.

Браузер - всего лишь один из примеров сложного софта, в котором всегда огромное количество дыр.

если помнишь прикол «лучшая защита это призерватив на линк надеть»

В дистре общего назначения модули conntrack для dccp таки присутствуют. Всего-то делов - словить dccp пакет от любого хоста в интернете.

Т.е., безопасность для тебя - это уверенность в том, что ты заметишь хак?

Я натолкнулся на этот баг. Год висит как и, вроде, не починили.

Защита методом неуловимого Джо ничего не доказывает

ты не заметишь, даже если твоё пердачело хакнут, так что...

Неправильно смотришь, фф линкует статически значительное количество сторонних библиотек, особенно в некоторых дистрибутивах.

Звучит здраво

Звучит как бред наркомана. Если ты закроешь все порты, кроме «самых нужных» 80, 443 и 53, то куда у тебя входящие соеднинения пойдут?

Верно, я показал только сошки, со статикой кода еще больше, а значит и потенциальных дыр больше.

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

Или вы о них просто не знаете. А так автор флешками не пользуется?

Флэшки на ext4 и всегда либо бэкап, либо загрузочные с образом.