Перейти до

Подбор ssh китайцами


Рекомендованные сообщения

Случайно глянул auth.log на сервере, мне стало плохо. В день по 10 раз долбятся китайские друзья с разных айпи с перебором пароля.

Кто, как с этим борется?

Ссылка на сообщение
Поделиться на других сайтах

А еще лучше - фаерволом доступ только со своей автономки и управляющего влана.

я так и делаю обычно. ) Но вот недавно открывал и забыл закрыть. И потом афигел. 10 раз не в сутки а в минуту. Но не подобрали )

Ссылка на сообщение
Поделиться на других сайтах

 

А еще лучше - фаерволом доступ только со своей автономки и управляющего влана.

я так и делаю обычно. ) Но вот недавно открывал и забыл закрыть. И потом афигел. 10 раз не в сутки а в минуту. Но не подобрали )

 

китайцев миллиарды, больше чем IP :)

Ссылка на сообщение
Поделиться на других сайтах

Стандартные правила безопасности, при их соблюдении дают практически абсолютную надежность.

1) Не давать доступ отовсюду фаерволом. Все равно остается возможность атаки внутри сети через уязвимость любого другого сервера/клиента, но осуществить её уже сложнее на порядок.

2) Запретить root-доступ. Угадать имя юзера с паролем, а затем и рутовский пароль сложнее на много порядков.

3) Использовать хорошие пароли, минимум 8 символом, со случайным набором символов.

Ссылка на сообщение
Поделиться на других сайтах

Стандартные правила безопасности, при их соблюдении дают практически абсолютную надежность.

1) Не давать доступ отовсюду фаерволом. Все равно остается возможность атаки внутри сети через уязвимость любого другого сервера/клиента, но осуществить её уже сложнее на порядок.

2) Запретить root-доступ. Угадать имя юзера с паролем, а затем и рутовский пароль сложнее на много порядков.

3) Использовать хорошие пароли, минимум 8 символом, со случайным набором символов.

Это фантазии, очень далекие от реальности.

 

---

Подбор паролей проще всего закрыть через /etc/hosts.allow вместо фаервола. Добавляете туда свои подсети и закрываете sshd для всех, например:

sshd : 1.2.3.4  5.6.7.8 : allow
sshd : 62.149.0.0/255.255.224.0 : allow
sshd : ALL : deny
Ссылка на сообщение
Поделиться на других сайтах

года 4 назад одному товарищу ломанули. Я ему готовил тазик. Пока приготавливал, пока интегрировал, пока показывал-рассказывал, то был пароль root'a 123456789 )) . Расставаясь, я ему указал на угрозы и на необходимость задать пароль для рута. Я не люблю знать чужие пароли, по этому сам менять не стал. Но чел. проигнорировал и через 3 дня этот парольчик подобрали и сменили. Звонил кричал караул шо делать )) Но кроме смены пароля ничего не порушили. Я приехал, восстановил и с тех пор человек знает,  что так делать низя )

Ссылка на сообщение
Поделиться на других сайтах

 

Стандартные правила безопасности, при их соблюдении дают практически абсолютную надежность.

1) Не давать доступ отовсюду фаерволом. Все равно остается возможность атаки внутри сети через уязвимость любого другого сервера/клиента, но осуществить её уже сложнее на порядок.

2) Запретить root-доступ. Угадать имя юзера с паролем, а затем и рутовский пароль сложнее на много порядков.

3) Использовать хорошие пароли, минимум 8 символом, со случайным набором символов.

Это фантазии, очень далекие от реальности.

 

---

Подбор паролей проще всего закрыть через /etc/hosts.allow вместо фаервола. Добавляете туда свои подсети и закрываете sshd для всех, например:

sshd : 1.2.3.4  5.6.7.8 : allow
sshd : 62.149.0.0/255.255.224.0 : allow
sshd : ALL : deny

Тоже самое можно сделать в iptables, с тем же результатом.

Ссылка на сообщение
Поделиться на других сайтах

смена стандартного порта решает 99 % проблем

Конкретно эта штука начинает свое повествование со сканирования портов. Где-то в гуглах можно много о ней нарыть.

 

У кого нибудь подобрали пароль сложнее qwerty и 123456?

Ну они там порядка десятка тысяч комбинаций пробуют годами, конечно подобрали и троян залили.

 

