Снова про безопасность - РЕАЛЬНЫЕ угрозы и способы защиты (а кто считает что угроз нет - просьба не соваться)

[taaroa]

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

да, вы правы. в пентагоне осталась одна школота.
взлом пентагона краткое пособие читать бесплатно без sms.

p.s. вероятнее всего тупо выйдет из строя железо (при аптайме более 20 лет). если же речь идёт о домашнем пользователе (где он по совместительству и root, и user), то риски многократно возрастают. начиная с того, что хомячок _сам_ сдаст все явки/адреса/пароли установив невесть откуда "суперкрякер интернетов". и это более вероятно, чем, скажем, наводнение на высоте пять тысяч метров над уровнем моря или падение второй ступени ракетоносителя "протон" на дом хомячка или датацентр.

[InterChaynik]

Если в твоём браузере (или не только браузере) засел некий паразит (и не важно от куда он там взялся), как его обнаружить? Как вообще можно узнать что ты его подцепил?

[watashiwa_daredeska]

как его обнаружить? Как вообще можно узнать что ты его подцепил?

google://IDS Не?

[drBatty]

Для уверенности. Так что не думаю, что под GNU/Linux поступлю по-другому.

+1

$

rm -rvf ~/.wine

Если в твоём браузере (или не только браузере) засел некий паразит (и не важно от куда он там взялся), как его обнаружить? Как вообще можно узнать что ты его подцепил?

вы можете составить список SHA-512 для каждого файла, и проверять их каждые 5 минут. Хотя лично я просто монтирую /usr как readonly - вирус даже с правами рута не сможет туда ничего записать. Я не думаю, что у этого вируса появятся не только права рута, но и такой могучий AI. Да если и появится, оно мне комп намертво повесит :)

[SinClaus]

Блин... Пока я работал под виндой, у меня на машине только раз в течение минут пяти был неконтролируемо активен вирус. Это в конце концов зависит от оператора (юзверя) а не от системы. В основном.

[drBatty]

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

ну моему зверьку хватит и нескольких секунд, даже на очень старой технике ;)

[taaroa]

краткое пособие для одептов.

To make system more secure in general:
1. Uninstall packages with unused suid/sgid binaries (like sudo) //p.s. migrating from shadow passwords to tcb
2. Make sure all the PaX and Grsecurity features are enabled, configured properly and don't prevent apps from working
3. Rebuild your kernel without unnecessary things like modules, LSM framework, SCTP and IPsec, FUSE, DRM, ALSA/OSS and so on
4. Apply more restricted DAC permissions on sensitive files and directories like stuff in /var/log, /sys, /boot, /lib/modules, /proc/bus, etc
5. Use more secure resolvers like unbound or djbdns instead of BIND; use more secure syslog daemon like socklog or even don't use syslog daemon at all
6. Make sure executables you use are build as PIE to make ROP attacks more unlikely to success, and if they aren't PIE, rebuild them with customized specs
7. If you connect to several banking systems, do it as separate users in separate X window servers, and maybe deploy some restrictive RBAC policy with custom killing and logging traps to detect and prevent intrusions
8. Try to maintain static /dev to prevent any exploitation of udev
9. Use iptables to reject any inbound connections to prevent exploitation of services that could be left running by mistake
10. Configure your browser for strict SSL/TLS usage (like requiring OCSP avalability, only safe TLS negotiation, no weak ciphers, etc)
11. Uninstall anything you don't need to prevent web browser or any other app from running Java applets and audio/video content by accident, etc.
12. Use NoScript and its ABE to prevent XSS/CSRF attacks
13. Disable JIT compiling of JavaScript and enable MPROTECT restriction on web browser executable
14. Anything else I forgot or don't know about

Btw, TinHat seems more appropriate for your task (if you have enough RAM to run it), or Hardened Gentoo, as they both have strong kernelspace and userspace hardeding, while OpenSUSE (which NetSecl 3.0 is based on), AFAIK, does not provide PIE binaries (at least not for client apps), has (partially) writable ELF relocation tables, no system-wide -fstack-protector-all, etc...

[taaroa]

Если в твоём браузере (или не только браузере) засел некий паразит (и не важно от куда он там взялся), как его обнаружить? Как вообще можно узнать что ты его подцепил?

Не стоит искать чёрную кошку в тёмной комнате ночью. Особенно, если её там нет. © Конфуций

[drBatty]

краткое пособие для одептов.

жестоко...

[chitatel]

краткое пособие для одептов.

Одепт.
Он во всё черное одет.
Одепты ходят там и тут
И постоянно где-то с root

[/dev/random]

жестоко...

А что жестокого-то? Грамотные рекомендации. Единственное, пункт 3 часто бывает невыполним.

