Una guía práctica para limitar el ancho de banda en QRadar

El gestor de ancho de banda de IBM® QRadar ® aprovecha la disciplina de colocación en cola de grupo de señales jerárquico (HTB) que se ofrece en el kernel Linux . Para un uso específico o más avanzado, hay muchas páginas en Internet que describen qué es y cómo funciona, incluyendo:

Nota: Este artículo del blog técnico es as-is y no pasó por ningún examen extra.

Antes de empezar, tendrá que ajustar primero el archivo bandwidthManagerCLI.sh para cambiar la ubicación de buildcpath . Para editar el archivo bandwidthManagerCLI.sh , escriba edit /opt/qradar/bin/bandwidthManagerCLI.sh. Cambie la tercera línea del archivo para que sea /opt/qradar/systemd/bin/buildcpath. Guarde y cierre el archivo.

Ayuda y uso de ancho de banda

El siguiente fragmento de código lista el uso del Gestor de ancho de banda:

[root@m5arch06 ~]# /opt/qradar/bin/bandwidthManagerCLI.sh
usage: BandwidthManagerCLI -a <ACTION>
          -a,--action The desired action. Recognized Actions: help, add_class, add_egress_filter,
                      delete_class, delete_egress_filter
usage: add_class <OPTIONS>
          -i,--hostID    The managed host ID which uniquely identifies the host. You can optionally
                         use '-1' to indicate you wish this to be applied to all hosts in the deployment
          -n,--name      A user-friendly name for the new configuration
          -c,--classID   The desired class ID of the class to be added
          -d,--device    The device name (e.g. eth0) which this configuration will apply to. You can
                         optionally use '*' to indicate you wish to be applied to all devices
          -h,--hostname  The managed host host name. Can be used when you don't provide the host ID
          -k,--kbpsLimit The rate limit to be applied against the class in kilobytes/sec
          -p,--parentID  The parent ID for this class
          -q,--qdiscID   The desired queuing discipline ID of the egress filter to be added
usage: add_egress_filter <OPTIONS>
          -i,--hostID           The managed host ID which uniquely identifies the host. You can
                                optionally use '-1' to indicate you wish this to be applied to all hosts in the deployment
          -n,--name             A user-friendly name for the new configuration
          -P,--protocol         The protocol for the new configuration
          -d,--device           The device name (e.g. eth0) which this configuration will apply to.
                                You can optionally use '*' to indicate you wish to be applied to all devices
          -dc,--dstCIDR         [Optional] The destination CIDR for the egress filter
          -dport,--dstPort      [Optional] The destination port for the egress filter
          -dportm,--dstPortMask [Optional] The destination port mask for the egress filter. If not
                                provided, 0xffff will be used (meaning match only that port)
          -f,--filterID         The desired filter ID to be assigned to the new egress filter
          -fl,--flowID          The filter's target flow ID (which represents the minor ID of a
                                class or qdisc). Traffic matched by this filter with go to that location
          -fp,--filterPriority  The fitler's priority relative to others attached to the same parent
                                (lower number is higher priority)
          -h,--hostname         The managed host host name. Can be used when you don't provide the
                                host ID
          -ma,--matchAll        [Optional] If "true", the filter that is created will match *all*
                                incoming packets at its priority level.
          -p,--parentID         The parent ID for this egress filter
          -q,--qdiscID          The desired queuing discipline ID of the egress filter to be added
          -sc,--sourceCIDR      [Optional] The source CIDR for the egress filter
          -sport,--srcPort      [Optional] The source port for the egress filter
          -sportm,--srcPortMask [Optional] The source port mask for the egress filter. If not
                                provided, 0xffff will be used (meaning match only that port)
usage: delete_class <OPTIONS>
          -i,--hostID   The managed host ID which uniquely identifies the host. You can optionally
                        use '-1' to indicate you wish this to be applied to all hosts in the deployment
          -c,--classID  The class ID to class to delete
          -d,--device   The device name (e.g. eth0) of the configuration to be deleted
          -h,--hostname The managed host host name. Can be used when you don't provide the host ID
          -q,--qdiscID  The queuing discipline ID of the class you wish to delete
