02-19-2009 02:23 AM - edited 02-19-2009 02:26 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.
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.
Gavrilo
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?
02-20-2009 03:38 AM
Hi,
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 proxy.juniper.net:8080
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 juniper.net 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(1.1.1.1)" "HTTP" permit
set policy id 100
set attack "CRITICAL:HTTP
IGS" action drop
set attack "CRITICAL:HTTP:ANOM" action drop
set attack "HIGH:HTTP:ANOM action none
set di-severity low
exit
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.
Regards
Gavrilo