Topic: Firewall - is there a GUI front end for SME

[raem]

arne

Alternative firewalls for the SME server could have been there alredy for a long time ago, if there were some positive will to have it.
These firewall configuration tools could also do all kind of fine grained firewalling control and also manage the problems related to a dmz zone, a wireless zone, outbound trafic control, inbound trafic control, etc, etc.

The links below are an example of some incremental work being done to develop code & db commands to control outbound traffic.
Once that part is done it's a much more straightforward project to develop a GUI to control the db selections, but many would question the need for such a GUI when db commands are perfectly adequate, and to some degree shield end users from doing something silly via a GUI panel.

http://forums.contribs.org/index.php?topic=36855.0

http://bugs.contribs.org/show_bug.cgi?id=2977

[CharlieBrady]

- limit a port forwarding to a range of source addresses

Already in the Bug Tracker - http://bugs.contribs.org/show_bug.cgi?id=2379

- Forward port for both tcp and udp in a single rule

When would you do that - what services run on both UDP and TCP (other than DNS)?

- Possibility to comment each forwarding rules

http://bugs.contribs.org/show_bug.cgi?id=771

- possibility to forward a port range

Already supported.

- support others interfaces than Internal and External, this could be great for site-to-site VPN, or a DMZ, or a WiFi device
- Support forwarding rules between the different network if there are more than 2 interfaces

There already exist new feature requests for supporting more than two interfaces. If that work is ever done, then firewall changes will need to be made. Until then, it would be pointless to add such support to the firewall rules.

- possibility to disable NAT with a db key

When would you want to do that, and why would a custom template not be adequate? I would be very hesitent to provide such a feature, as it would make it too easy for someone to make their LAN vulnerable. This "feature" would also be useful only to the very small number of people who have ISP allocation of more than one netblock.

- Block all the outgoing ports traffic (excluding an admin IP range) and allow just those we want

http://bugs.contribs.org/show_bug.cgi?id=9
http://bugs.contribs.org/show_bug.cgi?id=1409
http://bugs.contribs.org/show_bug.cgi?id=2977

- Add some protection against ssh scan at least (it seams to be possible with simple iptables rules, but I haven't tested)

http://bugs.contribs.org/show_bug.cgi?id=1645

- Add shaping rules (the script from hancees based on HTB works great, I think it should be added in the base)

http://bugs.contribs.org/show_bug.cgi?id=28
http://bugs.contribs.org/show_bug.cgi?id=674

I know it represent a lot of work, ...

You don't say.

... but these functionnality are really missing.

Well, you either need to live with what's there, use something else, or do something about what you think is lacking in SME server.

[arne]

From jdavey:

I'll repeat again, SME as a Server and basic gateway / firewall is a wonderful product. But when you need to offer someone something more than basics in terms of firewall / gateway, I just feel  more secure with a standalone product. Something more than SOHO and perhaps approaching enterprise level.

But the smeserver also have a fine grained control of the firewall actually more than the Smothwall has it.

as mentioned by CharlieBrady:

"You can provide your own file /etc/e-smith/templates-custom/etc/rc.d/init.d/masq and do there absolutely anything you want."

This is absolutely true. The only thing is that it is a bit complicated to do it this way. The more easy way is to test out a firewall configuration is to apply it via a script and then eventually after proper testing to implement it into the template system.

To apply a firewall script takes 2 minutes. To discuss if this 2 minutes job is possible to do takes in some strange an funny way hours, monts and years.

By the way I checked and went trough the sme bulit in standard firewall script this night, because I have some problems with it. It is located here: /etc/rc.d/init.d/masq (Please correct me if there should be more. Technically it is possible, but it does not look like that.)

After reading trough it my conclusion is that the sme server firewall is a standard stright forward statefull inspection iptables firewall.

Actually it is buildt much the same way as I use to do it so it wasn't much to complain about either. (exept for mine doesen't work.)