usage: delete_egress_filter <OPTIONS>
          -i,--hostID   The managed host ID which uniquely identifies the host. You can optionally
                        use '-1' to indicate you wish this to be applied to all hosts in the deployment
          -d,--device   The device name (e.g. eth0) of the configuration to be deleted
          -f,--filterID The filter ID of the filter to delete
          -h,--hostname The managed host host name. Can be used when you don't provide the host ID
[root@m5arch06 ~]#

Terminología

Este Disciplina de o HTB le permite definir las propiedades de las señales y el grupo que se utilizan. (No tenemos que preocuparnos por este mecanismo).

Clases: Definir trozos de ancho de banda-mínimos y máximos. Están dispuestos en una estructura de árbol. Por ejemplo, tiene un enlace de 10 Mbit que se comparte entre QRadar y otras aplicaciones. Desea asegurarse de que QRadar nunca utilice más de 5 Mbit/seg, por lo que no saturará el enlace. Define una clase para todo el tráfico que está limitado a 5 Mbit/seg y, a continuación, puede subdividir más para que la réplica de PostgreSQL no afecte al rendimiento de la búsqueda.

Filtros: Seleccione el tráfico de red que se coloca en cada uno de estos Clases. Típicamente hecho por las combinaciones IP/protocol/puerto, los filtros son notablemente flexibles y permiten una granularidad muy fina-para nuestros propósitos, nos quedaremos con las simples combinaciones IP/protocol/puerto.

Libro de cocina-Ejemplos

Todos los mandatos se ejecutan en la consola: no es necesario que se ejecute en un host gestionado. Puede especificar a qué host aplicar el cambio en la línea de mandatos de bandwidthManagerCLI.sh .

Ejemplo: Desconexión de réplica en un host (todo el puerto 443-suponiendo que no se haya cifrado)

En este ejemplo, creamos una clase en la que limitamos el ancho de banda a 10 Kbps. A continuación, creamos filtros para correlacionarlos con esa clase. Queremos limitar estos filtros específicamente al puerto de origen 443 (porque es la consola) y a la IP de destino 192.0.2.0 (el host gestionado en este caso). El nombre de host de la consola es m5arch06.

/opt/qradar/bin/bandwidthManagerCLI.sh -a add_class -h m5arch06 -n SlowReplication -c 1 -q 30 -p 0 -k 10 -d eno1
/opt/qradar/bin/bandwidthManagerCLI.sh -a add_egress_filter -h m5arch06 -n MatchHttps -d eno1 -dc 192.0.2.0/32 -f 2 -fl 1 -fp 1 -p 0 -q 30 -sport 443 -P tcp
/opt/qradar/bin/bandwidthManagerCLI.sh -a add_egress_filter -h m5arch06 -n MatchHttps -d eno1 -dc 192.0.2.0/32 -f 3 -fl 3 -fp 1 -p 0 -q 1 -sport 443 -P tcp

Para probar esto, hemos forzado la réplica en el host gestionado para solicitar un vuelco de base de datos completo y hemos finalizado con los resultados siguientes:

….
  2750K .......... .......... .......... .......... ..........  4% 9.02K 1h45m
  2800K .......... .......... .......... .......... ..........  4% 9.68K 1h45m
  2850K .......... .......... .......... .......... ..........  4% 9.51K 1h45m
  2900K .......... .......... .......... .......... ..........  4% 8.14K 1h45m
  2950K .......... .......... .......... .......... ..........  5% 9.00K 1h45m
  3000K .......... .......... .......... .......... ..........  5% 9.00K 1h45m
  3050K .......... .......... .......... .......... ..........  5% 9.99K 1h44m
…..

Las tarifas son aproximadamente (y no exceden) 10 Kbyte/segundo.

Para probar y ver si la regulación está teniendo lugar en la consola, mire la salida de la clase que configuramos:

[root@m5arch06 ~]# tc -s class ls dev eno1 classid 30:1
class htb 30:1 root prio 1 rate 80000bit ceil 80000bit burst 1600b cburst 1600b
 Sent 8579563 bytes 7315 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 3p requeues 0
 lended: 4682 borrowed: 0 giants: 0
 tokens: -4730822 ctokens: -4730822

[root@m5arch06 ~]#

