Автор Тема: Смисъл от блокиране на сканирането на портовете  (Прочетена 1562 пъти)

growchie

  • Участник
  • *****
  • Публикации: 582
    • Профил
Почвам да се чудя има ли изобщо смисъл да блокирам порт сканирането при положение, че публичните ми портове така и така трябва да са отворени, а останалите са на дроп. Напълнило се е с всякакви ботове и ми се струва, че е пилеене на ресурс да се опитвам да изследвам и блокирам всеки по отделно и да поддържам списъци вместо да го оставям да си фейват заявките му.
Ако имате някакви други съображения защо би трябвало да блокирам сканирането на общо основание ще ми е интересно да чуя.
Активен

makeme

  • Участник
  • *****
  • Публикации: 486
  • Distribution: Many
  • Window Manager: Mate
    • Профил
Ми презумпцията е, че щом някой сканира портове не ти мисли доброто :)
Смисъл, автоматичните атаки на ботовете, които обикалят нета са последващи на бота, който е минал преди това с порт скана.

Примерно:
Имаш вдигнат уебсървър на порт 80. Да, той е отворен и видим, но бота не знае това преди да го сканира. След като го сканира те слага в списъка с ИП-та, които имат уеб сървър. От там другият бот, който е за дупчене на CMSи минава и се пробва.
И така за всеки сървис на стандартен порт, за който има уязвимости.

Иначе, да, прав си. Ако нямаш от какво да се притесняваш и знаеш, че всичко ти е защитено, няма смисъл. Все пак обаче това си е още едно на защита, а в днешно време не е зле да имаш много.
Активен

Distributions:  UbuntuMate 14.04; 15.10; 16.04, CentOS 6.x, 7.x, Kali 2.0 ...

4096bits

  • Участник
  • *****
  • Публикации: 2737
    • Профил
Както казва и @makeme, трябва да имаш защита на всяко едно ниво, на което можеш да я осигуриш. В днешно време нищо не е достатъчно.
Активен

As they say in Mexico, "Dasvidaniya!" Down there, that's two vidaniyas.

Acho

  • Участник
  • *****
  • Публикации: 3239
  • Distribution: Slackware, MikroTik - сървърно
  • Window Manager: console only
    • Профил
    • WWW
Да си си "вързал гащите" дето се казва. И да си пуснал само това, което наистина ти трябва да се достъпва "отвънка".
Активен

CPU - Intel Quad-Core Q8400, 2.66 GHz; Fan - Intel Box; MB - Intel G41M-T2; RAM - DDR2-800, Kingston HyperX, 2X2048 MB; VC - onboard, Intel G41 Express Chipset; HDD - SeaGate, 160 GB, SATAII; SB - Realtek HD Audio; DVD-RW - TSSTcorp DVD-RW; LAN - Realtek PCI-E GBE Controller; PSU - Fortron 350 Watt.

growchie

  • Участник
  • *****
  • Публикации: 582
    • Профил
Абе и аз така бях решил, но като тръгнах да го реализирам с iptables осъзнах, че ще трябва да поддържам едни списъци, които са видими през /proc/net/xt_recent и като гледам как потенциално биха набъбнали започнах да се притеснявам. На практика като хвана бот трябва да го набутам в един несортиран списък и да започна в началото на инпут веригата да проверявам ВСЯКА нова входяща връзка дали не идва от блокирано айпи. Другото нещо което забелязах, е че файла не се чисти, а просто към айпи-то се добавя сигнатурата за последния пакет и от там се определя и кога за последно е имало връзка от дадения хост.
Нещото от което се опасявам, че след 2-3 месеца списъкът може да набъбне доста и да имам да проверявам в тлъста база всеки път преди да разреша връзка. В действителност, нямам си представа как са реализирани алгоритмите в модула и какво пърформънс пенълти ще се натрупа след известно време. Може и изобщо да не е някакъв проблем.
Активен

nslave

  • Участник
  • *****
  • Публикации: 77
  • Distribution: Fedora / Debian
  • Window Manager: Xfce
    • Профил
Мисля, че ще ти бъде полезно да използваш ipsets. Твърдението е, че е подходящо за големи списъци и когато има притеснения относно производителността.

Edit: Сега се зачетох и поддържа и timeout на записите. Това мисля, че ще ти помогне до някаква степен с това списъка да остане сравнително малък.
« Последна редакция: Ное 21, 2018, 11:15 от nslave »
Активен

growchie

  • Участник
  • *****
  • Публикации: 582
    • Профил
Мисля, че ще ти бъде полезно да използваш ipsets. Твърдението е, че е подходящо за големи списъци и когато има притеснения относно производителността.

Edit: Сега се зачетох и поддържа и timeout на записите. Това мисля, че ще ти помогне до някаква степен с това списъка да остане сравнително малък.

Мерси, ще го погледна това.
Активен

n00b

  • Участник
  • *****
  • Публикации: 1205
  • Distribution: OSX
  • Window Manager: 10.6, 10.8, 10.9
  • Live to hack, hack to live.
    • Профил
Няма да правиш списъци със портовете които да дропиш. Ще направиш списък със портове които ще отвориш - и всичко останало е на дроп.

Примерно така са Амазон и Гогол на облачните услуги. Казваш искам да ми се отворят за ВХОДЯЩИ заявки порт X, Y и Z. Всичко останали под ножа. И е добра стратегия.

