When we can easily implement security policies on Astaro?

Thanks, WaMaR, for a well-documented post.  If I understand your request, I believe the tools you need to achieve the security you want already exist in the Astaro.

Two questions about your diagrams... Couldn't you simplify them by removing the "Deny" arrows because traffic that is not explicitly allowed is denied?  Also, since the Astaro is a stateful firewall, isn't the "Allow" from the "Internet Servers" to "Internet" unnecessary unless those servers are initiating contact with outside servers?

If you are having PUBLIC users connecting inside your LAN with the HTTP/S Proxy, have you tried the following?  Put "Internal (Network)" in 'Transparent mode skiplist' and uncheck the box 'Allow HTTP traffic for listed hosts/nets'.  The proxy users in PUBLIC won't be able to use the proxy to access your LAN, but the users in LAN will be able to access everything in the LAN (I think you DON'T need an explicit rule 'LAN -> HTTP -> LAN : Allow').

If you've been using the transparent mode skiplist to allow traffic to specific hosts, you can just create a new packet filter rule 'Internal (Network) -> HTTP -> [specific hosts] : Allow'.  That's the equivalent of checking 'Allow' for those specific hosts.

Does that resolve your problem?

Cheers - Bob

Thanks Bob for you reply,

[LEFT]In accordance with your  suggestions already fixed diagrams.[/LEFT]



[LEFT]I assume that the DMZ has  the right to establish a connection to hosts on the Internet (you may not settle  the details here as to whether it is to be full access)
[/LEFT]
 



[LEFT][LEFT][LEFT]Suppose that we want that  users of the LAN and PUBLIC use with transparent proxy and its benefits as  antivirus, or filter content. If you enter any of the internal network (LAN or PUBLIC) in the "Transparent mode skiplist", will cease to operate as proxy above assumption.[/LEFT]
[/LEFT]

Therefore, I believe that this does not solve the problem.

Regards,
WaMaR
[/LEFT]

Sorry about that.  I tricked myself when I tested my idea.  It turns out that the skiplist now applies to BOTH source and destination.

The key thing to understand is that internal HTTP traffic is not handled by the proxy.  That means that you can add blocks for traffic to internal addresses, and they will affect only requests from the DMZ.

So, if the Internal LAN is 10.0.0.0/24, you could block access from the DMZ by adding '//10.0.0' to the block list on the 'Content Filter' tab. You also would want something like 'yourdomain.local' and other names that the proxy could resolve with your internal DNS.

Does that meet your requirements?

Cheers - Bob

Sorry about that.  I tricked myself when I tested my idea.  It turns out that the skiplist now applies to BOTH source and destination.

The key thing to understand is that internal HTTP traffic is not handled by the proxy.  That means that you can add blocks for traffic to internal addresses, and they will affect only requests from the DMZ.

So, if the Internal LAN is 10.0.0.0/24, you could block access from the DMZ by adding '//10.0.0' to the block list on the 'Content Filter' tab. You also would want something like 'yourdomain.local' and other names that the proxy could resolve with your internal DNS.

Does that meet your requirements?

Cheers - Bob

"Transparent mode skiplist" is good for set DMZ Network definition as source and destination skip list for all internal networks (for my diagram is LAN and PUBLIC Networks) which use http transparent proxy. Then we use only packet filter rules and all is OK for policy between DMZ  LAN and DMZ  PUBLIC.

Problem is with http connection between two internal networks LAN  PUBLIC.

So, if the Internal LAN is 10.0.0.0/24 and PUBLIC network is 10.0.1.0/24 , we could block access from the PUBLIC by adding '//10.0.1' to the block list on the 'Content Filter' tab. We also can adding names like 'yourdomain.local' and other names that the proxy could resolve with our internal DNS. These are only a mask for blocked URLs that I believe that there is not a good solution in order to properly and effectively implement the policy rules set out in my diagram.

To resolve this problem and increase the simplicity of the implementation of security policies on Astaro imagine many solutions such as:
1) Http Proxy (but also others) can check and use filter packet to determine whether a connection is not denied to any network. In my example from the diagram would be to deny the first two packet filter rules. 
Any to LAN Deny and 
Any to PUBLIC Deny.
2) HTTP proxy and the others also have an additional filter to your own packages in which the rule could be defined in the network layer 3 
3) In astaro could define the general principles of security that would be top priority for the packet filter, and all types of proxies.

[LEFT]I do not know which solution is best, but each of them would simplify the rules to implement safety Astaro network consisting of more than 3 zones of security. 
Introduction of functionality for which I say, also would make trying to carry out attacks such as "DNS cache poisoning", which are an easy way to circumvent the lock of the URLs in the content filter.

Regards,
WaMaR
[/LEFT]

In my second suggestion, there is nothing in the transparent-mode skiplist.

There is no need to block other traffic between subnets connected to different interfaces because all traffic is denied by default.  In particular, you do not need the 'Deny' packet filter rules listed in your diagrams.  Rather than use 'Any' in the 'Allow' rules, create a definition "Internet" 0.0.0.0/0, bind it to the External interface and use it instead with 'PUBLIC -> Internet' and 'DMZ -> Internet'.  If you want to allow traffic other than HTTP, you'll need to allow 'PUBLIC -> DMZ'.  It's confusing to discuss traffic other than HTTP on the same diagram.

The only traffic that needs to be blocked is that enabled by the HTTP proxy.  The only subnets that can use the HTTP Proxy are the ones explicitly listed.  All that is needed is to block URLs with explicit IP LAN addresses and names resolvable in the LAN.  It's unclear to me how a PC in PUBLIC could poison a reasonably-configured DNS cache inside the LAN.

