Topic: Some firewalling capability for a server-only installation ?

[arne]

As I would see it to design or modify a firewall for the SME server will contain 3 different activities or tasks:

1. The discussion to find out and state which is the good and which is the bad packets. Discussion can be in english or any other language.

2. The rules stated in activity 1 will then have to be converted to iptables syntax for implementation and testing. Activity 1 and 2 should be a bit interactive, and they should be performed more than one time.

3. Activity 3 will be to implement the iptables syntax developed under activity 1 and 2 to the automated SME server configuration system.

Activity 1 and 2 can be quite well maintained in a open and general discussion forum, as I would see it. When activity 1 and 2 is done, then activity 3 also can be done. Activity 1 and 2 will be valid for any newer Linux distro. Activity 3 will be specific for the SME server.

[raem]

arne

> As I would see it to design or modify a firewall for the SME server will contain 3 different activities or tasks:
> Activity 1 and 2 can be quite well maintained in a open and general discussion forum, as I would see it.
> When activity 1 and 2 is done, then activity 3 also can be done.

A lot of "as I would see it" here.
In regard to the existing firewall in sme server, one of the main sme developers, Gordon Rowell, has already stated;
"If it needs improvement, please raise a New Feature Request in the bug tracker."

Arne, where are you really heading with this thread & topic ?
Obviously Gordon is willing to listen to you, but he has asked you do that in the  bug tracker, with samples of your code/rules that are supposedly better than what is in sme now.
If you want to see changes in the firewall code, then I would stongly suggest you "play the game" the way the developers are asking.
You can talk & debate the issue as much as you want here, but Gordon wants to see your code !

[arne]

I do not know about any errors in the existing firewall and I don't have a script at all.

It's just that the nature of firewalls is that a general firewall intended to use for any (sme) server installation wil have to be wide and open enough to let inn all the trafic all potensial users and use might require.

On the other hand if a firewall is designed for one certain installation and one certain use, it can be designed to be tighter and more precise than the general firewall.

If I have a bad neigbour that I want to lock out or an old poor performing hardware that need some extra protection for dos attack's, I gues that this should not be implementet in the general firewall soultion, that should be working for everyone and all installations.

One other example is the typical lan ports for Samba. Those are also wery well known hacker ports. For a general firewall solutions, these will have to be left open. For a specialised and individual use on a server where the samba are not really needed, it might be adviceable to lock those ports.

Making a firewall has rather little to to with making code or script, as I would see it.

The interesting part of it, is the discussion about, which trafic should be allowed to fleet and hwich should not be allowed to fleet, which are the good and which are the bad packets, etc.

If there is a good and interesting discussion, why should we allow trafic a and trafic b, not trafic c, etc, there will allways be posible to make a configuration code that will do exactely that. If there is no interesting discussion there is no (new)firewall at all.

By the way, I have already posted two links that contains those syntax elements that should be needed, so it should actually only be a question if there is a discussion or not.

I can not see it can or would hurt the sme server project at all if there existed an alternative firewall script that anyone could use and modify as they want. If there should come out any good ideas or experiences this could easily be impemented in the general firewall soulution as long as the ideas is not valid for one specific installation only.

If there is a discussion ther will also be a fireall script. If there is no discussion there is no firewall script.

By the way how to identify the good and the bad packets ..

Personally I mainly use theese 3 tools:

1. "iptraf" is a simple trafic monitor to show a snapshot or picture of trafic out and in of the server.

2. "Ethereal" is a packet sniffer that can give a more detailed picture of the trafic. Can also be runned via console/ssh shell as the textbased variant "tethereal".

3. "Nmap" the linux port scanner.

I am not avare of any error in the sme server firewall. If I find one I will rise a bug. Specialised firewalls will normally be more pricise than genetral firewalls, but that's not a bug.

[arne]

By the way, the reason that I prefer to play with Linux more than M$ is that spirit of open mind and open discussions that is normally related to the open source projects. As I will see it, playing with open source the open source way, is not "bad".

