FIREWALL RULES DON'T WORK

Hi koolman,

YES they work!

NO, you don't have to use the command line to do this.
If you enter a FW Rule, where the destination is an interface address, we automatically add this rule into a INPUT subchain.

Works?

What is the difference, good question.

We have put together a special Security Distribution, where we followed the rule, less is more - that means less binaries and libs is more security.
So we only added what we really needed.

For every major process or directory, which can generate data, we gave them a separate partition. Even if the log partition is full, the system still works, to prevent DoS through no diskspace.

We have a special hardened and modified linux kernel to ensure maximum security.

We put all proxies into chroot environments, which are secured through kernel capabilities.
This makes it real hard to gain system root access through a buffer overflows in the proxies, bind for example or other exploits.

We have an full automated Up2Date Service, which keeps the system up to date with a 2 phase protocol, commit and rollback.
On errors during the update installation, the Update will automatically uninstalled and original state restored.

We have a selfmonitoring daemon, which monitors the system and major processes. If processes are not running or using too much memory, the will be started or restarted.

The two last points are important to keep the system up and running as long as possible, without admin interaction.
This is one focus, fast and easy installation and administration.

These are just a few differences between Astaro Security Linux and other distributions.

Greetings from Germany

Gert

------------------
-- 
Gert Hansen  <>gert.hansen@astaro.de>   |  Product Development
Astaro AG |  www.astaro.com  | Phone +49-721-490069-0 | Fax -55

[This message has been edited by Gert Hansen (edited 12 January 2001).]

[This message has been edited by Gert Hansen (edited 12 January 2001).]

Thanks for the answer - but  no -> the rules don't work. This time I tried to add a rule to filter the SMTP port for incoming packets on the outside ethernet address. The port is still open. I used NMAP to scan the ports.

Also I want to ask you a few questions. If this is a "secure" firewall - how come that the INPUT policy is set to ACCEPT by default?
How can I change the default INPUT policy using the WEBADMIN (I guess I can't)?

Hi again,

what I also noticed in this "firewall" is:

1.When you add a rule from Webadmin it puts this rule in a subchain called USR_FORWARD which is not a subchain of INPUT.
2.Even if you go and manually insert the subchain USR_FORWARD into the main chain INPUT your rule will not work if there's totaly oposite rule in the subchain TTT_ACCEPT.  And as you can guess the user cannot insert rules into this subchain from the Webadmin (sounds like Catch 22 , doesn't it).

My opinion: Please don't get me wrong - I really think that this Linux distribution is a very nice idea and I would love to use it. BUT IT'S IN A VERY VERY VERY DEVELOPMENT STAGE.

I apologize if I am wrong - but that's what I saw.

GREETINGS FROM LOS ANGELES

koolman

hi koolman,

you are right, astaro security linux is not in final stage, but its not VERY VERY VERY DEVELOPMENT STAGE! and never the packet filter code!

user defined rules are always in USR_FORWARD and we dont need a drop policy for the INPUT chain (and you dont need to change this)...

please read  http://netfilter.kernelnotes.org/unreliable-guides/packet-filtering-HOWTO.html  before you appose astaro securty linux is not secure - after reading this you will also understand why USR_FORWARD is not (and cant never) a subchain from INPUT...

last, but most important advice: dont insert USR_FORWARD manually to the main chain INPUT!!! thats complete "monkeyshine"




------------------

Markus Hennig
Astaro Product Development

hi koolman,

you are right, astaro security linux is not in final stage, but its not VERY VERY VERY DEVELOPMENT STAGE! and never the packet filter code!

user defined rules are always in USR_FORWARD and we dont need a drop policy for the INPUT chain (and you dont need to change this)...

please read  http://netfilter.kernelnotes.org/unreliable-guides/packet-filtering-HOWTO.html  before you appose astaro securty linux is not secure - after reading this you will also understand why USR_FORWARD is not (and cant never) a subchain from INPUT...

last, but most important advice: dont insert USR_FORWARD manually to the main chain INPUT!!! thats complete "monkeyshine"




------------------

Markus Hennig
Astaro Product Development