Para eliminar las reglas de ancho de banda, escriba los mandatos siguientes:

/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_egress_filter -h m5arch06 -d eno1 -f 2
/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_egress_filter -h m5arch06 -d eno1 -f 3
/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_class -h m5arch06 -c 1 -q 30 -d eno1

Nota: Sin eliminar las reglas de ancho de banda, estos filtros y clases seguirán siendo persistentes entre rearranques, etc, y QRadar continuará respetándolos a través de parches.

Ejemplo: Limitación de todo el ancho de banda entre la consola y un host gestionado

Estaremos supervisando el ancho de banda en la consola y en la siguiente configuración:

m5arch06 (198.51.100.0) es la consola
m5arch07 (192.0.2.0) es el host gestionado

/opt/qradar/bin/bandwidthManagerCLI.sh -a add_class -h m5arch06 -n SlowCommunicationToHost -c 1 -q 30 -p 0 -k 10 -d eno1

Añada filtros para que coincidan con la disciplina de clases y colas escribiendo el mandato siguiente:

/opt/qradar/bin/bandwidthManagerCLI.sh -a add_egress_filter -h m5arch06 -n MatchToIP -d eno1 -dc 192.0.2.0/32 -f 2 -fl 1 -fp 1 -p 0 -q 30 -P tcp
/opt/qradar/bin/bandwidthManagerCLI.sh -a add_egress_filter -h m5arch06 -n MatchToIP -d eno1 -dc 192.0.2.0/32 -f 3 -fl 3 -fp 1 -p 0 -q 1 -P tcp

Si desea regular el ancho de banda en el host gestionado (observe el cambio en el hostname al que se aplican estos y el CIDR de destino), escriba el mandato siguiente:

/opt/qradar/bin/bandwidthManagerCLI.sh -a add_class -h m5arch07 -n SlowCommunicationToHost -c 1 -q 30 -p 0 -k 10 -d eno1

Añada filtros para que coincidan con la disciplina de clases y colas escribiendo el mandato siguiente:

/opt/qradar/bin/bandwidthManagerCLI.sh -a add_egress_filter -h m5arch07 -n MatchToIP -d eno1 -dc 198.51.100.0/32 -f 2 -fl 1 -fp 1 -p 0 -q 30 -P tcp
/opt/qradar/bin/bandwidthManagerCLI.sh -a add_egress_filter -h m5arch07 -n MatchToIP -d eno1 -dc 198.51.100.0/32 -f 3 -fl 3 -fp 1 -p 0 -q 1 -P tcp

Por último, para suprimir de la consola y del host gestionado, escriba el mandato siguiente:

/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_egress_filter -h m5arch06 -d eno1 -f 2
/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_egress_filter -h m5arch06 -d eno1 -f 3
/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_class -h m5arch06 -c 1 -q 30 -d eno1

/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_egress_filter -h m5arch07 -d eno1 -f 2
/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_egress_filter -h m5arch07 -d eno1 -f 3
/opt/qradar/bin/bandwidthManagerCLI.sh -a delete_class -h m5arch07 -c 1 -q 30 -d eno1

Ejemplo: Añadir los cambios mediante SQL y pochear Mbeans para que los cambios entren en vigor (un poco más rápido y más scriptable)

Este ejemplo utiliza la misma configuración que en el primer ejemplo, pero insertamos en PostgreSQL en lugar de esperar a que el gestor de ancho de banda inicialice las infraestructuras y haga todo lo que pueda.

Hay dos tablas relevantes para la configuración del gestor de ancho de banda:

La tabla bandwidth_configuration contiene toda la información de clase/ancho de banda:

qradar=# \d bandwidth_configuration

Table "public.bandwidth_configuration"
     Column     |          Type          |                             Modifiers                             
----------------+------------------------+------------------------------------------------------------
 sequenceid     | bigint                 | not null default nextval('bandwidth_configuration_seq'::regclass)
 appname        | character varying(100) | not null
 mh_id          | bigint                 | not null
 device         | character varying(100) | not null
 qdisc_id       | integer                | not null
 class_id       | integer                | not null
 parent_id      | integer                | not null
 bandwidth_kbps | bigint                 | not null
 created_by     | character varying(100) |