[arne]

Some more ideas and reference about proper firewalling:


http://lfw.sourceforge.net/

Exuse me for using the space in the forum for some notes, but it will quite surely end up with a firewall script, that can be used for anybody who might find it usable or interesting.

There is no way of presenting an end result if not doing the basic works first. This end result can be bether, the more persons that particitipate in it.

I think a firewall script as a modification alternative for the sme server shold be a lot more simpler (to read) than those I have linked in. The idea is to pich in those ideas of filtering from these more complex solutions, and then simplyfy them in a "easy to read way" while still maintaining the more important firewalling functions.

[arne]

Excuse me once more for using your publishing space, but there is a few questions that need an answer before the firewall script revision 0:

1. Which ports and which protocolls to be opened for for Samba logon ?

http://support.microsoft.com/kb/179442/

2. Which ports/protocols for the PPTP VPN logon ?

http://www.tomsnetworking.com/2003/05/20/how_to_vpn_firewall/

http://poptop.sourceforge.net/dox/replacing-windows-pptp-with-linux-howto.phtml

The idea is to give the end user a fine grained and precise firewall controll via a easy to read and modify configuration script. Using the sme server togeteher with a traditional gateway firewall and with an aditional fine grained firewall controll on the sme server itself, should also give a relatively high degree of flexability and security.

While doing all the development "puplic" with also all references and souces "public" makes it possible for anyone to controll, modify and improve the work.

I guess that the revision 0 should not be to far away.

Any ideas or suggestions would be welcome.

[raem]

arne

> The idea is to give the end user a fine grained and precise firewall
> controll via a easy to read and modify configuration script.

Wouldn't that then be the request that you would submit to the bugtracker New Feature Request section ?

The ports & protocols needed for various services is common knowledge, perhaps not to yourself but certainly to technically literate persons such as the developers & similar.

The sme server does have underlying design concepts, one of the main ones being ease of configuration & use. The developers have obviously not included a server manager panel called "firewall", as this would allow non technical end users too much control that would inevitably end up compromising the security of the server.

In the various "blurbs" about sme, did you miss the part about services are enabled/disabled and ports (in the firewall) opened/closed as a result of configuration choices made in the server manager panels. The server manager is in fact a firewall adjustment tool, implemented in a way that does not allow end users to make "stupid" mistakes.

As far as fine grained control goes, then all the code that creates the various iptables firewall rules is in the masq templates, so a system admin has full & very precise control if they adjust the various template fragments, by the standard custom templates procedures of course.

Granted that is not a user friendly GUI server manager panel, and as such does require some understanding of iptables & templates. That is exactly the point though, you need to know what you are doing if you are going to mess around with the firewall, and technically minded persons who understand the security implications of their actions will know how to manipulate templates etc.

You may be able to come up with different firewall scripts/rules, but I doubt if the developers will weaken their stance on the underlying design concepts of simplicity & security etc, by exposing the firewall to easy adjustment & abuse.


> ...a general firewall intended to use for any (sme) server installation wil > have to be wide and open enough to let inn all the trafic all potensial
> users and use might require.

sme by default only opens necessary incoming ports required by services which are configured by the admin at setup time and ARE particular to that installation. All other incoming ports are closed by default.
I would not call this "wide & open" as you suggest.

I'm not sure what the server only firewall does in sme 7, but historically all outgoing ports were open, which was a design choice.


> On the other hand if a firewall is designed for one certain installation and > one certain use, it can be designed to be tighter and more precise than > the general firewall.

That's what sme firewall does do, the server (and firewall) are configured for the particular installation.

Have you run the ShieldsUp test at www.grc.com to see how few ports are open on sme ? These will be as a result of the system admins configuration choices too.

[arne]

Thanks for a frendly and interesting post

Some users might be more comfortable to have the full and whole controll over the trafic to and from the server. Some others might prefer to use an automated system only.

