2) su/sudo плохи тем, что позволяют переходить от менее привилегированного аккаунта к более привилегированному. Если этот аккаунт будет скомпрометирован, то будет скомпрометирован и рут — как минимум появляется возможность подбора пароля, как максимум получение пароля путём перехвата (поддельная pts).
3) Представьте себе, что у вас уже _есть_ пароль рута, но вам некуда его вводить — ни su, ни sudo, ни ssh вам не доступны. Весело, да? :)
Во-первых — теряюсь в догадках почему основой оценивания защищённости систем от данной атаки является визуализация нового устройства. В линуксе тихо мирно можно запретить добавление новых устройств через
И вручную (или по вайтлисту, как хочется) включать доверенные устройства.
Во-вторых — в виндовзе поддельное устройство ввода может принести больше вреда, т.к. оно может, эмулируя мышь, нажать на заветную кнопку «разрешить» UAC'а. Если есть поддержка со стороны зловредной программы, и у-во ввода и троян (работающий от админа) могут общаться (т.е. работают не вслепую), то UAC повержен. В UNIX рутовая консоль будет щупаться вслепую, ибо никто не сможет в неё заглянуть (эмулятор терминала в иксах и так незащищён, поддельное у-во ввода не добавит возможностей атакующему).
Сканирование сети на предмет _хостов_, а не открытых портов. TCP/UDP-портов как было 65535, так и осталось :) Если вы знаете адрес жертвы, то разницы никакой.
Потому что большинству приложений просто не нужны фичи sctp вроде сохранения границ сообщения, «многопоточности», мультихоуминга. Всё, что нужно — это двунаправленный поток байтов с гарантией сохранения порядка байтов и надёжности доставки. Проблемы незащищённости соединения, конечно, есть, но это немного другой разговор.
Интересно, а кто сказал, что мы постепенно переходим с TCP на SCTP? В статье IPv6 противопоставляется IPv4 точно также, как и SCTP TCP. Лучше добавить, что тем же макаром можно обеспечить discovery поддержки со стороны сервера альтернативных протоколов без ущерба для производительности.
У меня не было нужды тупо генерировать монотонный траффик, так что не могу сравнить. Тем не менее, чисто логически, нагрузка на процессор должна быть минимальной (Если только в сетевой карте нет генератора :) ).
Создает пару UNIX-сокетов, отправляет первый _сокет_ во второй, закрывает дескриптор первого. Т.к. к первому ещё можно обратиться, если прочитать его из второго, то ядро не освобождает структуры, связанные с первым сокетом. Далее создается третий сокет, второй пишется в него, второй закрывается. И так далее. Эдакая глубокая матрёшка.
Немного не в тему, но у меня такой вопрос. У меня есть роутер zyxel Prestige 600. Его можно заставить ребутнуться как нефиг делать, если начать кидать SYN пакеты с произвольных адресов внутренней сетки на произвольные интернет адреса. Стабильно через 5 секунд — ребут.
Понятно, что нормальная ОС при нехватке памяти под таблицы должна дропать пакеты/коннекты. Но отсюда вопрос — есть ли вообще способ защитить машину, делающую NAT, от таких страстей? Или доверие внутренней сети == беззащитность перед DoS'ом с их стороны?
> Точно так же, при помощи плагинов, можно организовать и управление логическими томами как в ZFS или btrfs. Однако, тут я должен предостеречь: это уже будет так называемое смешение уровней (layering violation). Дело в том, что в Линукс управление томами осуществляется отдельной подсистемой (lvm)
Мне интересно, может ли lvm выделить ФС «быстрые» блоки под часто используемые файлы как ZFS (делает ли то же самое btrfs — не знаю) или все блоки для ФС выглядят как абсолютно равные? Если второе, то мой ответ однозначен — это не такое злобное смешение уровней.
ИМХО вы слишком остро восприняли пункт (3). Первые два гораздо важнее.
lists.openwall.net/full-disclosure/2010/10/18/7
lists.openwall.net/full-disclosure/2010/10/22/15
В идеале их вообще быть не должно.
2) su/sudo плохи тем, что позволяют переходить от менее привилегированного аккаунта к более привилегированному. Если этот аккаунт будет скомпрометирован, то будет скомпрометирован и рут — как минимум появляется возможность подбора пароля, как максимум получение пароля путём перехвата (поддельная pts).
3) Представьте себе, что у вас уже _есть_ пароль рута, но вам некуда его вводить — ни su, ни sudo, ни ssh вам не доступны. Весело, да? :)
echo 0 > /sys/bus/usb/devices/usbX/authorized_default
И вручную (или по вайтлисту, как хочется) включать доверенные устройства.
Во-вторых — в виндовзе поддельное устройство ввода может принести больше вреда, т.к. оно может, эмулируя мышь, нажать на заветную кнопку «разрешить» UAC'а. Если есть поддержка со стороны зловредной программы, и у-во ввода и троян (работающий от админа) могут общаться (т.е. работают не вслепую), то UAC повержен. В UNIX рутовая консоль будет щупаться вслепую, ибо никто не сможет в неё заглянуть (эмулятор терминала в иксах и так незащищён, поддельное у-во ввода не добавит возможностей атакующему).
www.mjmwired.net/kernel/Documentation/networking/pktgen.txt
2) Сама система является OpenVZ-контейнером.
Обе песочницы предполагают, что в ядре нет уязвимостей, дающих выбраться из песочницы, либо получить ресурсы, больше предопределённых.
Понятно, что нормальная ОС при нехватке памяти под таблицы должна дропать пакеты/коннекты. Но отсюда вопрос — есть ли вообще способ защитить машину, делающую NAT, от таких страстей? Или доверие внутренней сети == беззащитность перед DoS'ом с их стороны?
А вконтакте — тот же facebook с точки зрения сабжа.
www.mjmwired.net/kernel/Documentation/kprobes.txt
Правда, не на всех архитектурах…
Мне интересно, может ли lvm выделить ФС «быстрые» блоки под часто используемые файлы как ZFS (делает ли то же самое btrfs — не знаю) или все блоки для ФС выглядят как абсолютно равные? Если второе, то мой ответ однозначен — это не такое злобное смешение уровней.