When I apply my forewall script I do the quite exately firewalling exept for the difference that I close down all ports that does not need to be open. I do not belive that a standard Linux firewall will be less secure because you close down some ports for external access.

It has been mentioned somewere above I think that you need to be an expert on firewalls to configure or understand the smeserver firewall. But it is actually a question of understanding the basic of a Linux netfilter firewall as far as I can see it.

I once made a simular check of the Smothwall (not the newest) and I think it was much the same.

The main difference I think is that the SMEServer has a more finegrained configuration oportunity via the template system.

On the other hand discussing firewalls is posiible "quicker" at the Smoothwall user forum.

To read trough the sme server firewall configuration script takes 5 minutes. To discuss if a port or two can be opened or closed takes some time.

To have the fine grained controll over the SMEServer firewall and network trafic is actually not a problem et all. It can be tested out on a separate config script and then implemented into the template system. (I had actually forgotten some stuff about the template system so thanks to Charlie for reminding me. The only problems with my sme servers is that they allways works so I got rateher little maintenance experience.)

To set up a 3 network adapter soulution is a bit more "tricky", but not much. I have it running right now and the 3'rd nic does not make a problem at all. The firewalling is done quite the same way as using the standard SMEServer firewall script, and it is actually not a problem at all.  To implement it into the template system would be a project I guess, but as an "add on" it is not a problem.

I don't know why people think that a firewall should be such a difficult thing because actually it is not. Some firewall designers does strange things, but the standard firewall of the sme server seems to be a rather stright forward, well structured and clean one.   

(But the new smoothwall has some qos fuctions and etc but thats another story.)

[arne]

RayMitchel and CharieBrady ->

Thanks a lot for interesting info about ongoing firewall developing projects.

I have to admit that I did not know exately how this bugzilla works at all. (I had a bug there some years ago, but it was not a success.)

The strange thing about the firewall "problem" is that the existing SMEServer firewall seems to be "only" based on a rather stright forward Linux firewall configutation script, if I'm not wrong. (/etc/rc.d/init.d/masq)(Buildt up useing the template system.)

But the main thing about a firewall is that it should not be regardet as something "pice by pice" and "bug by bug".

I think that a firewall should be rather regardet as "a complete whole".

I also think that good enough firewalls, like the Netfilter firewall, should not be about technology, and neither som much about security, it should rather be about users and user experiences. (Security and technology is already built in by the Netfilter team.)

To work on a good firewall, I thinkt there will be needed lopback times from sugestions to testing not, 2 monts in a bugzilla but rather 5 minutes in a test environment.

As I will see it, the feedback from the users and the discussion about how the firewall should work is the firewall, while the technology around it is something more secondary.

Lets take filtering of outgoing trafic from lan as an example. It is rather easy and stright forward to set up, but it would normally have a great influence of how the user experience will be for using the net. On the other side it could also have great influence for the overall security. This question is not a question of technology, or some "bug" it is a question of how humans experience the use of the net, and how it can or might be made a trade off between security and functionality. I guess that the more tight and secure and outgoing trafic control is, the more there will be a need for an easy and detailed interactive user control of the firewall functionality.

As I would see it the best way of doing this is by working on the firewalling thing first to obtain solutions that is comlete and well working first, and then to make the technology implementation after.

The firewall allone is something rateher very easy and managable that can be changed easy in allmost any form. The technical part of implemting an well working firewall into the SME configuration system seems to be something rather more difficult. 

The firewalling part of the firewalling problem is allmost nothing at all if it is handled as a whole, and not as a pice by pice by pice colletion of technical parts from the sme server.

When considered and tested out and discussed as a whole, it should the be possible to find a technical implementation of a well working firewall solution.

When the all firewalling probelems and all the server problems it put into one bag and mixed togeter I think you get something rather difficult, even though it is about something rather easy. I think that the good trick is modularity and to solve one problem at the time, the firewall problem and the server problems. If not such a modularity things will be rather difficult to improve or change.