There is no other practical way, as I would se it, to optain such a full controll other than using a firewall configuration script.

I also think that there is nothing wrong with the existing fireall as a general and all round firewall soulution, so it can basically be left just as it is.

As I hope to demosntrate soon, a manually configured firewall, using a script can be almost as easy as a automated configuration system, if optimized for simplicity.

To make changes in the existing sme firewall is a task that is very much more complicated than just applying a new firewall via a script. At the sme server, the template fragments build up the configuration file, the configuration file is a script that generates the firewalling rules, and the firewalling rules themself contain a number of "jumps" in the rule stack, and declaration of new rule stacks that make it difficult to overview how it all work.

On the other hand those same firewalling rules could also be a simple listing of rules in a rule stack,  that will be quite easy to overview and to understand.

In such a siplified firewall setup the end user would not have to think much about the firewall itself, only about the trafic and which trafic to let trough or filter out.

As I will see it, simplicity and a easy and a easy overview and control also leads to security.

There will also be a theoretical disadvantage making things simple as posible, and that is eficiency (correct spelled ??). If the one packet has to traverse 5 or 6 rules rather than 2 or 3 it might cost some small extra processor power.

The bulit in automated firewall in the sme server, at least that for the new server only installation, seems to contain allmost only basic iptables filtering functions. I think it would be mere easy to experiment with more advanced functions using a siplified firewall setup.

I do not agree that shields up and simular web based scanning tools gives a good picture of the quality of a firewall. They can scan if ports are open or closed, but a firewall could also be able to do more than that.

***

Some more reference for later use (not completely correct for the sme server but still instersting):

http://www.linuxtopia.org/online_books/centos_linux_guides/centos_linux_reference_guide/s1-iptables-init.html

And the adress for the standard sme server firewall config script:

/etc/rc.d/init.d/masq

For checking status

iptables -L
iptables -L -n
iptables-save

[arne]

A small script for flushing out the existing firewall to leave everything open for monitoring of trafic:


#!/bin/sh

# Flush
iptables -t nat -F
iptables -F
iptables -X
iptables -Z

# Set policies to open
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

[arne]

Installation of some tools:

yum install --enablerepo=base --enablerepo=updates --enablerepo=addons nmap

yum install --enablerepo=base --enablerepo=updates --enablerepo=addons ethereal

yum install --enablerepo=base --enablerepo=updates --enablerepo=addons iptraf

[arne]

Revision 0.0.0.0, first start ..
(Firewall script for the server-only installation.)

# Start

# A simple rule stack for a server.
# No filtering of trafic out.
# Rules are performed from top to bottom.
# No entrys to log this time

# Flush, reset firewall
iptables -F
iptables -X
iptables -Z

# Set the policy, the defult last rule
# The input chain is completely closed.
# The output chain is open.
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# Drop all packets with false destination adress
iptables -A INPUT -d ! 10.0.0.4 -j DROP
# Drop all packets with false source adresses
# Not implemented yet

# some filtering for spoofed packets
# to filter out packest with imposible setteing of flags
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

# Lock out some bad guys:
iptables -A INPUT -s 123.123.123.1 -j DROP
iptables -A INPUT -s 123.123.123.2 -j DROP
iptables -A INPUT -s 123.123.123.3 -j DROP

# Restrict dataflow to prevent dos attcks
# Not impemented yet.  

# Open ports on router pc for server/services
# Web mail and some other functions will require lo to be open:
iptables -A INPUT -i lo -j ACCEPT
# Opening of tcp ports for ftp. Unclear if both has to be open.
iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
# Open tcp 22 for the ssh deamon  
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Open tcp 25 for the mail server
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# Open tcp 80 for the web server
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Open tcp 110 for the pop server
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# Open tcp 443 for the https server (ssl)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Open for the local dns server
iptables -A INPUT -p udp --dport 53 -j ACCEPT

# Dynamic opening / stateful inspection for input chain.
# If the server works as a client, it will dynamically have to open for
# the return trafic.
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# End



