Uwielbiam wprost firmy trudniące się bezpieczeństwem, które skanują porty serwerów. Zapewne robią to w celu poszukiwania luk w zabezpieczeniach, by następnie zaoferować firmom swoje usługi. Tak prawdopodobnie działa RiskIQ w sieci Zayo: 64.125.239.0/24, które powoli testuje porty serwerów.
Do zablokowania: 64.125.239.0/24
Maszyny w całej puli adresowej 64.125.239.0/24 wyszukują otwarte porty. Akcja jest raczej skoordynowana, żaden z portów nie pojawia się dwa razy.
Dowód:
Apr 4 22:36:15 kernel: [4089881] TCP: [64.125.239.76]:43673 to [10.10.10.102]:6379 tcpflags 0x2<SYN> Apr 5 03:34:21 kernel: [4107767] TCP: [64.125.239.57]:46590 to [10.10.10.102]:79 tcpflags 0x2<SYN> Apr 5 09:03:31 kernel: [4127515] TCP: [64.125.239.120]:56702 to [10.10.10.102]:1434 tcpflags 0x2<SYN> Apr 5 10:17:58 kernel: [4131982] TCP: [64.125.239.136]:33224 to [10.10.10.102]:109 tcpflags 0x2<SYN> Apr 5 10:51:19 kernel: [4133983] TCP: [64.125.239.152]:52050 to [10.10.10.102]:110 tcpflags 0x2<SYN> Apr 5 15:55:20 kernel: [4152224] TCP: [64.125.239.164]:38315 to [10.10.10.102]:79 tcpflags 0x2<SYN> Apr 5 21:10:02 kernel: [4171106] TCP: [64.125.239.182]:44138 to [10.10.10.102]:443 tcpflags 0x2<SYN> Apr 6 02:38:45 kernel: [4190829] TCP: [64.125.239.106]:44433 to [10.10.10.102]:995 tcpflags 0x2<SYN> Apr 6 04:58:08 kernel: [4199189] TCP: [64.125.239.216]:32809 to [10.10.10.102]:631 tcpflags 0x2<SYN> Apr 6 06:17:23 kernel: [4203944] TCP: [64.125.239.211]:53464 to [10.10.10.102]:3128 tcpflags 0x2<SYN> Apr 6 06:53:40 kernel: [4206121] TCP: [64.125.239.150]:50732 to [10.10.10.102]:515 tcpflags 0x2<SYN> Apr 6 07:30:45 kernel: [4208347] TCP: [64.125.239.129]:40374 to [10.10.10.102]:8140 tcpflags 0x2<SYN> Apr 6 08:36:27 kernel: [4212289] TCP: [64.125.239.120]:51770 to [10.10.10.102]:1900 tcpflags 0x2<SYN> Apr 6 08:39:08 kernel: [4212450] TCP: [64.125.239.213]:47913 to [10.10.10.102]:3389 tcpflags 0x2<SYN> Apr 6 10:26:34 kernel: [4218896] TCP: [64.125.239.230]:56752 to [10.10.10.102]:5900 tcpflags 0x2<SYN> Apr 6 12:25:44 kernel: [4226046] TCP: [64.125.239.88]:37856 to [10.10.10.102]:5903 tcpflags 0x2<SYN> Apr 6 13:27:15 kernel: [4229736] TCP: [64.125.239.170]:33858 to [10.10.10.102]:9200 tcpflags 0x2<SYN> Apr 6 14:28:08 kernel: [4233389] TCP: [64.125.239.208]:49172 to [10.10.10.102]:5901 tcpflags 0x2<SYN> Apr 7 07:55:57 kernel: [4296257] TCP: [64.125.239.57]:59758 to [10.10.10.102]:8123 tcpflags 0x2<SYN> Apr 7 08:20:42 kernel: [4297741] TCP: [64.125.239.214]:57248 to [10.10.10.102]:3306 tcpflags 0x2<SYN> Apr 7 12:31:40 kernel: [4312799] TCP: [64.125.239.39]:37173 to [10.10.10.102]:389 tcpflags 0x2<SYN> Apr 7 13:02:44 kernel: [4314664] TCP: [64.125.239.105]:56755 to [10.10.10.102]:953 tcpflags 0x2<SYN> Apr 7 16:25:45 kernel: [4326844] TCP: [64.125.239.194]:38068 to [10.10.10.102]:2077 tcpflags 0x2<SYN> Apr 7 17:20:28 kernel: [4330127] TCP: [64.125.239.17]:55450 to [10.10.10.102]:17185 tcpflags 0x2<SYN> Apr 7 18:15:09 kernel: [4333408] TCP: [64.125.239.150]:57402 to [10.10.10.102]:11211 tcpflags 0x2<SYN>
Dlaczego zwróciłem uwagę na to skanowanie? Nie podoba mi się w nim przesadnia ostrożność: jeden adres IP próbkuje jeden port o przypadkowej godzinie, a w dodatku robi to z portu klienckiego, jak gdyby użytkownik przez pomyłkę chciał się połączyć z niewłaściwym portem.
Oczywiście może być tak, że RiskIQ zabezpiecza się w ten sposób przed oskarżeniem o skanowanie zabezpieczeń (co może być karalne w niektórych krajach). Mnie jednak takie zachowanie śmierdzi.
Poziom zagrożenia: znikomy, o ile firma jest prawdziwa i nie kłamie na swojej stronie WWW
Zalecana akcja: brak (ale ja zablokowałem na firewallu zakres 64.125.239.0/24)
Do kogo należy pula adresów IP 64.125.239.0/24?
Z użyciem polecenia whois możemy sprawdzić, że pula adresów 64.125.239.0/24, w skład której wchodzi powyższe IP należy do Zayo IP Engineering, a dwa czterobitowe zakresy 0-127 i 128-255 wykorzystywane są przez RiskIQ.
Co się stanie po zablokowaniu?
Nie będziesz mógł otrzymać oferty zabezpieczenia Twojej firmy przez RiskIQ.
