Screen OS

Hi,

 

I am a bit confused regarding the function and the terms in policies. If I enable a DI on my trust to untrust policy, will it check only the packets sent from the trusted, or the incoming answer packet (page to be displayed on the browser) which comes from the untrusted?

To make it short: is it sufficient to enable the DI on the initial Trust-to-Untrust policy to protect the browsing users or is it necessary to define another policy from Untrust-to-Trust to have protection from attacks coming from outside.  

 

In the DI, Target - again - a similar question. Src-IP and Dst-IP is in this case (Trust-to-Untrust policy) the computer in trusted zone always the source and the untrusted the destination, or in a browsing scenario the source is always the one sending data and the destination is the actual recipient.

 

Akos 

The DI inspection is performed in both flows of a session.

Hi Screenie,

 

You helped me a lot! 

 

As for the second part of my question: what is considered "source" and what is the "destination" in policy's context for the columt "Target"?

Are they the actual sources and destinations based on the flow of the data, or it corresponds to the From-To definition of the policy (in this case Trusted-to-Untrusted), and so the source will be always the Trusted and the destination the Untrusted?

 

Akos 

Ouch, good question. I think it will depend on on the context definition of the attack. The way DI (and IDP signature scanning) works is to look for a certain string in a certain part of the protocol. That's called the context. Some context will be direction depend, some not. If you scan for "root"in ftp user id the actual direction is depending on the policy. In untrust to trust it's found in the inbound stream, in a policy from trust to untrust (although you don;t scan very much in that direction to save CPU power mostly) you scan outbound. For other attacks the contect might be in the other direction.

 

Interesting stuff, isn't it?

Hi Screenie,

 

Sorry, I think lost the track, and start feeling confused... You told me the DI does the inspection in both flows of a session. So I was happy to stuff up my initial Trust-to-Untrust policy with DI items I considered useful for my needs.

In your recent post you wrote that scanning from Trust-to-Untrust is usually not done for saving CPU time (I'm actually using DI exactly on this policy - Trust-to-Untrust!). If DI checks in both directions then it will keep scanning the incoming data flow too, which comes in as a response on my queries sent from the Trusted zone, doesn't it?

Or should I set up an additional Untrust-to-Trust policy for HTTP, SSL and another few ones to use the DI to filter incoming packets, even when session is initiated from the Trusted zone? 

 

CPU consumption is not an issue (permanently around 1-2%) because of low traffic on mostly 1, sometimes on up to 3 computers.

Actually I have only one Untrus-to-Trust policy for now for a special purpose, forwarding data sent to a certain port to a specific IP address in the Trusted zone which runs only a small web-server in Java which processes and answers the data sent to that port and is not vulnerable to most of the attacks covered in DI. 

 

 Akos

If you only have a trust to untrust policy and no performance problems you're fine. What I wanted to say is most people use DI to scan on inbound traffic. Scanning from trust to untrust doesn't do any harm! Most attack you get in DI are directed at a server so found in inbound sessions.

Hi Screenie,

 

OK, if I got it right the DI will scan my packets in the Trust-to-Untrust traffic for both incoming and outgoing ones in the sessions initiated from inside. If I deploy a web-, a FTP- or a mail server, then I have to put DI on their respective inbound (Untrust-to-Trust) policies and most of the attacks is supposed to target these services. Is that the point?

 

Thanks,

 

Akos

Yes, this is my point of view indeed!

Hi Screenie,

 

As for the sources, destinations, clients and servers in DI:

I was almost sure I was unable to find it first time in the manual, but eventually here it is:

"Note:The client is always the initiator of a session; that is, the source address in a policy. 

The server is always the responder, or the destination address."

 

But for the brute force part - there is no adequate information on the "Target" column in the manual what is supposed be the "source" and "destination". I thought similar rule applies as for the "Action" column, but nope! In this case, these are the actual IPs of the "source" and "destination" of the ongoing attack in the session and so completely independent from the the "from-to" direction of the policy - that was from JTAC.

#DI
#force
#brute

So finaly all is clear, thanks for the feedback!

I want to NAT a public ip address to access internal mail server. But the public ip is not in the same subnet. I have screenos 6.1r3 pls let me know how can i configure this?

MIP address can be any address. Doesn't need to be from primary or secondary interface addresses.

Use an extended address in that case.

MIP is the best solution for inbound natting an SMTP server on other address than interface because outbound sessions will use this address to.