El bandwidth_egress_filter contiene todos los filtros:

qradar=# \d bandwidth_egress_filter

Table "public.bandwidth_egress_filter"
     Column      |          Type          |                             Modifiers                             
-----------------+------------------------+-----------------------------------------------------------
 sequenceid      | bigint                 | not null default nextval('bandwidth_egress_filter_seq'::regclass)
 appname         | character varying(100) | not null
 mh_id           | bigint                 | not null
 device          | character varying(100) | not null
 qdisc_id        | integer                | not null
 parent_id       | integer                | not null
 filter_id       | integer                | not null
 flow_id         | integer                | not null
 filter_priority | integer                | not null
 src_port        | integer                |
 src_port_mask   | integer                |
 src_cidr        | character varying(45)  |
 dst_port        | integer                |
 dst_port_mask   | integer                |
 dst_cidr        | character varying(45)  |
 match_all       | boolean                | not null default false
 created_by      | character varying(100) |
 protocol        | character varying(4)   |

Utilizando la configuración de ejemplo 1, terminamos con SQL que parece el siguiente fragmento de código:

INSERT INTO bandwidth_configuration (appname, mh_id, device, qdisc_id, class_id, parent_id, bandwidth_kbps, created_by) VALUES ('SlowReplication', 53, 'eno1', 30, 1, 0, 10, 'SQL_Insert');
INSERT INTO bandwidth_egress_filter (appname, mh_id, device, qdisc_id, parent_id, filter_id, flow_id, filter_priority, src_port, src_port_mask, dst_cidr, created_by, protocol) VALUES ('MatchHttps', 53, 'eno1', 30, 0, 2, 1, 1, 443, 65535, '192.0.2.0/32', 'SQL_Insert', 'ip');
INSERT INTO bandwidth_egress_filter (appname, mh_id, device, qdisc_id, parent_id, filter_id, flow_id, filter_priority, src_port, src_port_mask, dst_cidr, created_by, protocol) VALUES ('MatchHttps', 53, 'eno1', 1, 0, 3, 3, 1, 443, 65535, '192.0.2.0/32', 'SQL_Insert', 'ip');

Ahora, hemos personalizado el Mbean y renovamos su configuración:

[root@m5arch06 ~]# /opt/qradar/support/jmx.sh 7778 'com.q1labs.hostcontext.bm:application=hostcontext.hostcontext,type=BandwidthManager' reloadConfig

Invoking operation: reloadConfig ( )
Result: true

[root@m5arch06 ~]#

¡Y voila! La clase ha vuelto:

[root@m5arch06 ~]# tc class ls dev eno1
class prio 1:1 parent 1: leaf 10:
class prio 1:2 parent 1: leaf 20:
class prio 1:3 parent 1: leaf 30:
class prio 1:4 parent 1: leaf 40:
class prio 1:5 parent 1: leaf 50:
class prio 1:6 parent 1: leaf 60:
class prio 1:7 parent 1: leaf 70:
class htb 30:1 root prio 1 rate 80000bit ceil 80000bit burst 1600b cburst 1600b
[root@m5arch06 ~]#

A continuación, se suprimen las entradas de la base de datos y se vuelven a cargar:

[root@m5arch06 ~]# psql -U qradar -c "DELETE from bandwidth_configuration"
DELETE 1
[root@m5arch06 ~]# psql -U qradar -c "DELETE from bandwidth_egress_filter"
DELETE 2
[root@m5arch06 ~]# /opt/qradar/support/jmx.sh 7778 'com.q1labs.hostcontext.bm:application=hostcontext.hostcontext,type=BandwidthManager' reloadConfig

Invoking operation: reloadConfig ( )
Result: true

[root@m5arch06 ~]#

¡Y voila! La clase vuelve a desaparecer:

[root@m5arch06 ~]# tc class ls dev eno1
class prio 1:1 parent 1: leaf 10:
class prio 1:2 parent 1: leaf 20:
class prio 1:3 parent 1: leaf 30:
class prio 1:4 parent 1: leaf 40:
class prio 1:5 parent 1: leaf 50:
class prio 1:6 parent 1: leaf 60:
class prio 1:7 parent 1: leaf 70:
[root@m5arch06 ~]#