Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 2908 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Interface as source or destination?

Enok
Astaro seems currently unable to have an interface as a source or  destination.

This is a problem because it forces the use of black-lists.


An example follows:

A network with 6 segments.  Each with different policy and access between each other.   There should be possible to access the internet from some or all this segments.  What we do not want is to have free access between the segments.  Therefore the segments  

With astaro today this seems to be done in an utterly ugly and insecure fasion.

To have access to internet one have to use the destination any.  But this is not right!     One then have to add deny-rules before this rule to avoid uncontrolled access to the other segments.

This adding of deny-rules is called a black-list.  Astaro is supposed to use white-lists but this falls apart when you have a couple of segments.


In the case of 6 segments one need not 6 rules to give them access to the internet.  One need 6*6 = 36!  


Have i missed sometihing or is astaro just not meant to be used for more than internet-dmz-internal?
 



By the way, what happened to the filter number in the logs?


This thread was automatically locked due to age.
Parents
  • 0
    I'm used to seeing this, and not just on Astaros. What do you have in mind as an alternative to Astaro's functionality?? (Please include a specific example)
  • 0 in reply to SecApp
    Netfilter support using an interface as a source or destination.   http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.3

    This is implemented in shorewall (http://shorewall.net/) and other systems closely connected to netfilter.  We were supprised that astaro did not implement this.

    This solves most of the problem by beeing able to use a normal  "open" rule to allow traffic for the internet where the internet is connected to a specific interface.


    Example:
    If we want users in a network segment to beeing able to use HTTP, HTTPS and SSH towards the internet but nothing else we can do this by 3 rules by letting the destination be the internet interface.

    If we have 3 departments in separate network segments where each should have http, https, and ssh towards the internet but not between themself.  They should have some access to a network with some servers however.

    If we ignore the access rules towards the server network and just look at how the 3 services can be realized with a destination beeing an interface we will get 3*3=9 rules in netfilter.  If we on the other hand do not have the opportunity to use an interface as a destination we end up with one rule for each service for each segment just to open to destination any (3*3=9).  And then one have to close this access to all the other segments.

    If we have 3 segments for departments and one server segments this makes us write 3 denying rules for each of the opening rules (3*9=18).  This might not seem as a very huge number of rules but the sorrow is that for every rule you want to open towards the internet you have to type in 4 rules rules which increases the chance of doing something wrong.  One also have to look at the order of rules etc..


    Is my ravings about this understandable or is none other having similar thoughts?  [:S]
  • 0 in reply to Enok
    Its really only the internet that is the problem here?

    All other NICs will have a defined set of IP addresses behind it.

    I am not 100% sure being able to use the Int as a source or dest will fix this as I have seen some scenarios where a router is outside a firewall bringing in multiple untrusted feeds (say other branches). Using this interface as the source means if you open it upo for on branch in this scenario you open it up to all. You are down to having to define IP range rules again.

    How about this.

    Astaro can easily work out what is a public and private IP address. If you had an option in the object definition to define trusted and untrusted Ip address you could automatically create an object for the internet

    e.g. start with ANY, remove all the IANA private IP addresses, remove all public IP addresses marked as trusted. Whats left is the internet.

    Not completely thought through but it has potential. It is especially nice as it is an extension of Astaro object capabilities and not a technology change.
  • 0 in reply to PenTest
    The problem is with rules handling internet or more precicely "undefined nets".  This is in all cases I can think of up through the default gateway.


    If one have multiple untrusted feeds as you name them, these is either multiple ways to internet in which routing protocols come in to handle the technicalities (astaro currently do not support so much here either) but they are still internet and should be treated the same.  Else they are distinkt networks that we know the ip-range of and therefore can handle in a normal way.

    Or in a most peculiar situation that I do not know exist is when you manage a firewall and you have nets that you do not know the range of.  If this is subnets it is administratively dangerous as the manager of the fiirewall should know which ip-ranges is in use.  If this is nets which have their own connections to internet then the connection to them is really a connection to internet.


    If you want to open up for a specific access to or from a subnet behind the internet-interface you add that rule in a normal fasion and then add the general rule for accessing the internet.



    What you write about what is private and internet addresses is already implemeted in the routing tables.  What is sendt to default gateway is internet.  Which of the default gateways is used is up to routing protocols.  Astaro only supports one default gateway it seems and this is really not a problem since one can add a small router to fix it if needed.


    What I bitch about here is the firewall part that is within the domain of Astaro.  This is already implemented in netfilter..  I dont care if a couple of other products suck in the same manner  [:(]


    I like the interface of Astaro and the way rules is updated.  [:)]
  • 0 in reply to Enok
    the point i am making is that there is no one solution to fit all scenarios.

    But i agree that keeping it all in the rulebase and object driven.

    So the options are:

    define an interface as an object

    or

    define the untrusted network as an object

    both would work. both have their ups and downs
  • 0 in reply to Enok
    Rules that would also support interfaces as destinations would be good! I'm sure they would like to have it, just a developer resource thing...
  • 0 in reply to PenTest
     [ QUOTE ]
    Astaro can easily work out what is a public and private IP address. If you had an option in the object definition to define trusted and untrusted Ip address you could automatically create an object for the internet

    e.g. start with ANY, remove all the IANA private IP addresses, remove all public IP addresses marked as trusted. Whats left is the internet.

    Not completely thought through but it has potential. It is especially nice as it is an extension of Astaro object capabilities and not a technology change.   

    [/ QUOTE ] 

    This is somewhat similar to how I handle this in a Check Point environment.  Since you need to create objects for all of your internal networks, you add all of those to a group, and then use the "negate" feature in a rule. 

    Basically you say "anything NOT in this group" when the rule is read, so if you wanted to allow HTTP to the Internet, you could say:  Internal Networks, to NOT internal networks on port 80.

    Not sure how easy this is to implement, but it could also be used for this purpose.
Reply
  • 0 in reply to PenTest
     [ QUOTE ]
    Astaro can easily work out what is a public and private IP address. If you had an option in the object definition to define trusted and untrusted Ip address you could automatically create an object for the internet

    e.g. start with ANY, remove all the IANA private IP addresses, remove all public IP addresses marked as trusted. Whats left is the internet.

    Not completely thought through but it has potential. It is especially nice as it is an extension of Astaro object capabilities and not a technology change.   

    [/ QUOTE ] 

    This is somewhat similar to how I handle this in a Check Point environment.  Since you need to create objects for all of your internal networks, you add all of those to a group, and then use the "negate" feature in a rule. 

    Basically you say "anything NOT in this group" when the rule is read, so if you wanted to allow HTTP to the Internet, you could say:  Internal Networks, to NOT internal networks on port 80.

    Not sure how easy this is to implement, but it could also be used for this purpose.
Children
No Data