Представи си пуснеш за малко един MySQL за да тестваш нещо. И му бутнеш слаба парола. Така младежите ще му се изредят да почукат първо, и после да брутфорснат.

Ако обаче си отворил примерно порт 23 и порт 80 само. MySQL-а ще остане скрит зад firewall правилата и даже никой отвън няма да го види, че е наличен.
Активен

mobilio - професионални мобилни приложения

growchie

  • Участник
  • *****
  • Публикации: 582
    • Профил
Да, аз така го правя, ама искам да блокирам и да съм информиран като някой малоумник реши да се тества да сканира надлъж и нашир. Сега ще тествам тия айпи сет-ове и ще пиша какво съм измислил.
« Последна редакция: Ное 21, 2018, 14:25 от growchie »
Активен

nslave

  • Участник
  • *****
  • Публикации: 77
  • Distribution: Fedora / Debian
  • Window Manager: Xfce
    • Профил
Определено ако няма специфично изискване да са отворени портовете, всеки сървър с директен излъз (пък и не само) към интернет, и според мен трябва да е с default policy на iptables - drop.

Има друго, не знам как действат точно сканиращите. Дали след като сканира, после идва от друг адрес да пробва exploit-и или пак от същият. Ако е така има потенциал да не хванеш нищо.. или поне нищо, което да има значение. С ipset като гледам обаче, можеш бързо да се затвориш по региони. Ако не очакваш трафик от Русия, Китай и подобни.. то съвсем спокойно може да ги отрежеш директно тях :D
Активен

growchie

  • Участник
  • *****
  • Публикации: 582
    • Профил
Целта ми е да блокирам сляпо сканиране на отворени портове. За сега това ми е идеята. Направих 4 сета:
ipset -N banned_hosts iphash
ipset -N second_strike_hosts iphash timeout 30
ipset -N first_strike_host iphash timeout 30
ipset -N retry_hosts hash:ip,port

Направих си верига SCAN_BLOCK която я апенднах към INPUT чейна:
iptables -A INPUT -p tcp -i enp17s10 -m multiport --destination-port 21,23,109,110,445,501,1000,1194,1200 -j SCAN_BLOCK
Примерно няколко портове които да са хем смесени стандартни върху които нямам услуги, хем нестандартни да подбера ако някой е решил да жъне наред.

SCAN_BLOCK веригата ми съдържа следното:

iptables -A SCAN_BLOCK -m set --match-set retry_host src,dst -j DROP
iptables -A SCAN_BLOCK -m set --set second_strike_hosts src -j SET --add-set banned_hosts src
iptables -A SCAN_BLOCK -m set --match-set first_strike_hosts src -j SET --add-set second_strike_hosts src
iptables -A SCAN_BLOCK -j SET --add-set first_strike_hosts src
iptables -A SCAN_BLOCK -j SET --add-set retry_host src,dst
iptables -A SCAN_BLOCK -j DROP

Надявам се че не съм объркал нещо копи/пействах от командния ред.
Идеята е следната, ако някой почне да шава по портовете попада съответно първо в първи списък, после във втори и накрая в перманентния бан. За да не попадне някой който просто ритрайва на порт се наложи да добавя още един временен списък където да пиша айпита и портове. за това са предпоследен и първи ред. Двата списъка за първи и втори страйк таймаутват за 30 секунди.
Перманентният не, както и тия дето жулят на един и същи порт безуспешно.

Това измислих на първо време, после ще оптимизирам. Трябва да измисля как да добавям айпита които пробват произволни глупости по уеб съръва да влизат в банлиста. командата е ясна ipset add нещо си там и айпито.
Активен

n00b

  • Участник
  • *****
  • Публикации: 1205
  • Distribution: OSX
  • Window Manager: 10.6, 10.8, 10.9
  • Live to hack, hack to live.
    • Профил
Да - изглежда 6.

Но според мен лично е губене на време. По-добре направо си ги дропи и без да се занимаваш със анализи. За всичко останало има fail2ban.
Има и по-хардкор варианти на F2B дето направо се банва C-class range за по-удобно.
Активен

mobilio - професионални мобилни приложения

growchie

  • Участник
  • *****
  • Публикации: 582
    • Профил
Знам за fail2ban. Предпочитам нещата свързани с мрежовото филтриране да се случват в кернелспейс.
Иначе горе трябва да се добави и правило за дропване на пакетите идващи от баннатите хостове. Някъде в началото на инпут чейна и при желание във форвард.
Активен

Yasen6275

  • Участник
  • *****
  • Публикации: 454
    • Профил
...Има и по-хардкор варианти на F2B дето направо се банва C-class range за по-удобно.
Което директно те прави уязвим от DoS атака със пакети с подменени адреси.
Активен

Acho

  • Участник
  • *****
  • Публикации: 3239
  • Distribution: Slackware, MikroTik - сървърно
  • Window Manager: console only
    • Профил
    • WWW
А това дето ще се защитава домашна машина ли е ? Или некав фирмен сървър ?
Активен

CPU - Intel Quad-Core Q8400, 2.66 GHz; Fan - Intel Box; MB - Intel G41M-T2; RAM - DDR2-800, Kingston HyperX, 2X2048 MB; VC - onboard, Intel G41 Express Chipset; HDD - SeaGate, 160 GB, SATAII; SB - Realtek HD Audio; DVD-RW - TSSTcorp DVD-RW; LAN - Realtek PCI-E GBE Controller; PSU - Fortron 350 Watt.