Jump to content

Александр Рыжов

Moderators
  • Posts

    1,089
  • Joined

  • Last visited

  • Days Won

    22

Posts posted by Александр Рыжов

  1. Хорошо бы не забывать, что прокси  — это откровенный костыль, которого в идеале быть просто не должно. Оправдано использование проксика (почти) исключительно в корпоративной среде, где используются средства фильтрации и скорее всего не используется кинетик. В частности в windows, именно по этой причине всё больше программ используют общесистемные настройки прокси, а возможности его конфигурирования сокращены до перечня исключений.

  2. Именно поэтому и уточнял, потому что мне до сих пор непонятно: зачем между роутером и NAS'ом два гигабита, если дальше все соединения (все два:)) будут не шире одного гигабита.

    Отказоустойчивость, т.е. недоверие гигабитному кабелю? Тоже не понятно, простите. К клиентам дальше будет идти по одному вместо пары.

  3. 1 минуту назад, Keenetic сказал:

    Так как между NAS и роутером KN-1810 самое узкое место - гигабитный сосок, то Link Aggregation это выход с ситуации «узкого горлишка».

    Link Aggregation увеличивает пропускную способность NAS с помощью объединения нескольких сетевых интерфейсов и обеспечивает переключение трафика для сохранения сетевого соединения в случае его потери

    Даже если считать гигабит NAS-роутер узким горлышком и устранить его агрегацией, то что делать с клиентами? Подразумевается агрегация оставшихся двух LAN-портов?

     

    В 29.08.2017 в 14:32, vasek00 сказал:

    Утилиту управления можно будет использовать ifenslave (пока ее там нет в Entware-3х но https://github.com/Entware-ng/entware-oldpackages-ports )

    Добавлять не станем: ifenslave использовалась на ядрах 2.6 и безнадёжно устарела. Функционал перенёс в iproute2 с 2011-го года.

  4. 26 минут назад, Keenetic сказал:

    Будет подключатся NAS DS718+

    Это необходимо для того, чтобы передавать по гигабиту одновременно в каждый из оставшихся двух Ethernet-портов, верно?

    Просто выгода от bonding'а при наличии всего четырёх Ethernet-портов как-то не очевидна, а то и вовсе на гране здравого смысла.

  5. 1 час назад, Exrector сказал:

    Нужен. Хотя бы для того чтобы установить homebridge и привязать все устройства в доме

    Он на node.js написан, поэтому на кинетик его добровольно разработчики не добавят.

  6. Запросто может быть из-за перебоев питания. Если роутер не подключен к бесперебойке, то я бы не стал на него складывать сколь-нибудь значимую информацию.

    Полезно будет заглянуть в системный лог для выяснения обстоятельств.

  7. 21 час назад, keenet07 сказал:

    Хорошо. Я понимаю, что полноценного фаервола и IDS из роутера пока скорее всего не выйдет. Отбросим это. Но вторую часть просьбы вполне можно реализовать. Не называть это громкими словами "Форпост безопасности". Выделить страничку где будут фиксироваться сообщения о попытках ввода неверного пароля в админку, к WiFi и к другим сервисам роутера.

    Чтоб тут же была гибкая настройка политики для этих событий. Допустим какое-то вол-во попыток за какое-то время зарегистрировать, как попытку перебора. И выбор действий. Просто уведомить, либо бан IP на выбранный срок, либо бан MAC если это исходит из WIFI или локалки. Возможность как-то просигнализировать об этом админу. Либо алерт, либо mail, мигание светодиода.

    Всё это реализовано без дополнительной веб-странички и отлично работает. И в логе посмотреть можно и подкрутить при желании.

    Повторюсь, что вы будете делать с собранной информацией? Как вы отреагируете на десять попыток подбора пароля из Эфиопии? Просто интересны дальнейшие действия.

  8. Влезу в старый топик.

    В 13.01.2019 в 02:17, keenet07 сказал:

     А как вы смотрите на то, чтобы сделать в web-интерфейсе роутера дополнительный подраздел, что-то вроде "Отчеты безопасности" где собирать и выводить какую-то статистику например по произведенным на роутер сетевым атакам со стороны WAN, выводить отчеты по попыткам сканирования какого-либо перечня опасных портов? А также выводить там все попытки перебора пароля в админку и к другим службам роутера. Попытки перебора паролей Wi-Fi. Ну и конечно же сделать удобный способ бана этих адресов, как в автоматическом, там и в ручном режиме. Этакий форпост безопасности будет. Думаю железо это не нагрузит. А фишка у роутера офигенная будет. Сразу его на голову выше аналогов поднимет.

    Нет, это НЕ будет форпостом безопасности, это будет просто красивая страница отчётности с некоторой информацией, с которой в большинстве случаев непонятно как распоряжаться. К примеру, как вы будете себя вести узнав о нескольких сегодняшних атаках на SSH из Китая?

    В роутере нет полноценных универсальных средств фиксирования вторжения (IDS), есть защита двух-трёх сервисов от перебора паролей. Можете оценить ресурсоёмкость и быстродействие IDS, установив из пакетов suricata, считающуюся легковесной.

    В роутере нет по умолчанию нет никакого файервола (дажe SPI) при обращении из домашнего сегмента, в котором «светятся», напомню, большинство сервисов, лакомых для атак, как-то SAMBA, DLNA, UPNP, FTP, lrp/p9100nd и прочая и прочая.

     

    А в итоге будет так: пользователи действительно будут считать эту страницу форпостом, сильно обижаясь в случаях, когда она не сработала в соответствии с ожиданиями.

    IMHO, лучше тратить ресурсы на повышение безопасности отдельных сервисов, чем вешать иконку на торпедо.

    • Thanks 3
    • Upvote 2
  9. Почему в начало? Посмотрите как это сделано в том же Debian файлом patches\Set-systemwide-default-settings-for-libssl-users.patch

    В PHP-скриптах оставьте вместо "tlsv1.2" просто "tls".

    Придётся последовательно разбираться в вопросе, потому что если копипастить без понимая, то ничего не выйдет.

  10. 3 часа назад, Илдар сказал:

    Не очень понятно, почему вопрос конфигурирования OpenSSL, если другие утилиты, его использующие (curl например) коннектятся корректно.

     Я в душе́ не знаю почему на предложение о renegotiation со стороны api.github.com PHP скатывается в TLS1.0, curl так не делает. Если не предлагать renegotiation (что видно в выводе openssl s_client -connect api.github.com:443 -tls1_3), то при указаниии в PHP контекста "tlsv1.3" соединение устанавливается нормально.

    Опциями в /etc/ssl/openssl.cnf Debian запрещает использование всего, что хуже TLS1.2 для всех пакетов системы:

    # System default
    openssl_conf = default_conf
    …
    [default_conf]
    ssl_conf = ssl_sect
    
    [ssl_sect]
    system_default = system_default_sect
    
    [system_default_sect]
    MinProtocol = TLSv1.2
    #CipherString = DEFAULT@SECLEVEL=2

    Этим и пресекаются попытки PHP скатиться в TLS1.0. Аналогичные правки вы можете сделать и на Entware.

     

×
×
  • Create New...