Write for OTN
Earn money and promote your technical skills by writing a technical article for Oracle Technology Network.
Learn more
Stay Connected
OTN Architect Community
OTN ArchBeat Blog Facebook Twitter YouTube Podcast Icon

Virus-Proofing Oracle WebCenter Content 11g with Oracle API Gateway 11g

Marcelo Parisi

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

June 2014

Downloads
download-icon13-1Oracle WebCenter Content
download-icon13-1Oracle API Gateway

Introduction

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).

Architecture Infrastructure Considerations

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.

parisi-webcenter-oag-fig01
Figure 1

Software Requirements

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.

Preparing the Environment

  1. Create an Oracle user and group:

    [root@gw-host ~]# groupadd -g 54321 oinstall

    [root@gw-host ~]# useradd -g 54321 -u 54321 -m oracle

  2. 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

  3. As Oracle user, create the commons directory to handle our installation files:

    [oracle@gw-host ~]$ mkdir -p /u01/oracle/commons

     

  4. Move the files below to /u01/oracle/commons:

    • ofm_oag_linux_11.1.2.2.0_disk1_1of1.zip
    • clamav-0.98.3.tar.gz

Installing Oracle API Gateway

  1. 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_11.1.2.2.0_disk1_1of1.zip

  2. Run the installer file:

    [oracle@gw-host OAG]$ cd Linux/64bit/

    [oracle@gw-host 64bit]$ chmod +x OAG-11.1.2.2.0-linux-x64-installer.run

    [oracle@gw-host 64bit]$ ./OAG-11.1.2.2.0-linux-x64-installer.run

  3. Install software at /u01/oracle/middleware/oag/OAG-11.1.2.2.0:

    parisi-webcenter-oag-fig02
    Figure 2

    Select Core Server and Policy Studio as shown in Figure 3:

    parisi-webcenter-oag-fig03
    Figure 3
  4. 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.

    parisi-webcenter-oag-fig04
    Figure 4
  5. After the installation, the topology will resemble Figure 5.

    parisi-webcenter-oag-fig05
    Figure 5

Installing Clam AV

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.

  1. 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

  2. Unpack its source code:

    [oracle@gw-host ~]$ cd /u01/oracle/commons/

    [oracle@gw-host commons]$ tar -xvzf clamav-0.98.3.tar.gz

  3. 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

  4. 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:

    UpdateLogFile /u01/oracle/clamav/var/log/freshclam.log

    LogFileMaxSize 2M

    LogTime yes

    DatabaseMirror database.clamav.net

    MaxAttempts 5

    ConnectTimeout 60

    ReceiveTimeout 60

  5. Update Clam AV's virus definition database:

    [oracle@gw-host ~]$ cd /u01/oracle/clamav/bin/

    [oracle@gw-host bin]$ ./freshclam

  6. 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:

    LogFile /u01/oracle/clamav/var/log/clamd.log

    LogFileMaxSize 25M

    LogTime yes

    TCPSocket 3310

    TCPAddr 127.0.0.1

    MaxConnectionQueueLength 10

    ReadTimeout 300

    CommandReadTimeout 5

    MaxFileSize 250M

  7. Start Clam AntiVirus daemon by running:

    [oracle@gw-host ~]$ cd /u01/oracle/clamav/sbin/

    [oracle@gw-host sbin]$ ./clamd

  8. Check if the daemon is running:

    [oracle@gw-host ~]$ ps -ef | grep clamd

Creating Oracle API Gateway Policies

To configure the Oracle API Gateway instance created during the installation process, we need to run the Policy Studio tool.

  1. To run the Policy Studio tool, perform teh following:

    [oracle@gw-host ~]$ cd /u01/oracle/middleware/oag/OAG-11.1.2.2.0/oagpolicystudio/

    [oracle@gw-host oagpolicystudio]$ ./policystudio

  2. 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.

    parisi-webcenter-oag-fig06
    Figure 6
    parisi-webcenter-oag-fig07
    Figure 7
  3. Create policies. The first policy to create is the Redirect Policy, which redirects the user from http://gw-host:8080/ to 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.

    parisi-webcenter-oag-fig08
    Figure 8
  4. The filter created needs to be set as a start point for our Redirect Policy, as shown in Figure 9.

    parisi-webcenter-oag-fig09
    Figure 9
  5. 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.

    parisi-webcenter-oag-fig10
    Figure 10
  6. 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.

    parisi-webcenter-oag-fig11
    Figure 11
  7. Create a Success Path going from the Route to WCC filter to the Connect to WCC filter. The policy will resemble Figure 12.

    parisi-webcenter-oag-fig12
    Figure 12
  8. 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.

    parisi-webcenter-oag-fig13
    Figure 13
  9. 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.

    parisi-webcenter-oag-fig14
    Figure 14
  10. 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.

    parisi-webcenter-oag-fig15
    Figure 15
  11. 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.

    parisi-webcenter-oag-fig16
    Figure 16
  12. 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.

    parisi-webcenter-oag-fig17
    Figure 17
  13. 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.

    parisi-webcenter-oag-fig18
    Figure 18
  14. 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.

    parisi-webcenter-oag-fig19
    Figure 19
  15. 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.

    parisi-webcenter-oag-fig20
    Figure 20
  16. 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.

    parisi-webcenter-oag-fig21
    Figure 21
  17. 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.

    parisi-webcenter-oag-fig22
    Figure 22

Configuring Oracle API Gateway Paths

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.

    parisi-webcenter-oag-fig23
    Figure 23
  1. Edit out the root path and apply the policy created to redirect the user from http://gw-host:8080/ to 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.

    parisi-webcenter-oag-fig24
    Figure 24
  2. Create a new path by clicking the Add button and selecting Relative Path, which is needed for Oracle WebCenter Content authentication.

  3. Use the /adfAuthentication and set policy as Simple Passthru, As shown in Figure 25.

    parisi-webcenter-oag-fig25
    Figure 25
  4. Create the /cs/ path by clicking the Add button and selecting Relative Path. This path will resemble Figure 26.

    parisi-webcenter-oag-fig26
    Figure 26
  5. Deploy the configuration by pressing F6.

Testing Everything

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.

parisi-webcenter-oag-fig27
Figure 27

After logging in, try to check-in some documents, as shown in Figure 28.

parisi-webcenter-oag-fig28
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.

parisi-webcenter-oag-fig29
Figure 29

You can also check for transaction status in Oracle API Gateway Manager, as shown in Figure 30.

parisi-webcenter-oag-fig30
Figure 30

Conclusion

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.

About the Author

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.
Twitter LinkedIn Facebook