Any ideas or sugestions or revisions are welcome.

NOTE: Don't play with the firewall on a remote controlled server. You will easily lock your self out. Play with the firewall only when you have console access !

[arne]

Temporary revision.

A bit half done at the moment but with working burst/rate control:
(But right values has to be set trough testing of server)

# A simple rule stack for a server.
# No filtering of trafic out.
# Rules are performed from top to bottom.
# No entrys to log this time

# Flush, reset firewall
iptables -F
iptables -X
iptables -Z

# Set the policy, the defult last rule
# The input chain is completely closed.
# The output chain is open.
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# Drop all packets with false destination adress
# iptables -A INPUT -d ! 10.0.0.4 -j DROP
# The above prevented logon to the server-manager panel can not be used
# Drop also all packets with false source adresses
# Not implemented yet

# some filtering for spoofed packets
# to filter out packest with imposible setteing of flags
# Ref. Firewall book R Ziegler &  
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

# Lock out some bad guys:
iptables -A INPUT -s 123.123.123.1 -j DROP
iptables -A INPUT -s 123.123.123.2 -j DROP
iptables -A INPUT -s 123.123.123.3 -j DROP

# Restrict dataflow to prevent dos attacks
# Common rule for all servers. Could also be sat up individually.
# Right values for limit and limit-burst will have to be experimented with
# limit = trafic avarage, limit-burst, for a very short period.  
iptables -N syn-flood
iptables -A INPUT -p tcp --syn -j syn-flood
iptables -A syn-flood -m limit --limit 16/s --limit-burst 24 -j RETURN
iptables -A syn-flood -j DROP

# Open ports on router pc for server/services
# Web mail and some other functions will require lo to be open:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -d 127.0.0.1 -j ACCEPT
# Opening of tcp ports for ftp. Unclear if both has to be open.
iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
# Open tcp 22 for the ssh deamon  
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Open tcp 25 for the mail server
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# Open tcp 80 for the web server
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Open tcp 110 for the pop server
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# Open tcp 443 for the https server (ssl)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Open for the local dns server
iptables -A INPUT -p udp --dport 53 -j ACCEPT

# Open port for PPTP VPN
# iptables -A INPUT -p tcp --dport 1723 -j ACCEPT

 
# Dynamic opening / stateful inspection for input chain.
# If the server works as a client, it will dynamically have to open for
# the return trafic.
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

[arne]

For later reference. From a running sme 7.0 server with most things open and running:


[root@sme7 init.d]# nmap localhost

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2006-08-21 00:41 CEST
Interesting ports on localhost (127.0.0.1):
(The 1643 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
80/tcp   open  http
110/tcp  open  pop3
139/tcp  open  netbios-ssn
143/tcp  open  imap
389/tcp  open  ldap
443/tcp  open  https
445/tcp  open  microsoft-ds
465/tcp  open  smtps
515/tcp  open  printer
548/tcp  open  afpovertcp
980/tcp  open  unknown
993/tcp  open  imaps
995/tcp  open  pop3s
1723/tcp open  pptp

Nmap run completed -- 1 IP address (1 host up) scanned in 0.291 seconds


It should actually be rather easy to make and maintain a script that gives lan access only for lan the lan serices that will be used and internett access for those internett services that will be used, and then to block unvanted ip's, some spoofing filtering, some dos trafic limiting etc.

[arne]

Some more reference:


Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2006-08-21 00:57 CEST
Interesting ports on localhost (127.0.0.1):
(The 1471 ports scanned but not shown below are in state: closed)
PORT     STATE         SERVICE
53/udp   open|filtered domain
67/udp   open|filtered dhcpserver
123/udp  open|filtered ntp
137/udp  open|filtered netbios-ns
138/udp  open|filtered netbios-dgm
1812/udp open|filtered radius
1813/udp open|filtered radacct

Nmap run completed -- 1 IP address (1 host up) scanned in 1.567 seconds