As I would see it a good firewall is the sum of all user experiences and all the discussions that is behind it.

A good firewall is per definition not something one person can develop allone and come up with a solution for, as it should be the result of all the discussions that is the content of the firewall.

Just my point of view

[raem]

arne

After reading trough it my conclusion is that the sme server firewall is a standard stright forward statefull inspection iptables firewall.

That is freely available information that has been published for years, so you didn't discover anything there.

To apply a firewall script takes 2 minutes. To discuss if this 2 minutes job is possible to do takes in some strange an funny way hours, monts and years....
To read trough the sme server firewall configuration script takes 5 minutes. To discuss if a port or two can be opened or closed takes some time.

Your discussions seem to be about alternative firewall scripts that flush the current configuration, that's why you don't get much support for your approach.

As you now admit that it is straightforward and relatively easy to understand, then the existing code base for masq can be built upon & added to, rather than being discarded as you have been consistently promoting.

How about you contribute code to the project rather than just lot's of discussion.

I'll refer you again to
http://forums.contribs.org/index.php?topic=36855.0
and
http://bugs.contribs.org/show_bug.cgi?id=2977

The people involved took it upon themselves to create additional code. The code was based upon & fitted into the current design.

Read the links and you can follow the sequence of events that has lead to this code & db commands being developed. I'm sure it was more than 5 minutes work by a skilled coder(s) who understood both iptables and sme templating.


You do not need to discuss anything here ad infinitum, just start doing something, and if you upload code to bugzilla that fits into the current design concepts, I'm sure it will be picked up by others and developed further, if/as necessary.

To quote Gordon Rowell in
http://bugs.contribs.org/show_bug.cgi?id=9
(which refers to a revised iptables script by hans-cees)

"We'd be very happy to have a look at this, as long as:

- We have code to look at
- The code works in with the existing system or provides a
total replacement with all of the existing features. We're
much more likely to be able to assess a diff/patch than a
total replacement.
- Each part is separable and can be independently assessed
in a separate bug"


The developers clearly prefer ideas/code that fit into the existing structure. If your ideas are way different to what is currently being done, then don't expect the developers to develop it for you, unless as they say you present a "total replacement" that includes all existing features plus any additional stuff.

If you cannot or don't know how to implement something into the sme templating structure, then propose iptables rules and ask that they be implemented by someone who does know how.
You have been asked to contribute code previously, yet we see nothing from you except discussions, and having just read your most recent post, something that sounds like philosophical diatribe.

[arne]

RayMichel -> Thanks a lot for your answer  !

Your discussions seem to be about alternative firewall scripts that flush the current configuration, that's why you don't get much support for your approach.

Yes, but that is because I beileve that this is the only way to develop somthing (an improved firewall design) that will fit into the existing structure.

It's like if you are sitting and you want to walk. You first have to rise up, then you can walk. You can not walk when you are sitting.

If you want to develop some firewall stuff you will have to flush out the existing firewall to get started and you will have to do it again and again, when you are doing the developing work.

Then it is possible to do those discussions and to do the exange of experiences that will end up in an well functioning firewall that can be implemented into an existing structure.

As I will se it flushing the existing firewall and discussion with the users is the basic thing you are doing when you are working on a firewall that might be implementet into "technical structure" A or B, when it works.

As I will se it "can not flush" will mean "can not do anything" like "can not rise" will mean "can not walk" when you re sitting in a chair.

I have not understood how anything could be done at all about the firewall in an envirinment where firealls can not be flushed, as the flushing will be the basis for everything else.

When I see the links to the suggestion of Hans_cees is mentioned abovehttp://bugs.contribs.org/attachment.cgi?id=1416 I think I understand a little bit how to set up a suggestion concerning a firewall.

As I will see it the important thing about a firewall design is the dialog and expericences and the feedback from the users.