I'm not saying your ideas aren't good ones.  I'm just saying that the stated requirements can be met with the current features.

Cheers - Bob

Thanks Bob,

You are right, probably I should use packet filter rules like this:
1. Source: LAN (10.0.0.0/24 bound to LAN Interface) | Service: Any Service | Destination: Internet (0.0.0.0/24 bound to WAN Interface) | Action: ALLOW
2. Source: LAN (10.0.0.0/24 bound to LAN Interface) | Service: Any Service | Destination: DMZ (10.0.2.0/24 bound to DMZ Interface) | Action: ALLOW
3. Source: PUBLIC (10.0.1.0/24 bound to PUBLIC Interface) | Service: Any Service | Destination: Internet (0.0.0.0/24 bound to WAN Interface) | Action: ALLOW
4. Source: PUBLIC (10.0.1.0/24 bound to PUBLIC Interface) | Service: Any Service | Destination: DMZ (10.0.2.0/24 bound to DMZ Interface) | Action: ALLOW
5. Source: Internet (0.0.0.0/0 bound to WAN Interface) | Service: Any Service | Destination: DMZ (10.0.2.0/24 bound to DMZ Interface) | Action: ALLOW
6. Source: DMZ (10.0.2.0/24 bound to DMZ Interface) | Service: Any Service | Destination: Internet (0.0.0.0/0 bound to WAN Interface) | Action: ALLOW

but using packet filter rules from my diagram was sufficient to use only a total of 5 rules (when I explicitly use deny rules). It seems to me that no matter which set of rules we use in the filter package, it is not there problems with the implementation of policy rules in contrast to the proxy.

I assume that we want to use proxy for content filtering such as HTTP traffic from LAN (10.0.0.0/24) and PUBLIC (10.0.1.0/24).
Therefore, in addition, I enable the transparent http proxy where I define allowed networks:
1. LAN (10.0.0.0/24 bound to LAN Interface)
2. PUBLIC (10.0.1.0/24 bound to PUBLIC Interface)

And here is the problem of how to easily and effectively force a proxy (eg, HTTP) to work integrate with layer 3 network packet filter in which carefully implemented our security policies presented in the diagram.

Currently, the Astaro proxy can only try to block the content at the application layer and in the case of several internal networks that are allowed to use proxy (in my example, LAN and PUBLIC) believe that the problem is that how to do the proxy to work safely and in accordance with the principles defined in the security diagram.

Regards,
WaMaR

That's a clear suggestion.  I'll be interested to see if anyone from Asraro responds.  Thanks for your participation here.

Cheers - Bob

Please vote at integrated configuration of the security policy

Best Regards,
WaMaR

(If I understand the problem, correctly)

Hello WaMaR

From the dialog in previous posts, I would like to add some info.  

1. The transparent proxy will only affect packets with a tcp source port of 1:65535 and a tcp destination port of 80 (or 443 if configured) and that do not have an internal destination.  This is shown with iptables -nvL -t nat

Chain AUTO_PRE (1 references)

 pkts bytes target     prot opt in     out     source               destination

    0     0 REDIRECT   tcp  --  *      *       10.129.12.0/24       0.0.0.0/0           tcp spts:1:65535 dpt:80 ADDRTYPE match dst-type !LOCAL redir ports 8080

    0     0 REDIRECT   tcp  --  *      *       10.129.12.0/24       0.0.0.0/0           tcp spts:1:65535 dpt:443 ADDRTYPE match dst-type !LOCAL redir ports 8080

2. The transparent skip list will skip an IP address that appears in the IP source or IP destination fields in the IP header.  This is not the case in previous versions.

3. The order of precedence will make the packet pass through the proxy before passing through the user-defined packet filter chain.  This means that aside from port(s) 80 (and 443), you can use the packet filter to block/allow/reject all other services.  This is a pretty standard DMZ/segmented network topology.

Dilemma: The dilemma is "what if you want to selectively block/allow port 80/443 while using the transparent proxy".  There are 2 ways to do this:

1. you can use the transparent mode skip list for the servers in which you would like to selectively block.  This will make the packet filter affect the connection, but it will also mean that you can't scan for anything (it won't be going through the proxy at all).

2. you can use http profiles to allow/block the IP/URL of the site.  This will be preferable because the proxy will still be able to scan the traffic, but will block or allow based on source network or user/group.

I hope this all makes sense in the context of your issue.  Please let me know if you need clarification.

Tim, based on WaMaR's requirements, he can't use the first way.  The second way describes what I suggested in post #6, but it still doesn't give adequate traffic selection.

I can use //10.0.0 to block access via IP address and add mydomain.local, but I still have to add a new block whenever a new device joins the AD.  If you add YourPC, I have to go to the Astaro and add a block for YourPC because the name is resolvable without its FQDN.

Does that make sense?

Cheers - Bob

I see now, sorry for the confusion.  

I see the new problem is that you can bypass this with NBT name.  You can add a block entry for the entire domain or network range, but since those are matched based on regex, you will need to add a very large whitelist.

Conceivably, you could use a naming convention for all hosts.  PCs would be named net1-pc-username, then you can block [FONT="Courier New"]net\d-pc-.*[/FONT], but this is a stretch for our customers to have to do, especially if such a naming convention does not yet exist for their domain.  DNS may have an answer for this by adding the domain suffix, but I have not tested it.

unfortunately, there is nothing else I can add as this is already requested as a feature and the capability of the proxy does not allow for this.[:(]

Thanks, Tim, for confirming; that helps alot in understanding.

Cheers - Bob

Thanks to everyone for the votes submitted. Please look at one feature and vote, the lack of which is pain in Astaro.

integrated configuration of the security policy