|
2.5, Crazy Alex (ok), 15:17, 28/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Например, чтобы пролезть оттуда, где вовне открыт доступ только на 80 и 443, на свой VDS
| |
|
3.6, толлейбусизбуханки (?), 18:50, 29/07/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
а тебе не ссыкотно?
обычно где вовне он так открыт - еще при входе заставляют подписать бумажку, что на работе надо заниматься работой, а не по своим vds лазать. И учти, что pa/checkpoint/cisco умеют отличать ssl от левого протокола на тех же портах, тем же самым (и не только) способом.
впрочем, гораздо чаще - на дороге стоит дешифрующий прокси, и никакой ssh через него не пролезет в принципе.
а вот мобилы заставляют сдавать в камеру хранения гораздо позже.
| |
|
4.15, Crazy Alex (ok), 14:24, 31/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Есть реальная безопасность, а есть заигравшиеся админы или, что гораздо чаще, банально стадартные полиси, не подходящие под половину реальных ситуаций. И подобными обходами пользуются тупо все - и для работы, и фоточки с котиками смотреть. И все об этом знают - ну просто потому, что это не криминал, а технически обойти проще, чем с бюрократией возиться. И быстрее - на месяцы. Соответственно, никакого DPI там нет в принципе, потому что тот, кто всё это настраивал, тоже понимал, скажем так, не универсальность требований.
Я вообще ещё не видел ни одного случая, чтобы в более-менее крупной конторе возможно было эффективно работать, не нарушая букву полиси.
Впрочем, обычно проще, конечно, тупо на 443 поднять ssl vpn.
| |
|
5.17, пох (?), 22:21, 31/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Есть реальная безопасность, а есть заигравшиеся админы или, что гораздо чаще, банально
> стадартные полиси
и твоя стандартная подпись под ней. Ну и оно вот тебе - надо?
> И подобными обходами пользуются тупо все
потом начальству попадает возжа под хвост, админу надо на кого-то свалить проблему с вирусом, положившим пол-сети, меняется младший оператор зонда в отделе иб, или ты не так с кем-то здороваешься - и увольняют по статье, велев радоваться, что не заставили компенсировать "ущерб".
Ну и насчет "все" это явное преувеличение. Тетки в бухгалтерии тоже настраивают себе ssh на левых vps?
> Я вообще ещё не видел ни одного случая, чтобы в более-менее крупной конторе возможно было
> эффективно работать, не нарушая букву полиси.
я видел и работаю. интернет доступен в силу служебного положения, флэшки - нет. Ну и хер с ними.
Нужен конфиг vpn дома - ок, идем к начальству, оно допущено к актам владения переносными носителями. Нет на месте - значит, vpn из дома у меня пока не будет. За это еще никого не уволили.
не путать буквы с личными фанабериями админчиков - этим успешно можно прищемить хвост или игнорировать предоставляемый ими сервис. Но если подписал бумажку, что доступ в интернет строго для работы, потребные для работы сайты прилагаются списком - глупо наживать себе неприятности, да еще столь череззадничными методами.
а для дpoчева на опеннете есть мобило. Если и его заставляют сдавать при входе - нафига ж было там работать?
| |
|
6.26, Crazy Alex (ok), 11:50, 04/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да никто не заставляет мобилы сдавать. Речь об обычных больших айтишных конторах, где "глобальная" полиси вечно конфликтует с нуждами и удобствами конкретных проектов, и в мелочах никто её не энфорсит, так как невозможно и половина разработчикв уволится на фиг из такого концлагеря (и найдёт себе другую работу за пару недель). Что там у тёток в бухгалтерии мне вообще не интересно, речь об айтишных решениях на айтишном ресурсе. А вот где точно не надо работать, так это там, где могут попытаться уволить, потому что "не так с кем-то здороваешься" и т.п. Благо, для программиста есть вагон более привлекательных вариантов, где даже в случае каких-то проблем сначала минимум пару раз вежливо пообщаются, и только потом, если не договоритесь, разорвут контракт.
| |
6.36, Аноним (36), 00:56, 12/09/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
А вы не думали что есть юзкейсы кроме того что ты раб который пyкнуть боится чтобы с работы по статье не пойти?
| |
6.38, Максим (??), 22:21, 20/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну и страдай, трепеща перед "начальством" и подписывая разрешения на каждый поход в сортир. Такие конторы издалека видно ещё на собеседовании (а то и до него). И я искренне не понимаю тех мазохистов, которые идут туда работать.
| |
|
|
|
3.33, atk91 (ok), 13:36, 06/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
почему нельзя просто на свой vds повесить sshd на 443 порт?
| |
|
|
1.3, Василий (??), 12:58, 26/07/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А есть ли возможность сделать подобное с витруальными-хостами ( server_name )? Например крутятся во многих lxc разные сайты и мы хотим давать доступ и по https и по ssh через единый nginx на хост системе
| |
|
|
3.8, толлейбусизбуханки (?), 18:54, 29/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> как я понял , можно написать еще один map по ssl_preread_server_name
нельзя, нет в ssh никакого "server name".
| |
|
2.7, толлейбусизбуханки (?), 18:53, 29/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> А есть ли возможность сделать подобное с витруальными-хостами ( server_name )?
нет. да и зачем?
> Например крутятся во многих lxc разные сайты и мы хотим
для этого есть sni, который прекрасно работает без этих ненужно-фокусов.
> давать доступ и по https и по ssh через единый nginx
а для ssh нет sni, да и не парсит его nginx, просто откидывая как "не-ssl" - поэтому попасть по ssh ты сможешь только на кого-то одного. Например на саму хост-систему, было бы чего ради огород-то городить...
| |
|
1.9, adsh (ok), 19:43, 30/07/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Это получается, что если долбиться в 443 порт как SSL (2,3), TLS (1.0,1.1) или любым другим, не TLS 1.2 образом, то всё это будет скормлено sshd? А ему не поплохеет? Молодцы...
| |
|
2.10, Аноним (10), 21:00, 30/07/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если вашему sshd поплохеет из-за того, что ему от неаутентифицированного клиента прилетит в сокет мусор, то у вас какой-то неправильный sshd.
| |
|
3.11, adsh (ok), 22:02, 30/07/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Обычное количество HTTP запросов не идёт ни в какое сравнение с числом таковых же по SSH. Фактически, в статье описан рецепт, как сделать DOS на свой же сервер. Правильнее было сделать наоборот - воспринимать все обращения по умолчанию, как HTTP запросы.
| |
|
4.14, толлейбусизбуханки (?), 12:09, 31/07/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Правильнее было сделать наоборот - воспринимать
> все обращения по умолчанию, как HTTP запросы.
а они не могут. Там суть не в "по умолчанию" а в "нешмалга я распознать".
то есть единственное, что можно сделать, если уж задаться целью спасти доступ васяна к его ssh - это перечислять абсолютно все распознаваемые (regex або поштучно), а ssh по прежнему валить в default - его нечем матчить.
если бы авторы этого странного кода действительно имели ту же цель, что и васян, они бы добавили значение "unknown", отдельное от "default". Но у них явно была какая-то другая задача, а пример писал менеджер по рекламе, поэтому такая фигня и написана.
| |
|
|
2.13, толлейбусизбуханки (?), 12:04, 31/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
да не переживайте так, васян-vds'у на котором этот конфиг бездумно скопипастили, чтобы "обойти систему", в общем-то пофиг. В том числе и тот факт, что пользователи неправильных браузеров сайта не увидят.
а реальные применения препарсера - они для ids каких-нибудь имеют смысл, защит от атак ("ssl2 роняем на пол, это точно не человек, странные протоколы отправляем в один балансер, нормальные, реально используемые большинством юзеров - в другой"), еще чего в этом же роде - и там, уверяю, не ssh будет принимать default ;-)
| |
2.34, Аноним (36), 00:45, 12/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну ты же умнее автора примера, небось сообразишь как остальные версии прописать?
| |
|
|
|
3.18, int13h (ok), 23:54, 31/07/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Коллега, неопытный администратор, которому кто-то выслал доступ к серверу в виде "root@blahblah -p443" начал править конфиги nginx и ошибся, не выполнив nginx -t, совершив синтаксическую ошибку рестартанул веб-сервер. Дальше, додумаете сами.
Не проще ли использовать порт, к примеру, 22732 + доступ по ключу?
| |
|
4.19, adsh (ok), 00:39, 01/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Не проще ли использовать порт, к примеру, 22732 + доступ по ключу?
Порт может быть закрыт, а ключ можно украсть вместе с компом. Паролить ключ - это уже почти то же самое, что заходить по паролю. Только пароль нужно держать в голове или в программе для хранения паролей со стойким паролем, опять же - в голове.
| |
|
5.20, int13h (ok), 00:49, 01/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> Не проще ли использовать порт, к примеру, 22732 + доступ по ключу?
> Порт может быть закрыт, а ключ можно украсть вместе с компом. Паролить
> ключ - это уже почти то же самое, что заходить по
> паролю. Только пароль нужно держать в голове или в программе для
> хранения паролей со стойким паролем, опять же - в голове.
Откройте порт -- в чем проблема?
Ну, если есть сложности с запоминанием пароля )
Просто на порт !=22 меньше "китайцев" будет стучать.
Я про то, что смысла стримить трафик ssh через nginx нет, это как-то неправильно
| |
|
6.21, adsh (ok), 01:21, 01/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Откройте порт -- в чем проблема?
Описанный в статье рецепт относится к ситуации, когда на хостинге открыты только заданные порты и изменить это нельзя.
> Я про то, что смысла стримить трафик ssh через nginx нет, это как-то неправильно
Конечно неправильно и где-то даже отдаёт идиотизмом.
| |
|
7.23, int13h (ok), 09:43, 01/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
>Описанный в статье рецепт относится к ситуации, когда на хостинге открыты только заданные порты и изменить это нельзя.
Мы говорим о хостинге или сервере (аппаратном, виртуализированном)? Если о хостинге, то Вам никто не даст стримить ssh через nginx
| |
|
8.25, adsh (ok), 15:17, 01/08/2018 [^] [^^] [^^^] [ответить] | +/– | Вообще говоря - нужно спросить у автора, для какого случая это всё Это может бы... текст свёрнут, показать | |
|
|
|
5.22, ssh (ok), 09:37, 01/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Паролить ключ - это уже почти то же самое, что заходить по паролю.
Вас обманули. Пасс-фраза вводится один раз при авторизации в системе, опционально после каждой разблокировки экрана. А к хостам подключаетесь посредством ssh host ;)
| |
|
6.24, adsh (ok), 15:12, 01/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Вас обманули. Пасс-фраза вводится один раз при авторизации в системе, опционально после
> каждой разблокировки экрана. А к хостам подключаетесь посредством ssh host ;)
Вы сами себя обманули. Это от клиента зависит, как он работает с паролем к ключу.
| |
|
7.27, h31 (ok), 12:37, 04/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
От наличия и настроек ssh-agent, если уж так говорить.
| |
7.29, ssh (ok), 14:48, 07/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Вы сами себя обманули. Это от клиента зависит, как он работает с
> паролем к ключу.
Разумеется я имел ввиду клиент из комплекта OpenSSH, там именно так как я написал. Используйте агент и не сочиняйте нам тут. :)
| |
|
|
|
4.28, Аноним (28), 23:00, 05/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
> nginx и ошибся, не выполнив nginx -t, совершив синтаксическую ошибку рестартанул веб-сервер.
И nginx не рестартанул, а остался работать со старым конфигом, так как именно так он себя и ведет в приличных системах. Проверено электрониками.
| |
|
5.30, Аноним (30), 10:00, 22/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
омг, restart != reload.
вы описали поведение для reload'а, а при restart'е выполняется остановка процесса и его запуск.
поэтому если конфиг битый запуск завершается с ошибкой.
| |
|
6.31, moo (?), 09:08, 04/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
Зависит от ОС.
В нормальных - при restart'е перед стопом делается nginx -t.
| |
|
|
|
|
2.35, Аноним (36), 00:47, 12/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Так, а для чего это делать? Не, серьезно -- для чего?
А почему нет-то? Мало ли откуда приспичит до сервера достучаться, и может там все кроме 80/443 блокируют.
| |
|
1.41, Nolf (ok), 17:46, 13/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А как быть в ситуации если есть сервак с белым IP, а на нем 10 вируталок с сервми IP... И нужно ходить из вне на них по SSH?
| |
|