Тоже самое можно сделать в iptables, с тем же результатом.

На линуксах на голом железе мир клином не сошелся. В линуксах без файрволов или в openvz, lxc контейнерах тоже есть openssh. И неожиданно там обычно работает /etc/hosts.allow и нет доступа к фаерволу.

 

Но не в этом проблема, а в уверенностях в безопасности.

Ссылка на сообщение
Поделиться на других сайтах

А хіба не найкраща рекомендація використання ключів а не паролів?

Доречі, доволі давно до телнету (мабуть китайці) підібрали пароль 8-символьний абсолютно випадковий.

Ссылка на сообщение
Поделиться на других сайтах

И сервер отключить. На всякий случай - из розетки.

Зачем? Для начала просто от интернет сети :)  Пущай себе в розетке кипит :D

Ссылка на сообщение
Поделиться на других сайтах

Доречі, доволі давно до телнету (мабуть китайці) підібрали пароль 8-символьний абсолютно випадковий.

А 18 знаков, не было случаев ? Ну вот типа такой  ;) 

us7lv4ef7jpsfbg3ey 

Ссылка на сообщение
Поделиться на других сайтах

Была такая проблема с полгода назад на сервер по ssh практически не реально было попасть, только ещё и на сайт ДДОСили, fail2ban всё решил!

Ссылка на сообщение
Поделиться на других сайтах

... и отключить ssh вообще ))

Не поверите, так и делают :)

Где-нибудь в налоговой стоят хэдлесс линуксы с единственным запущенным приложением, никаких ssh, ниче вообще, ибо риск.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від fet4
      Добрый день.
      У кого есть практика доступа к bdcom olt по ключу через ssh ?
    • Від Cvan
      Слышал от своих знакомых, что когда они ставили на клиентские антенны (ЭирГрид - например) галочку "SSH Server", то после этого у клиентов глючил вход в инет: то скорость падала, то вообще не заходило. После отключения SSH  - всё ставало на свои места. Кто-то встречался с такой ситуацией?
    • Від TET
      Помогите решыть проблему. Предистория - есть два сегмента сети соеденены мостом из наносов м2 (192.168.1.50 и 192.168.1.51), причем обое в одной подсети. Шлюз в интернет (192.168.1.1) находится в первой подсети, там же и dhcp (192.168.1.1) сервер. Проблема заключается в том что в здании где нахится сегмент 1 иногда вырубают електричество и как презультат клиеты в сегменте 2 не получают адреса.
      Вопрос возможно ли с помошью SSH запустить dhcp сервер на нанос м2 (192.168.1.51) (та что во втором сегменте): вариант 1) если точка (наносм2) в режме бриджа (тат как ето работает на некоторых точках доступа тп-линк), вариант 2)в режиме роурера (лан0 нто wan (не трогаем), а lan1 и wlan - сеть) но тут проблема в том что в веб меню AirOS не дает выбрать на какой имено шглюз и DNS будет раздавать DHCP и клиентам выдает 192.168.1.51 вместо 192.168.1.1?
      Идея заключается в том чтобы клиенты продолжали роботу друг с другом даже после отвала DHCP сервера.
      P.S. Надо чтоб обязательно был DHCP
      И еще вопрос возможно ли с помошью SSH сделать что б в Airrouter радио таботало по расписанию (к примеру с 8,00 по 17,00)?
    • Від fulls
      Добрый день. Извините может нубский вопрос, но как изменить частоту на устройствах Ubiquiti через SSH или Telnet? Заранее благодарен за ответы.
    • Від qwerty
      Здравствуйте, подключаюсь на микротик по ssh ключу(без ввода пароля), далее задача подключится  на rocket тоже посредством ssh, клиент на микротике как я понял не поддерживает передачу пароля как параметра(впрочем как и везде)? скопировать что либо я не могу так как файловая система только для чтения.. нашел файл  /usr/etc/secret.key  но там указано что это  rsa ключ, попробовал этот ключ закинуть на микротик и прикрепить к пользователю но микротик говорит что ему нужен только dsa. Как быть? задача подключится на рокету а там уже без разницы по ssh или telnet(поставлю сложный пароль хацкеров вроде пока нет) главное без ввода пароля, так как это подключение будет выполняться из php скрипта.
×
×
  • Створити нове...