Я бы ещё добавил такие:
* Пользователь не должен иметь права исполнять файлы там, куда имеет право писать. Этого можно добиться как с помощью правил RBAC, так и монтированием с noexec.
* Также нужно позаботиться об автоматически исполняемых файлах, таких как .bashrc. Они должны быть ro и неудаляемы (напр., через sticky-bit) для пользователя.
* Есть несколько программ, требующих наличия исполнимых файлов в $HOME; при использовании RBAC для них можно сделать исключение (и опять же защитить файлы от записи/удаления), без использования RBAC остаётся только не пользоваться такими программами.

[sciko]

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

А как быть со скриптами? Тот же python не запретишь, а на x файла ему наплевать.

ЗЫ. Кстати, что лучше использовать acl или rsbac?

[/dev/random]

А как быть со скриптами? Тот же python не запретишь, а на x файла ему наплевать.

А не нужно его запрещать. Прежде, чем что-то запрещать, нужно подумать, чем оно может навредить.
Чем может навредить запуск созданного злоумышленником файла?
1) Если его запускает не злоумышленник, а вы либо система, то вред очевиден, и я не буду его расписывать. Но с этим бороться легко: достаточно запретить изменение/перезапись автозапускаемых файлов и файлов, находящихся в $PATH.
2) Если его запускает сам злоумышленник:
2а) скрипт. Дополнительного вреда никакого. Если он добрался до исполнения команд (чтобы запустить скрипт), то он сможет выполнить содержащиеся в нём команды и по одной, и от того, что он сможет или не сможет оформить их в единый скрипт, ничего не изменится. Поэтому бороться с запуском скриптов бессмысленно.
2б) бинарник. Вот тут вред уже есть: многие эксплойты повышения привилегий требуют выполнения системных вызовов, что возможно только из бинарника. Но запуск бинарников всегда учитывает noexec.

[sciko]

Для подавляющего большинства ACL-прав уже найдены способы гарантированного повышения привилегий с них до рута.

А моожно про это поподробнее? Я-то думал, что acl нельзя разрешить того, что запрещено обычными правами.

[/dev/random]

Для подавляющего большинства ACL-прав уже найдены способы гарантированного повышения привилегий с них до рута.

А моожно про это поподробнее? Я-то думал, что acl нельзя разрешить того, что запрещено обычными правами.

Тьфу, прошу прощения. Меня переклинило, не обращайте внимания на тот абзац. Я удалил его из предыдущего поста.
Когда я отвечал про ACL, я думал вовсе не про ACL.

[sciko]

Тьфу, прошу прощения.

Бывает. Но тогда вопрос

Кстати, что лучше использовать acl или rsbac?

остаётся в силе.

Когда я отвечал про ACL, я думал вовсе не про ACL.

А про что, если не секрет? Просто любопытно.

[taaroa]

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

А как быть со скриптами? Тот же python не запретишь, а на x файла ему наплевать.

tpe

TPE test

% id uid=1666(hax) gid=1666(hax) groups=1666(hax) % pwd /home/hax/tmp % la analyze-x86.pl -rwxr-xr-x 1 hax hax 12K May 8 2010 analyze-x86.pl % ./analyze-x86.pl /bin/ls zsh: permission denied: ./analyze-x86.pl # tail -1 /var/log/grsec.log Apr 4 15:34:56 localhost kernel: [449012.718692] grsec: denied untrusted exec of /home/hax/tmp/analyze-x86.pl by /bin/zsh[zsh:3507] uid/euid:1666/1666 gid/egid:1666/1666, parent /bin/zsh[zsh:3474] uid/euid:1666/1666 gid/egid:1666/1666

[/dev/random]

Бывает. Но тогда вопрос

Кстати, что лучше использовать acl или rsbac?

остаётся в силе.

Субъективный вопрос. RSBAC (кстати, это не единственная реализация RBAC в Linux, есть и другие) мощнее, но эта мощность не всегда нужна. Изучите возможности и особенности всех вариантов и определите, какой ближе к вашим целям.

[drBatty]

А что жестокого-то? Грамотные рекомендации. Единственное, пункт 3 часто бывает невыполним.

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

Я-то думал, что acl нельзя разрешить того, что запрещено обычными правами.

ими можно запретить то, что нельзя запретить обычными правами.

./analyze-x86.pl /bin/ls
zsh: permission denied: ./analyze-x86.pl

а если perl analyze* ?

[/dev/random]

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

Они вполне достижимы, и у меня даже почти все достигнуты.

[taaroa]

./analyze-x86.pl /bin/ls
zsh: permission denied: ./analyze-x86.pl

а если perl analyze* ?

Shell

% perl analyze-x86.pl /bin/ls Checking vendor_id string... AuthenticAMD 64 Disassembling /bin/ls, please wait... i486: 0 i586: 0 ppro: 111 mmx: 63 3dnow: 0 ext3dnow: 0 sse: 67 sse2: 5 sse3: 6 sse4a: 0 /bin/ls will run on AMD Athlon64 w/ SSE3 or higher processor. % cc sp_exploit.c -o sp % la sp -rwxr-xr-x 1 hax hax 8.0K Apr 4 20:48 sp %./sp zsh: permission denied: ./sp # tail -1 /var/log/grsec.log Apr 4 20:49:37 localhost kernel: [467893.415751] grsec: denied untrusted exec of /home/hax/tmp/sp by /bin/zsh[zsh:4630] uid/euid:1666/1666 gid/egid:1666/1666, parent /bin/zsh[zsh:4594] uid/euid:1666/1666 gid/egid:1666/1666

