ScreenOS Firewalls (NOT SRX)
ScreenOS Firewalls (NOT SRX)

Inspecting SOAP transactions.

[ Edited ]
02.19.09   |  
‎02-19-2009 02:23 AM

Is it possible to inspect SOAP over HTTP transactions in Screenos ( or Junos-ES )? 


i need to be able to define a so called "white-list" of allowable namespace methods...


I have been able to do this in some other vendors firewalls, but i want to migrate to a Juniper solution soon, and this is proably the last hurdle.


Message Edited by mrpackethead on 02-19-2009 02:26 AM
( because i have to )
ScreenOS Firewalls (NOT SRX)

Re: Inspecting SOAP transactions.

02.19.09   |  
‎02-19-2009 07:24 AM

I am faily sure you could do this with Deep Inspection but it is the sort of thing best left to a dedicated IDS System.



ScreenOS Firewalls (NOT SRX)

Re: Inspecting SOAP transactions.

02.20.09   |  
‎02-20-2009 12:59 AM

if u are sure this can be done with deep inspection could you elborate on how to do this?

( because i have to )
ScreenOS Firewalls (NOT SRX)

Re: Inspecting SOAP transactions.

02.20.09   |  
‎02-20-2009 03:38 AM



Deep Inspection is a subset of Juniper's IDP and there must be over a thousand signatures existing for it. These are updated via a subscription service and you will need a license key and a signature subscription before you can use it.  


Choose the signature packet:            

FIREWALL-> set attack db sigpack ?            

base                 Baseline Deep Inspection Pack           

client                Client Deep Inspection Pack           

server               Server Deep Inspection Pack           

worm                Worm Mitigation Deep Inspection Pack 


Load the signature onto the device and update the signatures the first time manually. The device needs Internet access for automatic updates.            

exec attack update           

set attack db mode update           

set attack db schedule daily 2:00 


If your firewall has no direct connection to the Internet, but it can reach a proxy configure the proxy settings


set pattern-update proxy http 


If you have problems downloading the signatures you can use the get lic command to make sure that you have a valid license and use get clock to check your system clock is correct. This is important for certificate validation. Use the get dns name command to check you have Internet access and your DNS server.  Only those signatures with a certain severity will be installed if your firewall has limited memory. Protocol anomaly is best used for pre-emptive protection from future exploits by enforcing protocol definitions and the context and stream signatures protection is best for known exploits so I would think pre-emptive protection would be best suited to your needs.The difference between context and stream matches is those contexts matches decode the application layer and apply the match only to the functional part of the application e.g. a filename, URL etc. and not the full data stream.  


If you want to block access to a certain virus filename but not block access to web sites reporting that virus, context signatures can virtually eliminate false positives if the system has been set-up well. You can also list signatures and anomalies with get attack signature and get attack anomaly.


You can organise and apply signatures to policies in groups using the get attack group command and they are organised by their severity level e.g. info, low, medium, high, critical.


To link an attack group to a policy it will only be passed to the deep inspection module if the rule permits traffic otherwise it will be dropped.            

set policy id 100 from "Untrust" to "Trust" "Any" "MIP(" "HTTP" permit           

set policy id 100           

set attack "CRITICAL:HTTPSmiley FrustratedIGS" action drop           

set attack "CRITICAL:HTTP:ANOM" action drop           

set attack "HIGH:HTTP:ANOM action none           

set di-severity low           



Configure multiple attack groups with different actions on the same policy:           

none                  permit flow without processing           

ignore                ignore this flow if attack is found and continue           

drop-packet     drop this packet           

drop                  drop all packets in this flow till connection timeout           

close-client       reset client to server connection and drop packet           

close-server     reset server to client connection and drop packet           

close                 reset connections on both sides and drop packet 


A few extra points, be careful when blocking traffic that is triggered by low-severity signatures, as it can also block legitimate traffic. You can control the logging level with di-severity. You can view DI attacks with get event type 767 and fine-tune different protocol decodes with the set di service <protocol> command. Finally to troubleshoot problems, use debug flow basic and debug idp all. With HTTP being the most common protocol it will probably use the highest bandwidth in your organisation so adding new HTTP signatures hits performance hard which is why this is better done with dedicated IDS.


Add new signatures with care and try to avoid high-state wildcards in the middle of signatures and after common matching strings.