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]

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

No one does not see more of this the problem? Do you really?

No one does not see more of this the problem? Do you really?