2 Replies Latest reply: Aug 21, 2014 11:25 AM by PhilM RSS

    Firewall Enterprise - Network Defense & Application Defense VS IDPS


      I am trying to determine the inherent differences between Application Defense, Network Defense and Intrusion Detection and Prevention.  Both Application Defense and Network Defense are free services however you need a license for Intrusion Detection and Prevention.  What are the differences between these services and are there compelling reasons for purchasing and enabling IDPS if there are not a lot of inbound connections permitted?  For example - would a combination of Application and Network Defense be adequate protection for a web server with just static pages displayed?  What about a file transfer server?  Web app server?   

        • 1. Re: Firewall Enterprise - Network Defense & Application Defense VS IDPS

          Application Defenses are the settings for the 'smart' proxies.  You can turn on URL Filtering for the HTTP Proxy or block certain commands through the FTP proxy, for example.

          The Network Defenses are built-in protection for well-known attacks like SYN Floods or fragment attacks.  They are always on and cannot be turned off.

          The Intrusion Detection/Prevention consists of signatures for more specific attacks, things that exploit Dreamweaver let's say, or javascript attacks, etc.


          At version 8.3.2 and later there is an Application Defense for the HTTP proxy called 'Trusted Inbound HTTP'.  This app defense Denies web requests that, most likely, you do not want making it through to your web server (like a URL that 'ends with - .htaccess').  That web defense also only allows specific HTTP commands, like GET and HEAD, and denies others (or disallows them) like COPY and DELETE.  These are all customizable by the administrator.


          The firewall can also decrypt SSH, so you can control what kind of commands a user can give to an SCP server (I don't know of any other products that can do that).  You can do the same for FTP and SMTP also (control the commands/extensions that pass through that proxy).

          • 2. Re: Firewall Enterprise - Network Defense & Application Defense VS IDPS

            If I were to venture an opinion:-


            Network Defense in the inherent protection/alerting system - allowing you to set thresholds for certain types of behaviour and then apply actions based on those. Be that to blackhole the offending IP address, send an e-mail to an administrator or generate an SNMP trap.


            Application Defenses have been the bread and butter of this product pretty much since I first started working with its predecessor Sidewinder at version 5 (approx 2000/2001). The system has protocol level awareness for a number of core protocols (HTTP, SMTP, FTP and such like) and as such any traffic passing through a rule referencing one of these service will treated according to the RFC for that protocol. Open up an HTTP rule and then try to telnet on port 80 and you'll have the door firmly shut in your face as the Firewall will quickly realise it isn't HTTP. Add to that the application defense templates (as I think of them) which you can create and overlay on a rule using one of these services. I alway use FTP as the example as it is a fairly simple protocol. One of the things you can do with an FTP application defense is only allow a subset of the FTP command set to pass. You can set up an FTP server, create an inbound FTP rule and then, using the application defense deny the use of the PUT command. So external users will be able to connect and download files from the FTP server but, regardless of the security rights on the server itself will not be able to upload to it.


            IPS is then a subscription service which provides you with a database of signatures for known malicious traffic behaviour. As far as I am aware a SQL injection attack doesn't violate the core functionality of the SQL protocol. So while the Firewall is protocol-level aware for the Oracle SQL protocol and will block anything that violates the protocol RFC, it won't be able to block a SQL injection attack. Add an IPS filter/policy to a rule involving the SQL protocol and it can then identify and block known malicious traffic based on these signatures.


            Does that help?



            Ignore anything I said - Sam has replied and he's the real deal.