Jump to content
  • 0

Сканиране на портове с вдигнат флаг URG


Стоян Иванов
 Share

Question

Здравейте. Пиша в темата за за начинаещи, защото съпоставяйки се с голямата част от хората тук, съм по-скоро начинаещ, затова и търся малко помощ от вас.

От известно време наблюдавам странна и завишена активност към единия от микротиците ми. Различното тук спрямо обикновеното порт сканиране е, че не се търсят случайни портове, а приоритетно само тези които се виждат на скрийншота. Също така забелязвам, че част от заявките идват с вдигнат флаг URG - спешно. Този микротик е конфигуриран с два доставчика (load balancing/failover) като зад него има съвсем обичайни неща - видео наблюдения, няколко други микротика с вдигнати L2PT/IPsec тунели, Офис централа за IP телефония на А1, два счетоводни линукс сървъра и тн. Наблюденията ми до тук, поне според мен показват че атаката е насочена или към  VoIP STUN (Session Traversal Utilities for NAT) port. It operates on port 3478 TCP/UDP, may also use port 19302 UDP. It is usually supported by newer VoIP devices - където заподозрения е централата на А1
Или към едно UniFi AP-LR, което осигурява WIFI в една заседателна зала.

Ubiquiti UniFi Controller uses these ports:
8080 tcp - http port for UAP to inform controller
8443 tcp - https port for controller GUI/API
8880 tcp - http portal redirect port (may also use ports 8881, 8882)
8843 tcp - https portal redirect port
3478 udp - STUN port (should be open at firewall)
Ubiquiti UniFi Cloud Access uses these ports:
443 TCP/UDP - Cloud Access service
3478/UDP - port used for STUN
8883/TCP - Cloud Access service


Тъй като знам че без предлагане няма и търсене, съм почти убеден че има компрометирано устройство или някаква дупка, която съм пропуснал да запуша. Някой имал ли е подобен проблеми накъде според вас е насочена атаката?
На микротика няма вдигнато прокси и порт 8080 е затворен перманентно от години. Благодаря предварително на отзовалите се.1.thumb.png.d5a34392c0a9db34732a921df973e50a.png

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

  • 0
  • Administrator

Правилата по подразбиране в Филтъра спират такива атаки отмахи,
дори дроп правилата може да се преместят в RAW да не се товари процесора.

Харесай поста ^^^
acer.gif htc.gifsigpic4024_2.gif

Форумът е за взаимопомощ а не за свършване на чужда работа


ɹɐǝɥ uɐɔ noʎ ǝɹoɯ ǝɥʇ 'ǝɯoɔǝq noʎ ɹǝʇǝınb ǝɥʇ

Link to comment
Share on other sites

  • 0

Това са типичните портове на джава базирани сървиси, опитват се да докопат нещо незащитено и експоузнато в интернет. Споко.

  • Like 1
Link to comment
Share on other sites

  • 0

Блгодаря за отговорите. Това е логът на  дроп правило и относно сигурността съм по-скоро спокоен. Всеки ден виждам логове от сканиране по рутерите си и това съм го приел за нормално. Понякога са повече, понякога по-малко, но общо взето са по десетина опита на ден за по няколко минути търсещи на случаен принцип. В случая идват от над четиридесет адреса за 24 часа. И все още не мога да разбера, защо тъпия ботнет реши да сканира точно този адрес ако нищо не го повиква.

Link to comment
Share on other sites

  • 0

Не е само при теб така. Винаги поне при нас в било на приливи и отливи. Има дни когато ги "мързи" но после си наваксват.

Analog Audio™

Link to comment
Share on other sites

  • 0

Това са моите правила за блокиране на сканирането на портове:

 2    ;;; Port scanners to list
      chain=input action=add-src-to-address-list protocol=tcp psd=21,3s,3,1
      address-list=port-scanners-wan address-list-timeout=2w log=no
      log-prefix="port-scan"

 3    ;;; NMAP FIN Stealth scan
      chain=input action=add-src-to-address-list
      tcp-flags=fin,!syn,!rst,!psh,!ack,!urg protocol=tcp
      address-list=port-scanners-wan address-list-timeout=2w log=no
      log-prefix=""

 4    ;;; SYN/FIN scan
      chain=input action=add-src-to-address-list tcp-flags=fin,syn protocol=tcp
      address-list=port-scanners-wan address-list-timeout=2w log=no
      log-prefix=""

 5    ;;; SYN/RST scan
      chain=input action=add-src-to-address-list tcp-flags=syn,rst protocol=tcp
      address-list=port-scanners-wan address-list-timeout=2w log=no
      log-prefix=""

 6    ;;; FIN/PSH/URG scan
      chain=input action=add-src-to-address-list
      tcp-flags=fin,psh,urg,!syn,!rst,!ack protocol=tcp
      address-list=port-scanners-wan address-list-timeout=2w log=no
      log-prefix=""

 7    ;;; ALL/ALL scan
      chain=input action=add-src-to-address-list
      tcp-flags=fin,syn,rst,psh,ack,urg protocol=tcp
      address-list=port-scanners-wan address-list-timeout=2w log=no
      log-prefix=""

 8    ;;; NMAP NULL scan
      chain=input action=add-src-to-address-list
      tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg protocol=tcp
      address-list=port-scanners-wan address-list-timeout=2w log=no
      log-prefix=""

 9    ;;; dropping port scanners
      chain=input action=drop src-address-list=port-scanners-wan log=no
      log-prefix="WAN scan"


Правилата добавят атакуващите към списък с адреси и последното правило блокира всички от този адресен списък.

Повторил съм същите правила и за chain "forward".

Link to comment
Share on other sites

  • 0
  • Administrator

DROP правилото се слага над маркиращите правила, за да не маркираш многократно вече маркиран трафик.

Не е нужно процесора да се товари безцелно.

Харесай поста ^^^
acer.gif htc.gifsigpic4024_2.gif

Форумът е за взаимопомощ а не за свършване на чужда работа


ɹɐǝɥ uɐɔ noʎ ǝɹoɯ ǝɥʇ 'ǝɯoɔǝq noʎ ɹǝʇǝınb ǝɥʇ

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.