You always reply with very strange, defensife, unclear and pointless answers. That's not professional. Instead of giving support to the people who blindly decided to use your product -you are hostile, being "smart" and NOT HELPFUL AT ALL. 

MY INITIAL QUESTION WAS WHY THE FIREWALL RULES DON'T WORK. 

TRY TO FILTER THE SMTP PORT - AND WE'LL SEE IF IT WILL FILTER IT. TRY TO FILTER ICMP TIMESTAMP REQUESTS/REPLIES AND WE'LL SEE IF IT WILL FILTER IT.

But you don't answer these questions and you don't solve these problems. Instead of this you started acting defensive, recommended for me to read netfilter tutorial. That's ridiculous. You turn these support message board into something SO FAR from being a CUSTOMER SUPPORT center. 

You are making this "secure" linux LESS POPULAR with your BAD ATTITUDE, LACK OF SUPPORT AND CHILDISH MANNERS.

Markus didn't answer your question but you never really asked it. Your topic SHOUTS that Astaro doesn't work...and you wonder why you get a reply to the topic you defined.

It seems really strange that one would assume that a firewall couldn't filter. You (and I) have been working from a knowledge base of ipchains. Markus provided a link that can set us straight.

Did you follow the link? 
The first line of 'Differences Between iptables and ipchains' is most enlightening.
http://netfilter.kernelnotes.org/unreliable-guides/packet-filtering-HOWTO-10.html 

What are your current settings under Packet Filter -> Rules? I'm not sure where the Proxies -> SMTP Proxy sits, you may have to disable that. You may also have to disable Packet Filter -> ICMP, ICMP on Firewall. Disclaimer: I'm still a stumbling around newbie when it comes to Astaro.

I do agree that some of the replies are from folks that have been on the inside to long (Astaro/Linux gurus), to much is taken for granted. Astaro is pretty straight forward when you start understanding the structure/format. Unfortunatly the documentation sucks and the developers are busy folks. Sometimes I feel like I'm working on a crossword puzzle.

...Hmm, I'm putting a noticable investment of time into Astaro, am I going to be locked out down the road when Astaro becomes a commercial product, i.e. no pay no play?

[This message has been edited by Dave (edited 14 January 2001).]

ok, there was no expliciet answer, but i also cant see a direct question...
i think the correct question you want ask is: why doesnt work my smtp-blocking configuration?

did you switch off the SMTP proxie?

yes dave, we are very busy and work every day with the some code, configurations, GUIs... so this board is very worthwhile for us, to know where are impediments while using astaro security linux - but we want not give lessons about networking architecture and kernel/netfilter code....
 
ok, lets be friends  [;)] !


------------------

Markus Hennig
Astaro Product Development

Hi koolman, 

I hope I can end this debate by answering your questions and describing what's behind our FW Chains, the way we use:

There Major logic looks like this:

Chain INPUT:
- Subchain: LOCAL
- Subchain: AUTO_INPUT
- Subchain: TTT_ACCEPT
- Subchain: LOGDROP

Chain FORWARD:
- Subchain: LOCAL
- Subchain: AUTO_FORWARD
- Subchain: USR_FORWARD
- Subchain: LOGDROP

Chain OUTPUT:
- Subchain: LOCAL
- Subchain: AUTO_OUTPUT
- Subchain: TTT_ACCEPT
- Subchain: LOGDROP

Chain Description:

LOCAL:
This Chains ACCEPTs all traffic coming from a local interface and going to a local interface.

AUTO_INPUT:
In this Chain you find all rules of services running on the firewall that have to be available from outside, for example SMTP if the SMTP Proxy is activated or SSH if SSH access is enabled.
Also you find the Statefull Inspection rule, that all ESTABLISHED and RELATED connections are ACCEPTED.
This rules in this Chain are generated automatically.
Modify them by disabling those services in the WebAdmin.

AUTO_OUT:
In this Chain you find all rules of services that need to open connections to the internet. 
For example FTP, HTTP and HTTPS if the HTTP-Proxy is enabled, or DNS if DNS-Proxy is enabled.
Also you find the Statefull Inspection rule, that all ESTABLISHED and RELATED connections are ACCEPTED.
This rules in this Chain are generated automatically.
Modify them by disabling those services in the WebAdmin.

