The Daily Shaarli

You can manually map a normalized or raw event to a high-level and low-level category (or QID).

Is there a way to test the high-availability (HA) crossover connection?

Event categories are used to group incoming events for processing by IBM® Security QRadar®. The event categories are searchable and help you monitor your network.

What are the sequence of events during an High-Availability (HA) failover and how are these experienced?

QRadar: HA synchronization progress resets to 0%

The version  of the DSA utility differs based Operating systems and appliance Model types. QRadar 7.2.x uses a different build than QRadar 7.3.x.  M3 and M4 appliances use a different build of the DSA than M5+ appliances. This technote lists the builds required for your base Operating and Appliance type.

The PowerShell execution policy is the setting that determines which type of PowerShell scripts (if any) can be run on the system. By default it is set to “Restricted“, which basically means none. However, it’s important to understand that the setting was never meant to be a security control.

Votre environnement Cloud Shell est un conteneur Docker. Le conteneur est démarré par défaut à partir d'une image Docker gérée par Google, mais vous pouvez aussi spécifier une image Docker personnalisée pour votre environnement Cloud Shell. La personnalisation s'effectue en deux étapes :

Localisez une image Docker pertinente. Notre outil Créer une image personnalisée peut créer une image personnalisée standard que vous pouvez utiliser comme point de départ pour votre image.
Modifiez votre environnement afin de référencer l'image souhaitée.

Siphons cookies, exposes internal router & installs web backdoor on locked computers

I provide support for european customers of QRadar and all of the family products (QVM, QRM, QRIF, QNI). Nowadays, I am more IT consultant than Civil engineer (MSc Eng), but I still have great passion for all reinforced concrete construction around the world.

How can you determine the physical specifications of an appliance?

After Administrative actions a "Deploy Changes" may be required. This article provides information on when to either perform a "Deploy" or "Deploy Full Configuration" and their impact on your QRadar services.

What is the impact of initiating a Deploy Full Configuration on QRadar systems?

How do I locate known issues or open defects logged against QRadar?

Administrators looking for the latest firmware downloads can review this page to locate firmware updates for QRadar appliances. The installation instructions include a direct download link to the firmware from IBM Fix Central.

Syslog messages from transit network devices can provide insight into and context for security events that may not be available from other sources. This insight aids in determining the validity and extent of an incident. Within the context of a security incident, administrators can use syslog messages to understand communication relationships, timing, and, in some cases, the attacker's motives and/or tools. These events should be considered complementary and should be used in conjunction with other forms of network monitoring that may already be in place.

In this post my intention is just to give some quick points on QRadar High Availability (HA)

    1.    HA Overview
        -    Uses Primary and Secondary HA hosts
        -    Uses Virtual IPs
        -    Network connectivity is tested via hearbeat (pings) to all managed hosts
        -    HA Can be configured for either  console or managed host
        -    Both devices must have the same versions of the software
        -    Both devices must support the same DSM, scanner and protocols RPMs
        -    Uses data synchronization or shared external storage
        -    Consistency is maintained locally by using Distributed Replicated Block Device (DRDB)
        -    If using external storage data consistency is maintained through iSCSI or Fibre Channel
        -    Data is synchronized in real time
        -    Note: Asset profiler can impact DRDB speed
        -    "/store" partition on secondary is automatically replicated to the secondary host
        -    Ensure min 1 Gbps between primary and secondary HA hosts
        -    Initial synchronization can take greater than 24 hours
            This may be an understatement. I've seen initial synchronization take upwards of 72 hours.
        -    Secondary host goes into "standby" after synchronization
        -    Primary HA hosts status becomes "offline" when restored from a failover
        -    Primary needs to be placed "online" before it becomes active
        -    Disk replication is enabled while primary is "offline"
        -    Post disk failover synchronization is faster
        -    Basically uses deltas
        -     When the primary host is restored, only the data collected by the secondary during the period the primary was unavailable is synchronized
        -    Replacing or reformating the disk on the primary can result in longer synchronization time in the event of a failback
       
       
   
        IP Considerations
            -    Uses Virtual IPs
            -    Needs 3 IP address - VIP, Primary and Secondary
            -    The IP address initially configured on the primary host is automatically made the cluster VIP
            -    A new IP will need to be assigned to the primary once HA configuration is started
            -    Primary host can act as a standby for secondary
            -    VIP is used by a host that has a status of active
            -    All IPs must be in the same subnet
            -    Latency must be less than 2ms for traffic crosing the WAN
           
           
        HA Wizard
            -    Used to configure Primary, Secondary and cluster VIP
            -    Verifies the secondary has a valid HA activation key
            -    Verifies the secondary is not part of an existing HA cluster
            -    Verifies software version is the same on both devices
            -    Verifies external storage (if configured) on primary and then secondary
            -    Verifies both support the same DSM, scanner and protocol RPMS
           
           
        Failover scenarios
            -    Power supply failure
            -    network failure (detected by connectivity tests)
            -    OS malfunction that delays or stops hearbeat tests
            -    RAID failure
            -    Manual failover
            -     Management interface failure on primary hosts
           
            -    Primary does not take back its role as primary in the case of a failover.
            -    Secondary stays as primary while primary acts as standy
            -    Primary must be switched to "active" to take over its role
           
            -    No failover for software errors or disk capacity issues
            -    If both primary and secondary are unable to ping a managed hosts no failover occurs
            -    If primary cannot but secondary can ping a managed host, failover occurs
           
           
       
       
        HA Failover event sequence
            -    File systems are mounted
            -    Management interface alias is created eth0 is eth0:0
            -    VIP is assigned to the alias
            -    QRadar services are started
            -    Secondary connects to console and downloads configuration files
           
           
        Tips for manual synchronization
            -    Ensure primary and secondary hosts are sync'd
            -    Secondary must be in standby
            -    Secondary to offline and power off the primary
            -    DO NOT MANUALLY FORCE FAILOVER DURING PATCHES OR SOFTWARE UPGRADES
                     
       
    2.    HA Planning
        -    File systems on both devices much match - ext-3, etc
        -    Secondary's "/store" partion must be equal to or greater than the primary
        -    Both devices should have the same number of interfaces
        -    Both must use the same management interface
        -    Only 1 VIP
        -    Port 7789 is needed for Distributed Replicated Block Device (DRDB)
        -    DRBD traffic is bidirectional
        -    Disk replication ensures software updates are applied to the secondary
        -    Ensure the host has a valid activation key
       
   
    3.    HA Management
        -    Uses System and License management window to:
            -    monitor HA
            -    Force failover
            -    Disconnect cluster
            -    Modify cluster settings
            -    Modify heartbeat interval
            -    Place the device in "offline" mode before maintenance