[drBatty]

taaroa
я к тому, что скрипт так не запретишь. А ELF можно просто noexec использовать. Хотя я согласен с /dev/random - скрипты запрещать не нужно. Достаточно запретить подмену команд скриптами, а это не сложно. (в PATH всё равно /usr/bin раньше идёт, потому подменить мне su никак не получится.)

Они вполне достижимы, и у меня даже почти все достигнуты.

у мну тоже почти все и почти достигнуты :)

[Ali1]

Был My_Data.txt -- ценный файл.

Код: Выделить всё

[ali@aliCQ tmp]$ mount | grep exec
/dev/mapper/vg_alicq-rpmbuild on /home/ali/rpmbuild type ext4 (rw,noexec,nosuid,nodev)
[ali@aliCQ tmp]$ pwd
/home/ali/rpmbuild/tmp
[ali@aliCQ tmp]$ ll
итого 8
-rw-rw-r--. 1 ali ali  0 Апр  5 00:44 My_Data.txt
-rw-rw-r--. 1 ali ali 31 Апр  5 00:43 s1.sh
-rwxrwxr-x. 1 ali ali 31 Апр  5 00:43 s.sh
[ali@aliCQ tmp]$ cat s1.sh
#!/bin/sh
rm -f ./My_Data.txt

[ali@aliCQ tmp]$ sh ./s1.sh
[ali@aliCQ tmp]$ ll
итого 8
-rw-rw-r--. 1 ali ali 31 Апр  5 00:43 s1.sh
-rwxrwxr-x. 1 ali ali 31 Апр  5 00:43 s.sh
[ali@aliCQ tmp]$

И нет его.
Что я не понимаю?

[drBatty]

И нет его.
Что я не понимаю?

а какая разница - запустит враг rm -f ./My_Data.txt или sh ./s1.sh ?
никакой. потому нет смысла запрещать sh-скрипт.

[shevan]

А зачем париться над безопасностью линукса среднестатическому пользователю домашнего десктопа?
Каков процент реальной угрозы?

Потому что, сам попадаешь в поставленные ограничения, и это лишает определенного комфорта в работе

[drBatty]

А зачем париться над безопасностью линукса среднестатическому пользователю домашнего десктопа?
Каков процент реальной угрозы?

зависит от дистрибутива и от наличия реального врага. Очевидно, что чем менее распространён дистрибутив, тем лучше вы защищены от случайных угроз. Для полной защиты от них необходим свой дистрибутив, или переделанный чужой. Ну и конечно, если у вас есть враги, то вы можете получить НЁХ не случайно. Прежде всего, следует решить - от каких угроз мы защищаемся.

Потому что, сам попадаешь в поставленные ограничения, и это лишает определенного комфорта в работе

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

[t.t]

А зачем париться над безопасностью линукса среднестатическому пользователю домашнего десктопа?
Каков процент реальной угрозы?

зависит от дистрибутива и от наличия реального врага. Очевидно, что чем менее распространён дистрибутив, тем лучше вы защищены от случайных угроз. Для полной защиты от них необходим свой дистрибутив, или переделанный чужой. Ну и конечно, если у вас есть враги, то вы можете получить НЁХ не случайно. Прежде всего, следует решить - от каких угроз мы защищаемся.

Потому что, сам попадаешь в поставленные ограничения, и это лишает определенного комфорта в работе

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

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

[drBatty]

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

ну значит для этих "некоторых случаев" нужно сделать исключение. Нет?
а какие случаи?

[Ali1]

И нет его.
Что я не понимаю?

а какая разница - запустит враг rm -f ./My_Data.txt или sh ./s1.sh ?
никакой. потому нет смысла запрещать sh-скрипт.

Согласен, почти никакой разницы. Но не понимаю я не этого. Зачем мучится с noexec и прочими подобными сложностями? Ведь и после всех этих объёмных и довольно сложных, а потому и потенциально содержащих ошибки конфигурации, упражнений остаётся незащищённым от какой-нибудь браузерной дыры самое ценное, что есть у простого пользователя -- его данные.
Т.е. модель угрозы:

• Сайт с активным содержимым
• Дыра в javascript или flash
• Откатываемая порча фотографий

Да, тут можно сказать, что noexec и т.п. почти закрывают риск эскалации привилегий и порчи системы.
НО потеря системы это не страшно. Система ставится за двадцать минут. А вот текст написанный сейчас невосстановим. И только этот текст для пользователя действительно важен.

[/dev/random]

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


PS:

Дыра в javascript или flash

Флэш вообще только идиот будет ставить на комп, на котором хранятся сколько-нибудь важные данные.