I tried to do a discussion about firewalls here on this forun for about someting like 2 or 3 years ago, but it did not work in this forum.

At that time I took the general project of devlop such a 3 port firewall for the Centos out to one other web forum to make the required discussion with interested users, to devlop a 3 port firewall with full controll of the trafic between the 3 network segments. We did and it ended up with a 3 port firewall soulution in it basic design not so unlike the one at the sme server or the Hans Cees suggestion. I will se if I am able to  find it again on the web and post it in the bugzilla system like the Hans Cees suggestion. I think it should work on the SME 7.2 as well (But I dont know how easy a 3 port mot into the existing template system will be.)

But by the way the Hans Cees suggestion is also based on flushing (and testing):

/sbin/iptables --flush  FORWARD
/sbin/iptables --flush  INPUT
/sbin/iptables --flush  OUTPUT

.. as I think practically all Linux firewalls are.


************************

Something here: http://www.eksperten.dk/spm/541674

(This firewall will not work directely on the SME server as it is a stright forward firewall gateway design where the gateway is without server functions.)

************************

This was obviosly a gateway design we did at that time. It needs some rework to be adapted to a server gateway.

But I did just now and I posting trough the old firewall from 2004 on my new 2007 model 3 port sme 7.2 server gateway.

If things were easy in this world we could just revork the old 2004 firewall a bit more and post it here. It could have been done some debugging and discussions and possibly someone could come up with some automated configuration tool (Actually I have started to make one myself based on php as I don't know Perl at all.)

As things were developed and checked for proper functinality we could then have looked into the problems how to implement a 3 port firewall (or any firewall) into the template system. A text based configuration tool for two or tree nic's could have been up within days. Some kind of web based configuration tool could have been there within a month or two. 

But things are not that easy, I guess. 

[gbentley]

Out of interest, has anyone ever had any kind of intrusion, even on a 'mis-configured' SME ?

Ive read these forums alot over the last few years and never heard of any.

[arne]

True, neiter my SME server or my other Linux firewalls has ever got hacked, as far as I know.

But on the other hand have anybody ever heard about a Windows client or some other clients that has got hacked or infected ?

Does the standard sme server firewall protect against such an infection of an Windows client ? Could it protect against this ? What about hacking of clients ? Could or should it protect againt that as well ?

If some revision of the firewall configuration and possibly some configuration tool like a GUI could increase the overall security, for server and the clients, would it then still be negative ?

[raem]

arne

You are free to create a firewall script and run it on your server, and anyone else is free to use it if they choose.
A firewall script like you propose is not likely to be accepted by the developers as a viable alternative to the current system.
Non standard firewall scripts may create problems when doing upgrades.


If you really want to make a contribution to the sme server project, I strongly suggest you take an alternative approach which is different to the attitude you have now.
Develop code (for new functionality) that adds fragments to the existing masq structure (as custom templates for now), and upload them to bugzilla as part of a New Feature Request (NFR). These will be reviewed by developers & peer group coders, modified if necessary, and may then be incorporated into the existing code base.
As the code is compatible with sme server, then all upgrades will work OK.

I will refer you again to these two links as a good example of how that process works.
http://forums.contribs.org/index.php?topic=36855.0
http://bugs.contribs.org/show_bug.cgi?id=2977

If you are unsure about how the current system works and how to integrate your ideas and new code into the system, you can ask questions at the devinfo list or in specific bugs.
http://lists.contribs.org/mailman/listinfo

The forums are not really the place to discuss advanced firewall design.

[arne]

I will try to take away the firewall project to somwhere else, or alternatively try to do it allone, not to disturb with this firewall talk anymore.

I am thankfull for all your frendly and well ment advices, but there is only one nag:

Inovative and new firewall design can not be done like that.

For the energy and time of discussing if firewall development is difficult or not it could have been produced hundreds of altenative firewall desigs, to have a collection, to test out from, to find out which is the best one to be implemeted into the template system.

A firewall script like you propose is not likely to be accepted by the developers as a viable alternative to the current system.
Non standard firewall scripts may create problems when doing upgrades.

But the developers has alredy made such a firewall script themself ? /etc/rc.d/init.d/masq

A non standard or in more general terms a "standard Linux firewall configuration script" should normally not affect the future upgrades of the sme server in any way, as it does not require any kind of installation on or modification to the server. The original firewall script can just be there as it is, and there is no need to change or modify anyting at all, to apply a new firewall. (Thats the beauty of Netfilter and Linux )

I will try to not mention the word "firewall" for at least a year now as I believe that mentioning it, will not produce any new firewall designs.

But it's a good thing that anyone can use the benifit of Netfilter/Linux, the capability of applying a completely new firewall, and to rearrange it and do all kind of testing, without the need of doing any (zero !) modifications to the underlaying operating system.

In the same way it is also be possible to use and test out a number of graphical firewall configuration tool front ends, without affecting the underlaying operatins system, at all, if they are designed to work like that.

The differece between firewall design and other contribs and suggestions is that a good firewall design will have to be based and created out of the free and open discussion about how to design and use the firewall in a best possible way.

My personal opinion is that the SME server could be even bether as a technical product if it took the full advantages of the options that is given by the Netfilter design.

I think that the SME Server is the best gateway server there exist for its intended use, but as times is changing, and it could be even bether. Firewalling is not just "firewalling", on a Linux platform it can increase usability and performace of a product, without the need of doing one single modifcation.

OK I will try to remeber: "Do not mention the word firewall on Contribs.org Forum until the 12 October 2008."
 

[gbentley]

Arne, your word count on this topic was 4142 - just imagine if that was SME code

[CharlieBrady]

... as I believe that mentioning it, will not produce any new firewall designs.

I'm glad that you have finally realised that.

When you come back, please contribute your ideas and code via the Bug Tracker. Thanks.

[CharlieBrady]

Arne, your word count on this topic was 4142 ...

Did you count in all four threads, or just this one?

[arne]

Arne, your word count on this topic was 4142 - just imagine if that was SME code

Yes but I also made a 3 port sme firewall in the middle of it all, with the other left arm, that works quite well, I think.

The firewall script is also posted on this forum.

I have posted the issue on the bugtracker, to see how it work, even though I think it is actually is a contrib and not a bug.

I think that the contribs.org forum also should be about contribs and the ability to develop some contribs including also some contribs related to firewalls. Don't know if it exist to many of them related to firewalling ?

[raem]

arne

I have posted the issue on the bugtracker, to see how it work, even though I think it is actually is a contrib and not a bug.

You have ideas that have great potential, and there are probably many sme users who want the functionality you are discussing, but these ideas need to be turned into working code that is compatible with the current system.

The bug tracker is now being used for far more than lodging bugs against current code.
Specific bugs are created as placeholders for a variety of matters eg New Feature Requests, outstanding bugs that are holding up a new release, documentation improvements & more etc etc.

The bug tracker has been strongly pushed by developers as "the only place" to report any problems, and also the main place to carry on development work & discussions. In the past there was much more of this happening in the contribs.org forums & the devinfo mail list. Most people here have responded to the core developers requests to do development work in the bug tracker within a specific bug (or multiple bugs if there are distinctly different parts).

That is because the bug tracker has good tracking & monitoring features that far exceed the management capabilities of the forums.
Perhaps you perceive the bug tracker as the wrong place to use, but that is incorrect. It is the right place to use for what you want to do.

No one is driving you away, but it does seem that all of us are asking you to use the bug tracker for your project, as that is how it is done around here now, is that such a difficult request ?
You can still have a thread here in the forums that can announce major changes or improvements or keep people generally aware of what is happening in bugzilla with regard to your project.

I don't see your bug, can you provide a link to it.