A proof-of-concept for a basic infrastructure re-architecture and software configuration needed to implement a basic virus-checking routine on files before they get to Oracle WebCenter Content
Checking files for viruses on Oracle WebCenter Content is a popular topic these days. It's also a delicate subject because traditional checking against the filesystem can't be done: if a file is on Oracle WebCenter Content's filesystem, it has already gone through the check-in process. If the file has a virus and is removed from the filesystem after Oracle WebCenter Content has processed it, Oracle WebCenter Content will probably have problems-or, at least, inconsistent data; it believes the file was checked-in and is there, but the antivirus software has removed the file from the filesystem. The best approach is to check the files before they arrive on Oracle WebCenter Content; that way, if the file has a vírus, the check-in request will not even get to the Oracle WebCenter Content instance.
This proof-of-concept article covers a basic infrastructure re-architecture and a software configuration needed to implement a basic virus-checking routine on files before they get to Oracle WebCenter Content. The main tools used for this article are Oracle API Gateway and Clam AntiVirus (Clam AV).
The original environment used for this article is a simple server, running a single instance Oracle WebCenter Content 11g. I will not get into details about Oracle WebCenter Content setup. For this article I used a default installation. On the initial environment, the user uses the URL that sends him directly to the Oracle WebCenter Content instance to perform operations. We are going to introduce a new layer between the client and Oracle WebCenter Content. This layer will have Oracle API Gateway 11g, and will be responsible for checking the content that is being sent to our Oracle WebCenter Content instance before it really hits its destination. Figure 1 shows what the original environment looks like, and how it will look after the changes proposed.
For this proof-of-concept article, we're going to need Oracle API Gateway 11g, Clam AV and an EICAR test file. The server used for demonstration is running Oracle Enterprise Linux 6.4. To download the required software, visit the following links:
For Clam AV, we'll be using version 0.98.3. EICAR is a file used to test antivirus software. If you have this kind of software in your computer you might need to disable it in order to be able to download the files.
Create an Oracle user and group:
[root@gw-host ~]# groupadd -g 54321 oinstall
[root@gw-host ~]# useradd -g 54321 -u 54321 -m oracle
Create a directory to handle our environment and give it write permissions to our Oracle user:
[root@gw-host ~]# mkdir /u01
[root@gw-host ~]# chown oracle:oinstall /u01
As Oracle user, create the commons directory to handle our installation files:
[oracle@gw-host ~]$ mkdir -p /u01/oracle/commons
Move the files below to /u01/oracle/commons:
Uncompress the file:
[oracle@gw-host ~]$ mkdir -p /u01/oracle/commons/OAG
[oracle@gw-host ~]$ cd /u01/oracle/commons/OAG/
[oracle@gw-host OAG]$ unzip ../ofm_oag_linux_184.108.40.206.0_disk1_1of1.zip
Run the installer file:
[oracle@gw-host OAG]$ cd Linux/64bit/
[oracle@gw-host 64bit]$ chmod +x OAG-220.127.116.11.0-linux-x64-installer.run
[oracle@gw-host 64bit]$ ./OAG-18.104.22.168.0-linux-x64-installer.run
Install software at
Select Core Server and Policy Studio as shown in Figure 3:
Create a new domain; ours will be without SSL/HTTPS support. A new API Gateway instance also needs to be configured. Ours will be created with name api-gw1, in group apigrp with default ports and no SSL/HTTPS support, as shown in Figure 4.
After the installation, the topology will resemble Figure 5.
Because I will not cover pre-req libraries for Clam AV compilation, refer to the product's documentation if you run into problems when building this software.
Create a directory structure to handle Clam AntiVirus, by performing the following commands:
[oracle@gw-host ~]$ mkdir -p /u01/oracle/clamav
[oracle@gw-host ~]$ mkdir -p /u01/oracle/clamav/var/log
[oracle@gw-host ~]$ mkdir -p /u01/oracle/clamav/share/clamav
Unpack its source code:
[oracle@gw-host ~]$ cd /u01/oracle/commons/
[oracle@gw-host commons]$ tar -xvzf clamav-0.98.3.tar.gz
Configure and compile the software source. Disable the unnecessary "on file access" scanning and extensions related to e-mail filtering:
[oracle@gw-host ~]$ cd /u01/oracle/commons/clamav-0.98.3
[oracle@gw-host clamav-0.98.3]$ ./configure --prefix=/u01/oracle/clamav --with-user=oracle --with-group=oinstall --disable-clamuko --disable-milter
[oracle@gw-host clamav-0.98.3]$ make
[oracle@gw-host clamav-0.98.3]$ make install
Create a config file for Freshclam, the tool responsible for creating and upgrading the Clam AV virus definition database:
[oracle@gw-host ~]$ vi /u01/oracle/clamav/etc/freshclam.conf
An example file is provided in
/u01/oracle/clamav/etc/. The file shoule resemble the following:
Update Clam AV's virus definition database:
[oracle@gw-host ~]$ cd /u01/oracle/clamav/bin/
[oracle@gw-host bin]$ ./freshclam
Create the config file for Clam AV daemon:
[oracle@gw-host ~]$ vi /u01/oracle/clamav/etc/clamd.conf
An example file for clamd.conf is also provided. Our file must look like this:
Start Clam AntiVirus daemon by running:
[oracle@gw-host ~]$ cd /u01/oracle/clamav/sbin/
[oracle@gw-host sbin]$ ./clamd
Check if the daemon is running:
[oracle@gw-host ~]$ ps -ef | grep clamd
To configure the Oracle API Gateway instance created during the installation process, we need to run the Policy Studio tool.
To run the Policy Studio tool, perform teh following:
[oracle@gw-host ~]$ cd /u01/oracle/middleware/oag/OAG-22.214.171.124.0/oagpolicystudio/
[oracle@gw-host oagpolicystudio]$ ./policystudio
After connecting it to your local Oracle API Gateway Node Manager, create a "Policy Container" to keep policies organized as illustrated by Figures 6 and 7, below.
Create policies. The first policy to create is the Redirect Policy, which redirects the user from
http://gw-host:8080/cs/, the main context of Oracle WebCenter Content. To create this policy, use an HTTP Redirect filter, as shown in Figure 8.
The filter created needs to be set as a start point for our Redirect Policy, as shown in Figure 9.
Create another policy, called Simple Passthru, which will send the transaction directly to Oracle WebCenter Content. To create this policy, use a Static Router filter named Route to WCC, as shown in Figure 10.
Set this filter as a start point for our policy, then create a Connection filter named Connect to WCC. When creating this filter, go to the Advanced tab, uncheck Handle Redirects and select Use Host header specified by client, as shown in Figure 11.
Create a Success Path going from the Route to WCC filter to the Connect to WCC filter. The policy will resemble Figure 12.
Create the last policy, Advanced passthru. It is the main policy, so we need to create it in our container. The first filter needed by this policy is the Content Type filter. Since the the Oracle WebCenter Content check-in screen is form-based, use this filter to determine if the transaction is a multipart form. This filter must fail if you see the content-type
multipart/* as shown in Figure 13.
Set this filter as a start point, and then create a ClamAV Anti-Virus filter that connects to the Clam AntiVirus daemon started earlier, as shown in Figure 14.
Create a Failure Path between the Content Type filter and the filter just created. Then create a Static Router filter named Route to WCC, as shown in Figure 15.
Create a Success Path between the Content Type filter and the Route to WCC filter. If the Content Type filter detects that the transaction is a form, it will fail and go to the ClamAV Anti-Virus filter to process the contents of the form. Otherwise, it will go to the Route to WCC filter. at this point the policy should resemble Figure 16.
If the ClamAV Anti-Virus filter does not fail, the message has no virus. Now you can send the transaction to the Oracle WebCenter Content. Create a Success Path from the ClamAV Anti-Virus filter to the Route to WCC filter. Then create a Connection filter named Connect to WCC, just as before. Remember to uncheck Handle Redirects and select Use Host header specified by client as shown in Figure 17.
Create a Success Path going from the Route to WCC filter to the Connect to WCC filter. For now, the policy should resemble Figure 18.
Create a "user friendly" message. First, create a Set Message filter named Create virus message, In this filter, use a custom-made HTML message to present to your user. Here, you'll see a simple one, but you can, for example, use Oracle WebCenter Content CSS to create this message with a pleasing layout. The content type for this message will be text/html, as shown in Figure 19.
Create a Failure Path from the ClamAV Anti-Virus filter to the Create virus message filter. Then create a Reflect Message filter named Send message with 403 as the code (unauthorized), as shown in Figure 20.
16. Create a Success Path from the Create virus message filter to the Send Message filter. Finally, create a Set Response Status filter, which will tell the Oracle API Gateway Monitor that the transaction failed to complete. Create the Set Response Status filter, name it Mark as failed and select fail as shown in Figure 21.
Create a Success Path from the Send Message filter to the Mark as failed filter.
The policy is now done, and should resemble Figure 22.
Now, inside the Policy Studio, adjust the paths so that the policies previously created get executed. To do this, first expand Oracle API Gateway, Listeners, Oracle API Gateway, Default Services and click on Paths as shown in Figure 23.
Edit out the root path and apply the policy created to redirect the user from
http://gw-host:8080/cs/ . In order to do it, select the
/ path, and click in the text box. Change the Path Specific Policy parameter to the Redirect Policy" as shown in Figure 24.
Create a new path by clicking the Add button and selecting Relative Path, which is needed for Oracle WebCenter Content authentication.
/adfAuthentication and set policy as Simple Passthru, As shown in Figure 25.
/cs/ path by clicking the Add button and selecting Relative Path. This path will resemble Figure 26.
Deploy the configuration by pressing F6.
Open your browser, click
http://gw-host:8080/ and you'll be redirected to
http://gw-host:8080/cs/. The routing will show you the Oracle WebCenter Content screen, as shown in Figure 27.
After logging in, try to check-in some documents, as shown in Figure 28.
If you try to check-in something with a virus, like the EICAR files, for example, you'll get an error message, as shown in Figure 29.
You can also check for transaction status in Oracle API Gateway Manager, as shown in Figure 30.
This proof-of-concept article shows a simple way of creating a virus protection layer in front of your Oracle WebCenter Content environment, without running the risk of compromising its operation or leaving it with inconsistent data.
This article is not intended to be a final guide, but only a demonstration of what can be achieved with Oracle API Gateway in conjuction with Oracle WebCenter Content. Please note that this article is covers only Oracle WebCenter Content's HTTP interface. It does not protect your native RIDC protocol or Oracle WebCenter Content's WebServices API. Oracle API Gateway can be used to protect Oracle WebCenter Content's WebServices API, but the policies will be different. To handle Oracle WebCenter Content's WebServices API you must virtualize the services.
Finally, a note about clustered environments. If you are planning to do this in a clustered environment, consider running an Oracle API Gateway instance in front of each Oracle WebCenter Content node, so that you don't introduce bottlenecks to your environment. I believe Oracle API Gateway should sit between Oracle HTTP Server and Oracle WebCenter Content.
Marcelo Parisi is a Consultant for Oracle Consulting Services in Brazil, where he is a member of the Tech Infrastructure team and works as an infrastructure architect and consultant for the Oracle Fusion Middleware family. His main roles includes architecture design, implementation and performance tuning of FMW infrastructure. Marcelo's fields of expertise include Oracle WebLogic Server, Oracle SOA Suite and Oracle WebCenter.