Бутфорсится любой пользователь, в том числе с uid=0, а при должном умение и упорстве атакующего — никакой fail2ban не спасет.
Поэтому никто, находясь в трезвом уме и твердой памяти, root-у не дает создавать входящее соединение по ssh — а также запускать из под root интересные для взлома сервисы: web-сервер, сервер базы данных, всякие ERP/CRM-мы со своими родными протоколами и т.д. Если, в редких случаях, и позволять root доступ, то только по rsa или dsa ключу(PermitRootLogin without-password) — охраняя свои ключи «как зеницу ока».
п.с:
По теме много еще чего можно написать — но не буду ибо прописные истины(тут вкратце)
Никогда не устанавливаю sudo на серверах и десктопах имеющих прямой доступ в интернет.
Ломается юзер прописанный в sudoers как ALL=(ALL) и «конец кину» — здравствуй новый спамбот… а с описанной дыркой, как понимаю, и ограничение по исполняемым от sudo командам не спасает.
«Моя школьная учительница по английскому языку делала другое лицо:»
Такое же лицо делала моя преподавательница немецкого языка в университете, говорила что: неправильно произношу придыхание в Ich и умляуты — грозила бесплатной туристической поездкой в Грозный(дело было в 1994 году) в сапогах — если не сдам экзамен по языку(в педагогическом то вузе, на биофаке).
С тех пор к дойчу стойкое отвращение — хотя английский приходится изучать, ввиду необходимости чтения технических форумов и литературы.
Интересно и очень много, хотя и логически разделено — можно по частям читать(что и сделаю — дочитаю из закладок :) )
Грамотно и красиво оформленная статья (прям на зависть — есть с кого пример брать), в таком виде хоть в журнале публикуй.
Автору огромное спасибо
Согласен с вами, тут явно «just for fan» = автор так и написал «Главное — наслаждаться работой в ViM». Ну вот нравится ему vim и все тут :)
За себя скажу — что использую с этой же целью MC — он по ssh многое умеет: и каталоги читать; и файлы — копировать, стирать, переименовывать; и редактировать в нужном вам редакторе(меня mcedit устраивает, но никто не запрещает vim запускать). Еще Midnight Commander использует стандартные ssh и scp без монтирования sshfs через fuse — последнее не очень хорошо работает на нестабильных каналах.
п.с:
А автор молодец — просто делает то что ему нравится и кому то его детище обязательно пригодится :)
[+] Opening socketpair.
[+] Executing child from child fork.
[+] Opening parent mem /proc/24125/mem in child.
[+] Sending fd 6 to parent.
[+] Waiting for transferred fd in parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x1190.
[+] Calculating su padding.
[+] Seeking to offset 0x117a.
[+] Executing su with shellcode.
su: пользователь 1ш╟м─1ш╟.м─1иЁ╠╟? м─1юPhn/shh//bi┴Ц1рf╨-iR┴Ю1рRPS┴А1р1ю╟
м─ не существует
$ id
uid=501(test) gid=501(test) группы=501(test)
CentOS 6 i386
$ cat /etc/issue
CentOS Linux release 6.0 (Final)
Kernel \r on an \m
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/6093/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x80491b0.
[+] Calculating su padding.
[+] Seeking to offset 0x804918e.
[+] Executing su with shellcode.
$ id
uid=500(111) gid=500(111) группы=500(111) контекст=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/4720/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x8049180.
[+] Calculating su padding.
[+] Seeking to offset 0x804915e.
[+] Executing su with shellcode.
Ошибка сегментирования
$ id
uid=1001(test) gid=1001(test) группы=1001(test),7(lp),91(video),92(audio),93(optical),95(storage),98(power),100(users)
На нестабильном соединении — вообще не стоит применять виртуальные сетевые ФС, в большинстве случаев после таймаута — получите зависание.
На таком канале поддается некоторой настройке NFS, но это тоже не панацея.
В вашей ситуации применяю ssh для удаленного подключения к сессии screen и scp для копирования файлов в обоих направлениях. Для командных сценариев на python модуль paramiko.
Что то не печалит это меня нисколечки. Возможно дело в особенностях работы и пр. деятельности. В скольких случаях использовал сегодняшний, стабильно работающий, драйвер под ntfs (ntfs-3g) вообще считаю по пальцам: притащили usb-хард расформатированный под ntfs. забрал данные с диска из под погибшей у кого то винды, убил винлокер при помощи livecd от касперского(тот что на основе gentoo сделан)… и наверно все за последние полгода.
Согласен — тем кто работает с использованием двойной загрузки (win/lin) может и нужно = но в таком случае обычно создается раздел для обмена данными — сейчас можно и под ntfs, раньше был fat32
Еще момент: обычно внедрение новой fs у microsoft идет весьма неспешно(как было уже с ntfs) + инерция пользователей(весьма осмотрительная в данном случае) — недоверие к этаким нововведениям. В результате имеем несколько лет времени за которые в режиме реверс-инженерии уже создадут(если будет сильно нужен) какой нибудь ReFS-4g — хотя бы для работы в режиме «только чтение».
Идеального решения с оборудованием (a la microsoft) конечно нет и боюсь, что в привычном виде, никогда не будет.
Классический бинарный драйвер (в виде демона или модуля ядра) сложно постоянно поддерживать в непрерывно совершенствующейся оси — в целом не имеющий понятия релиз: создавать релизы могут только отдельные дистрибутивы замораживая код на время — debian, redhat, *bunt и т.д… к rolling release дистибам последнее не относится. Потому привычная схема и не работает: сменилась версия ядра — требуется коррекция драйверов-модулей, обновился cups — требуется коррекция демона печати(пресловутый capt от canon) и все в таком духе. У microsoft подобное наблюдается — но происходит в более длительный промежуток времени между версиями + из версии в версию тянется груз winapi «со всеми каками прошлых версий» — зато позволяющий сохранять вертикальную совместимость ПО и, по идее, драйверов. к чему всю эту демагогию развел:
просто не нужно тянуть чужой устав в свой монастырь: комично получается :)
а подход к linux-драйверостороительству весьма прост: * Ось и производитель, не строят велосипедов, а четко придерживаются стандартов (хорошо это у samsung получается в смысле принтеров, у hp чуть хуже) *Производитель предоставляет в открытый доступ описание протокола взаимодействия со своей железкой (некоторое оборудование ATI и intel). * Компьютер сразу во время производства тестируется на совместимость с конкретным релизом конкретного дистрибутива (что и делает dell, с простым расчетом 3 года поддерживается LTS версия buntu = 3 года примерный срок жизни ноутбука) * Windows-like путь: есть у производителя достаточный штат специалистов чтобы следить за версиями, а спеки страшная военная тайна = делай бинарный драйвер и поддерживай его (nvidia) * ну и конечно сами гики обвешанные дизассемблерами, осциллографами и прочей неведомой аппаратуроой и софтом, с неисчерпаемым желанием узнать: «а как же энта хрень работает, чтоб потом к любимой оси прикрутить» = реверс-инжиниринг (не исчезнет никогда — хоть все спеки открой с протоколами)
и похоже описанный подход работает — просто сравнивая ситуацию с запуском оборудования в linux в 2007 году с текущем временем, не веришь глазам свом: в 70% случаев — просто втыкаешь, а оно просто работает… железок проходит через руки, много:) — конечно стараешься избегать неведомой экзотики)
Потому что linux драйвера под практически все устройства — это сплошной реверс-инжиниринг.
Там где «эта радость» предоставляется напрямую разработчиком оборудования, в том же стандарте качества что и для microsoft (яркий пример — nvidia ), проблем нет. Там где схалтурили, «сделали чтоб было — подавитесь»(яркий пример — canon принтеры) — будут сплошные проблемы = уж лучше бы: обратный инжиниринг.
пс:
Обратная разработка драйверов для оборудования с «закрытыми спеками» — занимает много времени, потому и выходит — что нормально большинство железа начинает под linux работать только по прошествии времени(иногда значительного)… и нефиг тут на зеркало ось пинять, коли у индивидуума производителя рожа кривая спеки закрыты и драйверов он не делает.
Ребят — это просто шутка была :)
Я никогда не пожалею своих 5 лет в университете, 3-х в аспирантуре и еще 3-х на кафедре — это были лучшие годы и школа научившая мыслить нестандартно, пользоваться разнообразными источниками, систематизировать и анализировать.
В отличие от некоторых своих коллег, так же как и я ушедших с основной специализации в другую отрасль, всегда указываю свое образование и места работы по этому образованию в своем резуме. В принципе тогда занимался анализом динамики биомассы растительных сообществ используя GIS ресурсы — что плотно граничило со сферой IT, в которую в последствии и ушел.
Все — трей появился. Пока на дескопе стартует только qtpanel — все таки погоняю, потестирую ее немного.
Стандартные панельные апплеты lxpanel я не использую за их убогостью, в трее стартуют сторонние приложения — потому разницы тут между lxpanel и qtpanel не заметил.
Выявил еще один недостаток: отсутствие управления рабочими столами: на панели они никак не отображаются. Если переключаешь столы хоткеями — и на разных столах стартуешь разные приложения = они все, в итоге, попадают на общую панель — но открываются только активные для текущего стола.
В результате получается свалка, что скажем мне не удобно: так как раскидываю по 5-ти столам различные по классу задачи (1-й браузер(ы) для серфинга, 2-й офисные приложения, 3-й многократно открытый терминал — в тайлинговом отображении через pytile, 4-й документация в различных форматах, 5-й всякие мультемения и пр развлечения), lxpanel все это богатство отображает в соответствии с активным столом(но не дает переставлять вкладки местами), qtpanel — сваливает в кучу(но можно руками пересортировать вкладки).
Спасибо за ваши знания — которыми делитесь.
Поэтому никто, находясь в трезвом уме и твердой памяти, root-у не дает создавать входящее соединение по ssh — а также запускать из под root интересные для взлома сервисы: web-сервер, сервер базы данных, всякие ERP/CRM-мы со своими родными протоколами и т.д. Если, в редких случаях, и позволять root доступ, то только по rsa или dsa ключу(PermitRootLogin without-password) — охраняя свои ключи «как зеницу ока».
п.с:
По теме много еще чего можно написать — но не буду ибо прописные истины(тут вкратце)
Ломается юзер прописанный в sudoers как ALL=(ALL) и «конец кину» — здравствуй новый спамбот… а с описанной дыркой, как понимаю, и ограничение по исполняемым от sudo командам не спасает.
Такое же лицо делала моя преподавательница немецкого языка в университете, говорила что: неправильно произношу придыхание в Ich и умляуты — грозила бесплатной туристической поездкой в Грозный(дело было в 1994 году) в сапогах — если не сдам экзамен по языку(в педагогическом то вузе, на биофаке).
С тех пор к дойчу стойкое отвращение — хотя английский приходится изучать, ввиду необходимости чтения технических форумов и литературы.
Грамотно и красиво оформленная статья (прям на зависть — есть с кого пример брать), в таком виде хоть в журнале публикуй.
Автору огромное спасибо
За себя скажу — что использую с этой же целью MC — он по ssh многое умеет: и каталоги читать; и файлы — копировать, стирать, переименовывать; и редактировать в нужном вам редакторе(меня mcedit устраивает, но никто не запрещает vim запускать). Еще Midnight Commander использует стандартные ssh и scp без монтирования sshfs через fuse — последнее не очень хорошо работает на нестабильных каналах.
п.с:
А автор молодец — просто делает то что ему нравится и кому то его детище обязательно пригодится :)
знаю что >=2.6.39, первый пример — как контрольная проба
$ cat /etc/issue
CentOS release 5.6 (Final)
Kernel \r on an \m
$ uname -r
2.6.18-238.19.1.el5PAE
$ gcc mempodipper.c -o mempodipper
$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================
[+] Opening socketpair.
[+] Executing child from child fork.
[+] Opening parent mem /proc/24125/mem in child.
[+] Sending fd 6 to parent.
[+] Waiting for transferred fd in parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x1190.
[+] Calculating su padding.
[+] Seeking to offset 0x117a.
[+] Executing su with shellcode.
su: пользователь 1ш╟м─1ш╟.м─1иЁ╠╟? м─1юPhn/shh//bi┴Ц1рf╨-iR┴Ю1рRPS┴А1р1ю╟
м─ не существует
$ id
uid=501(test) gid=501(test) группы=501(test)
CentOS 6 i386
$ cat /etc/issue
CentOS Linux release 6.0 (Final)
Kernel \r on an \m
$ uname -r
2.6.32-71.29.1.el6.i686
$ gcc mempodipper.c -o mempodipper
$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/6093/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x80491b0.
[+] Calculating su padding.
[+] Seeking to offset 0x804918e.
[+] Executing su with shellcode.
$ id
uid=500(111) gid=500(111) группы=500(111) контекст=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
ArchLinux i686
$ cat /etc/issue
Arch Linux \r (\n) (\l)
$ uname -r
3.2.1-1-ARCH
$ gcc mempodipper.c -o mempodipper
$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/4720/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x8049180.
[+] Calculating su padding.
[+] Seeking to offset 0x804915e.
[+] Executing su with shellcode.
Ошибка сегментирования
$ id
uid=1001(test) gid=1001(test) группы=1001(test),7(lp),91(video),92(audio),93(optical),95(storage),98(power),100(users)
п.с:
Дома попробую на 64 битном арче
На таком канале поддается некоторой настройке NFS, но это тоже не панацея.
В вашей ситуации применяю ssh для удаленного подключения к сессии screen и scp для копирования файлов в обоих направлениях. Для командных сценариев на python модуль paramiko.
какие только виртуальные файловые системы на ней не реализуют. Скажем SSHFS какая прелесть!
Согласен — тем кто работает с использованием двойной загрузки (win/lin) может и нужно = но в таком случае обычно создается раздел для обмена данными — сейчас можно и под ntfs, раньше был fat32
Еще момент: обычно внедрение новой fs у microsoft идет весьма неспешно(как было уже с ntfs) + инерция пользователей(весьма осмотрительная в данном случае) — недоверие к этаким нововведениям. В результате имеем несколько лет времени за которые в режиме реверс-инженерии уже создадут(если будет сильно нужен) какой нибудь ReFS-4g — хотя бы для работы в режиме «только чтение».
Классический бинарный драйвер (в виде демона или модуля ядра) сложно постоянно поддерживать в непрерывно совершенствующейся оси — в целом не имеющий понятия релиз: создавать релизы могут только отдельные дистрибутивы замораживая код на время — debian, redhat, *bunt и т.д… к rolling release дистибам последнее не относится. Потому привычная схема и не работает: сменилась версия ядра — требуется коррекция драйверов-модулей, обновился cups — требуется коррекция демона печати(пресловутый capt от canon) и все в таком духе. У microsoft подобное наблюдается — но происходит в более длительный промежуток времени между версиями + из версии в версию тянется груз winapi «со всеми каками прошлых версий» — зато позволяющий сохранять вертикальную совместимость ПО и, по идее, драйверов.
к чему всю эту демагогию развел:
просто не нужно тянуть чужой устав в свой монастырь: комично получается :)
а подход к linux-драйверостороительству весьма прост:
* Ось и производитель, не строят велосипедов, а четко придерживаются стандартов (хорошо это у samsung получается в смысле принтеров, у hp чуть хуже)
*Производитель предоставляет в открытый доступ описание протокола взаимодействия со своей железкой (некоторое оборудование ATI и intel).
* Компьютер сразу во время производства тестируется на совместимость с конкретным релизом конкретного дистрибутива (что и делает dell, с простым расчетом 3 года поддерживается LTS версия buntu = 3 года примерный срок жизни ноутбука)
* Windows-like путь: есть у производителя достаточный штат специалистов чтобы следить за версиями, а спеки страшная военная тайна = делай бинарный драйвер и поддерживай его (nvidia)
* ну и конечно сами гики обвешанные дизассемблерами, осциллографами и прочей неведомой аппаратуроой и софтом, с неисчерпаемым желанием узнать: «а как же энта хрень работает, чтоб потом к любимой оси прикрутить» = реверс-инжиниринг (не исчезнет никогда — хоть все спеки открой с протоколами)
и похоже описанный подход работает — просто сравнивая ситуацию с запуском оборудования в linux в 2007 году с текущем временем, не веришь глазам свом: в 70% случаев — просто втыкаешь, а оно просто работает… железок проходит через руки, много:) — конечно стараешься избегать неведомой экзотики)
Там где «эта радость» предоставляется напрямую разработчиком оборудования, в том же стандарте качества что и для microsoft (яркий пример — nvidia ), проблем нет. Там где схалтурили, «сделали чтоб было — подавитесь»(яркий пример — canon принтеры) — будут сплошные проблемы = уж лучше бы: обратный инжиниринг.
пс:
Обратная разработка драйверов для оборудования с «закрытыми спеками» — занимает много времени, потому и выходит — что нормально большинство железа начинает под linux работать только по прошествии времени(иногда значительного)… и нефиг тут на
зеркалоось пинять, коли уиндивидуумапроизводителярожа криваяспеки закрыты и драйверов он не делает.openkinect
www.youtube.com/v/rKhW-cvpkks
и на хабаре уже было:
Побеждаем Kinect в Linux
Я никогда не пожалею своих 5 лет в университете, 3-х в аспирантуре и еще 3-х на кафедре — это были лучшие годы и школа научившая мыслить нестандартно, пользоваться разнообразными источниками, систематизировать и анализировать.
В отличие от некоторых своих коллег, так же как и я ушедших с основной специализации в другую отрасль, всегда указываю свое образование и места работы по этому образованию в своем резуме. В принципе тогда занимался анализом динамики биомассы растительных сообществ используя GIS ресурсы — что плотно граничило со сферой IT, в которую в последствии и ушел.
Стандартные панельные апплеты lxpanel я не использую за их убогостью, в трее стартуют сторонние приложения — потому разницы тут между lxpanel и qtpanel не заметил.
Выявил еще один недостаток: отсутствие управления рабочими столами: на панели они никак не отображаются. Если переключаешь столы хоткеями — и на разных столах стартуешь разные приложения = они все, в итоге, попадают на общую панель — но открываются только активные для текущего стола.
В результате получается свалка, что скажем мне не удобно: так как раскидываю по 5-ти столам различные по классу задачи (1-й браузер(ы) для серфинга, 2-й офисные приложения, 3-й многократно открытый терминал — в тайлинговом отображении через pytile, 4-й документация в различных форматах, 5-й всякие мультемения и пр развлечения), lxpanel все это богатство отображает в соответствии с активным столом(но не дает переставлять вкладки местами), qtpanel — сваливает в кучу(но можно руками пересортировать вкладки).