для Cisco Cisco ASR 5000

Скачать
Страница из 48
Blacklist Updates
The following steps describe how the blacklist is updated in the system:
Step 1
The WEM downloads the blacklist file from the specified source (NCMEC/IWF/other). NCMEC provides the file in
clear text format which is then converted into a non-human readable optimized format (OPTBLDB), and IWF database
provides the file in OPTBLDB format. The merged OPTBLDB file (NCMEC and IWF) is then pushed to the chassis.
Step 2
The WEM pushes the optblk.bin file to the chassis (to /flash/bl) at pre-determined intervals. The optblk.bin file contains
the full blacklist. If this file is verified to be correct, it replaces the optblk.bin file on the chassis and the last optblk.bin
is rolled over.
Step 3
The blacklist file is auto-detected by the Session Controller (SessCtrl), which verifies the integrity of the Blacklist
database using checksums, and then loads it.
The new blacklist is loaded only if it has been received properly. If the full Blacklist database is not found, corrupted,
or if the loading fails, traps are generated. Correspondingly clear traps are also generated on a valid Blacklist database
being available, and after a successful load.
Step 4
The SessMgrs read the file and load the blacklisted URLs in a local in-memory database.
The URL Blacklisting feature is enabled only if the url-blacklisting action is set in any of the rulebases.
Thus, the automatic detection of the Blacklist database, storing it in memory, and loading onto the SessMgrs
will happen only if the url-blacklisting action is set in any of the rulebases.
Important
Step 5
The Blacklist database is loaded on each SessMgr as and when they come up (if URL Blacklisting is set in any rulebase)
or when URL Blacklisting gets set in any of the rulebases.
When the SessMgrs start for the first time or after recovery, if URL Blacklisting is set in any of the rulebases, the stored
Blacklist database at SessCtrl is loaded onto the SessMgrs. This holds true for standby managers as well i.e., when
standby managers come up, the Blacklist database is loaded onto them. Whenever a SessMgr is killed, standby manager
which already has the Blacklist database loaded takes its place, and a new standby manager is created which loads the
Blacklist database as part of SessMgr getting started for the first time. If SessCtrl is killed, while recovering it checks if
URL Blacklisting is set in any of the rulebases, if set it will store the Blacklist database onto itself and load all the
SessMgrs as well.
Step 6
When a new Blacklist database is loaded on to the SessMgrs, the new database (and any stored versions that have rolled
over) are synced to the other SPC so that after switchover, the proper Blacklist database can be accessed.
URL Blacklisting Action
The following steps describe how the URL Blacklisting feature works:
Step 1
When an initial HTTP/WAP request comes for ECS processing and is processed by the ECS subsystem, a check is made
to see if the URL Blacklisting support is enabled.
Step 2
If enabled, the URL is extracted from the incoming request and is matched with the local in-memory Blacklist database.
If a match is found for the URL in the Blacklist database, the packets are treated as per the blacklisting action
configured—Discard, Redirect, or Terminate flow. In case of multiple HTTP requests in the same TCP packet, if any
of the URLs match the packet is treated as per the blacklisting action configured. If a match is not found, the request is
allowed to pass through.
CF Administration Guide, StarOS Release 18    
5
Content Filtering Support Overview
How URL Blacklisting Works