Bekijk de volledige versie : Смена порта для SSH
DarthSemafor
30-10-2008, 22:11
Как сменить порт для доступа к роутеру по ssh - протоколу?
Unlimited
30-10-2008, 22:18
А зачем? Паранойя? Порт для веб доступа меняют не изза соображений секьюрности, а для того чтоб он не конфликтовал с веб сервером если вы захотите поднять у себя такой ;-)
DarthSemafor
30-10-2008, 22:43
А зачем? Паранойя? Порт для веб доступа меняют не изза соображений секьюрности, а для того чтоб он не конфликтовал с веб сервером если вы захотите поднять у себя такой ;-)
я не про веб - сервер, я имею ввиду SSH
DarthSemafor
31-10-2008, 00:28
Спасибо за ответ!
Unlimited
31-10-2008, 05:46
Лол, я понял что ты про ссш, я просто спросил зачем?
Unlimited - всё просто. Скорее всего задолбало наблюдать попытки перебора паролей через ssh. Самый простой выход - перевесить ssh куда-нить повыше =)
Unlimited
31-10-2008, 08:46
Хз имхо смысла в этом никакого нет, если стоит пароль не 111 и не qwerty...
Хз имхо смысла в этом никакого нет, если стоит пароль не 111 и не qwerty...
Ага, и если место в логе резиновое.
Unlimited
31-10-2008, 10:01
Ну если ты логи солишь, хранишь там три года или еще что очень полезного с ними делаешь...
Вообще от перебора есть другие варианты защиты.. например в пф можно отлично отслеживать количество соединений в заданое количество секунд, а потом оверлоад, и айпишник в таблицу запрещенных на Н количество минут/часов по желанию и настройки expiretable. Наверняка подобное можно сделать и на чейнах.
И выглядеть такое будет куда красивее :-)
Ну если ты логи солишь, хранишь там три года или еще что очень полезного с ними делаешь...
Вообще от перебора есть другие варианты защиты.. например в пф можно отлично отслеживать количество соединений в заданое количество секунд, а потом оверлоад, и айпишник в таблицу запрещенных на Н количество минут/часов по желанию и настройки expiretable. Наверняка подобное можно сделать и на чейнах.
И выглядеть такое будет куда красивее :-)
А зачем усложнять, если можно просто порт переехать?
Ну если ты логи солишь, хранишь там три года или еще что очень полезного с ними делаешь...
Вообще от перебора есть другие варианты защиты.. например в пф можно отлично отслеживать количество соединений в заданое количество секунд, а потом оверлоад, и айпишник в таблицу запрещенных на Н количество минут/часов по желанию и настройки expiretable. Наверняка подобное можно сделать и на чейнах.
И выглядеть такое будет куда красивее :-)
ну так может сделаешь!!!;)
Unlimited
31-10-2008, 12:11
Когда я пойму что перебор примитивными паролями одного из моих ссш хостов это серьезная проблема для меня или что изза этого так забились логи что просто жить негде, то обязательно займусь этой проблемой, но пока исходя из моего опыта администрирования интернет серверов необходимости в подобной защите SSH не было.
Я это юзаю для защиты от рассылателей спама. Тем кто больше 3х соединений по SMTP за 10 секунд открывает блокирую 25й порт на пол часа.
DarthSemafor
31-10-2008, 16:14
Ну если ты логи солишь, хранишь там три года или еще что очень полезного с ними делаешь...
Вообще от перебора есть другие варианты защиты.. например в пф можно отлично отслеживать количество соединений в заданое количество секунд, а потом оверлоад, и айпишник в таблицу запрещенных на Н количество минут/часов по желанию и настройки expiretable. Наверняка подобное можно сделать и на чейнах.
И выглядеть такое будет куда красивее :-)
Пример пф в студию, пожалуйста
Пример пф в студию, пожалуйста
А поиском слабО?
http://wl500g.info/showpost.php?p=69964&postcount=63
DarthSemafor
31-10-2008, 18:15
А где вообще располагаются файлы конфига dropbear? А также pvt и pub ключи?
Unlimited
31-10-2008, 19:03
Пожалуйста, реально работающий пример.
table <bad_hosts> persist
block in quick proto tcp from <bad_hosts> to any port 25
pass in quick on $ext_if proto tcp from any to any port 25
pass in proto tcp from any to any port 25 keep state (max-src-conn-rate 3/10, overload <bad_hosts> flush global)
*/10 * * * * root /usr/local/sbin/expiretable -t 1800 bad_hosts
Вариантов зачем это может понадобиться еще наберется.
И дело тут не в лени настроить "таблички"
У кого-то корпоративная прокся не пускает на 22 порт.
У кого-то корпоративная прокся не пускает на 22 порт.Ага, то-то админы возрадуются, когда из такой сетки кто-то поднимет шифрованный канал в неизвестном направлении на левом порту...
Ага, то-то админы возрадуются, когда из такой сетки кто-то поднимет шифрованный канал в неизвестном направлении на левом порту...
Есть системы защиты, которые ловят всю "левоту" прямо на стадии коннекта, особенно через прокси. И смена порта не поможет.
Только не все про них знают и пользуют.
Я сильно сомневаюсь, что будут ловить левоту на 443 порту
Я сильно сомневаюсь, что будут ловить левоту на 443 порту
Подобные системы фильтрации смотрят не на порт, а на биты.
Соответственно, режется протокол, а не порт.
А вот если надо мониторить шифрованный траффик - это немного другой вопрос (см. технологию man in the middle например).
Proofreader
01-11-2008, 13:41
Лол, я понял что ты про ссш, я просто спросил зачем?
Например, чтобы боты не долбились туда.
Подобные системы фильтрации смотрят не на порт, а на биты.
Соответственно, режется протокол, а не порт.
А вот если надо мониторить шифрованный траффик - это немного другой вопрос (см. технологию man in the middle например).
Если разрешен https, то ssh сможете отловить только по косвенным признакам.
по мониторингу - мы с Вами не в КГБ и не в Китае.
мы с Вами не в КГБ
Вы действительно уверены в том, что им до Вас дела нет?
Unlimited
01-11-2008, 22:54
Например, чтобы боты не долбились туда.
О, да, наверно тогда стоит и веб сервер на другом порту всегда поднимать! И еще много чего! По той же причине! Имхо бред, никому эти боты не мешают. А сканировать все равно будут юные хакеры а потом по приветствию уже смотреть что куда натравить...
Если разрешен https, то ssh сможете отловить только по косвенным признакам.
по мониторингу - мы с Вами не в КГБ и не в Китае.
Там и прямых признаков достаточно.
А по поводу КГБ - все забыли наверное про мировую практику мониторинга провайдеров государственными разведками? ;)
Ага, то-то админы возрадуются, когда из такой сетки кто-то поднимет шифрованный канал в неизвестном направлении на левом порту...
а одминов это совершенно не должно колебать, это НЕ их проблема...
... это НЕ их проблема...
Управляешь персоналом и знаешь его обязанности?
а одминов это совершенно не должно колебать, это НЕ их проблема...
это более, чем странное заявление...