Ошибки в cisco из-за нехватки памяти (следствие DDoS)
 |
В одной из моих организаций в роли пограничного маршрутизатора выступает устройство Cisco 2821 (revision 53.50) с IOS c2800nm-adventerprisek9_ivs-mz.124-24.T8.bin на борту. Внутренних сетей несколько (если быть точным – четыре штуки), плюс на ней же поднят сервис ip-телефонии. В один прекрасный день заметил, что данная cisco перестает отвечать на какие-либо запросы, а в логах на внешнем сервере логирования появляются ошибки о нехватке памяти. |
Ошибки примерно вот такого содержания:
019116: .Apr 23 12:42:55: %SYS-2-MALLOCFAIL: Memory allocation of 32768 bytes failed from 0x4015AA40, alignment 4 Pool: Processor Free: 277532 Cause: Memory fragmentation Alternate Pool: None Free: 0 Cause: No Alternate pool -Process= "DNS Server Input", ipl= 0, pid= 347, -Traceback= 0x401233F0z 0x4013D5D4z 0x40158E48z 0x41CD50D8z 0x41CD58D0z 0x435CD514z 0x435CD4F8z 019174: .Apr 23 12:42:56: %SYS-2-CHUNKEXPANDFAIL: Could not expand chunk pool for ipnat entry. No memory available -Process= "Chunk Manager", ipl= 4, pid= 1, -Traceback= 0x40155D8Cz 0x435CD514z 0x435CD4F8z 020605: .Apr 23 12:43:23: %DNSSERVER-3-UDPDNSOVERLOAD: Low available memory: dropping <id# 36844> from <cli 10.10.10.160>.
Сама cisco выполняет очень разнообразные функции, но до сих пор никаких проблем с нехваткой ресурсов (памяти) не наблюдалось. А тут – даже не может обслужить dns запрос…
Решил выяснить, чем же устройство занято в настоящее время. Как оказалось, оно нагружено sip запросами, причем “по полной”:
router#sh proc cpu sort | ex 0.00 CPU utilization for five seconds: 98%/93%; one minute: 92%; five minutes: 87% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 231 9732 2750 3538 73.27% 68.28% 62.22% 0 CCSIP-REGISTER 319 11060 3385 3267 16.34% 15.50% 22.60% 0 CCSIP_SPI_CONTRO 321 6348 2703 2348 8.05% 7.52% 1.37% 0 CCSIP_UDP_SOCKET
Как оказалось, несмотря на то, что в конфигурационном файле настройки на cisco для ip-телефонии явным образом указаны ip адрес (одной из внутренних сетей) и порты для работы сервисов Cisco Call Manager Express и Cisco Unified Communications Manager Express, эти порты стали автоматически доступны и из сети интернет (на внешнем интерфейсе).
Настройки в cisco для CME:
voice register global
mode cme
source-address 192.168.100.2 port 5060
max-dn 20
max-pool 10
timezone 32
time-format 24
date-format D/M/Y
create profile sync 2390165273445357
user-locale RU
Настройки в cisco для UCME:
telephony-service
no auto-reg-ephone
max-ephones 15
max-dn 30
ip source-address 192.168.100.2 port 2000
no caller-id name-only
service phone videoCapability 1
timeouts interdigit 5
timeouts ringing 30
system message COMPANY
cnf-file location flash:
cnf-file perphone
user-locale RU
network-locale RU
network-locale 1 RU
network-locale 2 RU
network-locale 3 RU
network-locale 4 RU
load 7931 SCCP31.9-2-1S
time-zone 32
time-format 24
date-format dd-mm-yy
max-conferences 4 gain -6
call-forward pattern .T
moh music-on-hold.au
transfer-system full-consult
transfer-pattern .T
create cnf-files version-stamp Jan 01 2002 00:00:00
Сканирование программой nmap внутреннего адреса 192.168.100.2 этой cisco среди прочих обнаружил открытые порты, относящие к ip-телефонии (что и должно быть):
PORT STATE SERVICE 1720/tcp open H.323/Q.931 2000/tcp open cisco-sccp 5060/tcp open sip 5061/tcp open sip-tls
При сканировании nmap-ом внешнего ip показало, что данные порты тоже открыты (чего в принципе не должно быть):
PORT STATE SERVICE 1719/tcp open h323gatestat 1720/tcp open H.323/Q.931 2000/tcp open cisco-sccp 5060/tcp open sip 5061/tcp open sip-tls
Да, не проверил данный момент сразу после настройки ip-телефонии на данной cisco, это моя вина… Прочитав некоторую документацию решил просто закрыть эти порты для доступа к ним “снаружи”. Для этого создал acl с именем BLOCK_VOIP и повесил его, как in, на внешний интерфейс:
interface GigabitEthernet0/0
description INTERNET
ip address 12.34.56.78 255.255.255.240
...
ip access-group BLOCK_VOIP in
...
, где сам acl имеет следующие настройки:
ip access-list extended BLOCK_VOIP deny tcp any any eq 2000 deny udp any any eq 2000 deny tcp any any eq 5060 deny tcp any any eq 5061 deny udp any any eq 5060 deny udp any any eq 5061 deny tcp any any eq 1720 deny udp any any eq 1720 deny tcp any any eq 1719 deny udp any any eq 1719 permit ip any any
повторное сканирование nmap-ом внешнего ip-адреса этой cisco показало, что теперь данные порты отфильтрованы:
PORT STATE SERVICE 1719/tcp filtered h323gatestat 1720/tcp filtered H.323/Q.931 2000/tcp filtered cisco-sccp 5060/tcp filtered sip 5061/tcp filtered sip-tls
Проверка загруженности памяти и процессора cisco сразу же показали о полном исчезновении нагрузки:
router#sh proc cpu sort | sec CCSIP 231 92020 25550 3601 0.00% 0.00% 0.00% 0 CCSIP-REGISTER 319 110540 37169 2973 0.00% 0.00% 0.00% 0 CCSIP_SPI_CONTRO 320 0 1 0 0.00% 0.00% 0.00% 0 CCSIP_DNS 321 61660 25788 2391 0.00% 0.00% 0.00% 0 CCSIP_UDP_SOCKET 322 4 6 666 0.00% 0.00% 0.00% 0 CCSIP_TCP_SOCKET 323 4 14 285 0.00% 0.00% 0.00% 0 CCSIP_TLS_SOCKET
После некоторого времени работы данного acl на внешнем ip показало, что “нехорошие люди” все еще продолжительное время пытались использовать (на сей раз – безуспешно) мой ресурс:
router#sh ip acce | sec BLOCK_VOIP
Extended IP access list BLOCK_VOIP
10 deny tcp any any eq 2000 (67 matches)
20 deny udp any any eq 2000
30 deny tcp any any eq 5060 (82 matches)
40 deny tcp any any eq 5061 (33 matches)
50 deny udp any any eq 5060 (367336 matches)
60 deny udp any any eq 5061 (55 matches)
70 deny tcp any any eq 1720 (77 matches)
80 deny udp any any eq 1720
90 deny tcp any any eq 1719 (27 matches)
100 deny udp any any eq 1719
110 permit ip any any (948094388 matches)
Больше проблем с производительностью на данной cisco не возникало…
Как говорится, первое правило системного администрирования – “никому не верь”, никто не отменял…