AUTO_FORWARD:
In this Chain you find the ICMP-Forward accept rule, as well as the Statefull Inspection rule, that accepts all ESTABLISHED and RELATED connections.

TTT_ACCEPT:
In this Chain you find the rules defined in WebAdmin which have an interface ip either in source or destination.

USR_FORWARD:
In this Chain you find all the forward rules which are defined in the WebAdmin/Packet Filer/Rules.

LOGDROP:
In this Chain every packet is logged with the equivalent protocol prefix and then dropped.
Due to this Chain which is the last in the 3 Major Chains is secure even if the default policy is ACCEPT.
But you are right we will change those policies to DROP, so we are secure even if the iptables were flushed.

I hope I answered your questions and explained why we do it the way we do.

Greetings Gert


 

------------------
-- 
Gert Hansen  <>gert.hansen@astaro.de>   |  Product Development
Astaro AG |  www.astaro.com  | Phone +49-721-490069-0 | Fax -55

[This message has been edited by Gert Hansen (edited 15 January 2001).]

If this forum had a rating scheme, I'd give you a 10 for that one. Thanks Gert

Thanks Gert,

Now I understand why I can't filter the SMTP. It's because in your default AUTOINPUT subchain. 

But my question about filtering the ICMP timestamp request and reply still exists. I add a rule to deny all the ICMP timestamp request packets coming from outside to my external interface. But when I check the system with NESSUS - it still says that the machine accepts ICMP timestamp requests.

Please help.

P.S. Sorry about the previous messages where I had doubts about this firewall.

Hi again,

I also have a suggestion about the future releases of your distribution. It would be nice if you implement in the Webadmin a GUI frontend of the iptables for all the chains and subchains(in a separate menu option - "Advanced Config" for example). It will make the Astaro Linux a very flexible product because it will let sysadmins configure their own subchains, or modify the existing ones. I'm sure it'll be very cool.

Greetings from your friend in L.A.,US
 

we cant add a support for single subchains, because the Subchains

AUTO_INPUT
TTT_ACCEPT
AUTO_FORWARD
USR_FORWARD
AUTO_OUTPUT

will be generated with the configfiles in /etc/wfe/conf (important are netdata, packetdata, servicedata) from our MiddleWare...

for your icmp-question: did you switch off icmp on firewall?

------------------

Markus Hennig
Astaro Product Development

Hi Dave,
thanks for the Rating! [;)]

Hi koolman, 

sorry i forgot that one.
In the default configuration at startup, 
we allow ICMP packts send to the firewall.

This adds a rule Any ICMP Any Allow in TTT_ACCEPT.

You can change this by disabeling ICMP on Firewall in WebAdmin/Packet Filter/ICMP.

It than changes this rule to Any ICMP Any LOGDROP in TTT_ACCEPT.

I know you will tell me now, that this doesn't make sense, because it blocks every ICMP traffic now and you can not accept some of it. And yes you are right, i will change that and in the next up2date the Any ICMP Any LOGDROP will be gone, then you can add filter in TTT_ACCEPT and ACCEPT or DROP them as you like. And if not it reaches the Subchain LOGDROP anyway.

We also thought about this idea, thanks by the way, developing a advanced GUI, but than dropped this idea for now, because it is complex managing this, due to the automatic and dynamic generation of the iptables rules from group and service definitions.
One Webadmin rule can generate many iptables rules.
Changing on one of this rule can not be brought back to the easy WebAdmin interface, due to its simplicity.

We haven't found a good way yet managing both
easy and advanced Configuration.

But we keep it in mind!

Thanks 
Gert



------------------
-- 
Gert Hansen  <>gert.hansen@astaro.de>   |  Product Development
Astaro AG |  www.astaro.com  | Phone +49-721-490069-0 | Fax -55

thanks Gert, Markus and Dave

I really think that what you are making is a VERY GOOD product. I've been waiting for something like this for years. 

Good luck guys.


Koolman (Nick)