Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: uli334 on May 02, 2007, 06:31:07 AM
-
Hello,
I'm using SME as firewall for a schools net. Now I want to block some ports for outgoing traffic (ICQ i.e.).
Does anyone know of contribs which allow blocking ports, or can give an example of setting the correct "masq" - rules to block outgoing ports or port-ranges?
Thank you,
uli334
-
i recently installed snort,guardian & oink and guardian has 2 scripts built in for blocking and unblocking by ip address
its very simple to use
sh /sbin/guardian_block.sh <IP> eth0
or
sh /sbin/guardian_unblock.sh <IP> eth0
the settings are only applied for 24 hours or unless the server is rebooted, i think the scripts could be modified to block on a more permanent basis.
-
you may want to look at
http://mirror.contribs.org/smeserver/contribs/jbennett/sme7/squidguard/
I am not shure if Squidguard will doo what you want, but it may be worth a try.
Bob
-
Hello,
no, I use SquidGuard for filtering Internet Traffic, so that our users can't reach some sites with unwanted content.
Also, I don't want to deny some IPs in the local network to reach the Internet.
What I want is to block the total traffic on some ports i.E. so that you can't use ICQ (Port 5190) on all machines in the local net.
That can only be reached by modifying the SMEs firewall rules (masq).
Maybe there is a contrib for that purpose, our an Example of closing one outgoing port...?
Greetings,
uli334
-
sounds like a very good contrib, i think i will have to give it a try myself
-
Submit a new feature request in bugzilla.
I myself would be interested in this as I have been working to lock down more strictly several servers. There is port-forwarding already that may be a good template. I will look for a src and have a look.
Craig
-
If you start me off requesting new features from SME i'll be doing it all day
I already think SME has so much useful features built in but a few other bits would make it unbeatable, even though its pretty close now.
I have tested Clarkconnect for several months to see how it panned out compared to SME. I did like the idea of a firewall panel with a status section to show you possible attacks and give you the chance to block the offending ip but that was about it.
I know SME manages the firewall on its own and there is no real need from user input. However i do think it would be nice to have some sort of iptraf implementation into the server manager so atleast the admin can view possible attacks and give an option to block if needed. I know this can be achieved in other ways (snort,guardian) but i really think snort and guardian should be built into the base. (Dont flame me for suggesting a base update,modification) I appreciate how much hard work the developers put into SME, i have read a topic reguarding how much time/effort needed to make changes to the base, i just thought it would be a cool feature that would attract more people to switching.
Thanks again to all the devs
-
This is what I use to block outside AOL access for example...
Create your...
/etc/e-smith/templates-custom/etc/rc.d/init.d/masq
Then 2 files...
00Definitions2
35SpecificBlocking
Then in the 00Definitions2 file put this in...
{
$OUT .= <<HERE;
LOCALIP=\$\(/sbin/e-smith/db configuration get LocalIP\)
if [ -z "\$LOCALIP" ]
then
# Set LOCALIP to internal loopback
OUTERNET=127.0.0.1
fi
HERE
}
Note a return at bottom after }
And in 35SpecificBlocking
{
$OUT = '';
# Users on LAN are not allowed to access to AOL
# servers on Internet.
# Block any outgoing connections to AOL servers
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 5190\\\n";
$OUT .= "\t--jump LOG --log-prefix \"denylogaoloutside: \"\n";
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 5190 --jump DROP\n";
}
Change "--dport 5190" to port you wish to change.
Now run expand-template \etc\rc.d\init.d\masq and restart service with service masq restart
Original thanks go to "Pascal Schirrmann" pointing me in right direction over on dev list a while ago.
-
A question from someone that doesn't know much about custom templates and scripting...
Can you repeat that code with different port numbers in the same custom template? For example:{
$OUT = '';
# Users on LAN are not allowed to access to AOL
# servers on Internet.
# Block any outgoing connections to AOL servers
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 5190\\\n";
$OUT .= "\t--jump LOG --log-prefix \"denylogaoloutside: \"\n";
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 5190 --jump DROP\n";
}
{
$OUT = '';
# Users on LAN are not allowed to access to Remote Desktop
# servers on Internet.
# Block any outgoing connections to Remote Desktop servers
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 3389\\\n";
$OUT .= "\t--jump LOG --log-prefix \"denylogRDoutside: \"\n";
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 3389 --jump DROP\n";
}
Not that I want to block remote desktop at this point, it was just the first port to pop in my head...
Next question, can you block a range of ports in this fashion?
Ryan
-
A question from someone that doesn't know much about custom templates and scripting...
Can you repeat that code with different port numbers in the same custom template? For example:{
$OUT = '';
# Users on LAN are not allowed to access to AOL
# servers on Internet.
# Block any outgoing connections to AOL servers
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 5190\\\n";
$OUT .= "\t--jump LOG --log-prefix \"denylogaoloutside: \"\n";
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 5190 --jump DROP\n";
}
{
$OUT = '';
# Users on LAN are not allowed to access to Remote Desktop
# servers on Internet.
# Block any outgoing connections to Remote Desktop servers
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 3389\\\n";
$OUT .= "\t--jump LOG --log-prefix \"denylogRDoutside: \"\n";
$OUT .= " /sbin/iptables --table nat --append PREROUTING\\\n";
$OUT .= "\t-i \$INTERNALIF -p tcp --dst ! \$LOCALIP --dport 3389 --jump DROP\n";
}
Not that I want to block remote desktop at this point, it was just the first port to pop in my head...
Should work, yes.
Next question, can you block a range of ports in this fashion?
Ryan
Yes, change the --dport 3389 to --dport 100:200 so it now blocks between 100-200
-
There was a contrib available for this request (to block specific outgoing ports) from Dungog (www.dungog.net) - but that was for SME6 only.
I do not believe they have a contrib for SME7 (yet) but it might be worthwhile to ask about that. Maybe it's possible to upgrade their old contrib?
Note: This might become a paid/sponsored task.
Michael
-
Should work, yes.
Next question, can you block a range of ports in this fashion?
Ryan
Yes, change the --dport 3389 to --dport 100:200 so it now blocks between 100-200
Excellent! Thanks!
Ryan
-
this method as a NFR
http://bugs.contribs.org/show_bug.cgi?id=2977
-
> this method as a NFR
> http://bugs.contribs.org/show_bug.cgi?id=2977
I added details of this method to
http://wiki.contribs.org/SME_Server:Documentation:FAQ#Firewall.2FPort_Forwarding.2COpening.2CBlocking
See "I want to block outgoing traffic from my server."
-
If you want to control the traffic out from a school gateway I guess it will not be an effective method to block one and one port, at it will be "normal procedure" for some unwanted applications to just switch over to some other open port. It is easy to end up closing ports and ports, while it will never be enough of closed ports.
The other approach is to set the default policy for outgoing traffic to all closed and then to open one and one port as required. This will be a some more effective approach.
I have made such an firewall implementation on my Sme 7.2 and I am using it and testing it now. (Zero problems until now, but I like to test it longer and more over time.)
By the way applying major changes on the fireall system is generally a dangerous thing to do, jut to have mentioned that.
If it was "a quite usual thing" to make major changes on the sme server firealling system there would certainly be a nuber of sme servers that were hacked due to missconfiguration, and there would also be a number of "incorrect asked or missleading questions" on the support forum that will be asked as if it was a server issue, but that in the real life is related to a missconfigured firewall. (That's how it use to be with firewalls.)
The disadvantage of allying a "full packet filtration" of outgoing traffic is that there will be som users that will ask: Why does not service x work on my PC ? The standard answer will be: "You will have to send a request to the administrator get your client program on the list of approved traffic."
Even though you do a filtration of outgoing traffic it might still be possible to perform a irregular use of the approved ports. As an excample: port 443 is the port of the ssl encrypted web traffic (https://..) It is quite easy to set up any encrypted tunnel trough port 443 and for most firewalls will be rather difficult to tell the difference between a datastram contained encrypted ssl datas ans other encrypted datas. Some programs that might be unwanted has automated procedures for finding and using an open port 80 and an open port 443 in the outgoing traffic direction.
On the other hand a policy of allowing only certains ports and protocolls might reduce unwanted traffic.
I think it would require a rather big project to make major changes to the SME server firewlling system, but on the other hand to have an option: "Apply rules for restricted outgoing traffic" and then to leave open just a few standard ports for outgoing traffic, that might not reqire a big modification.
One other advantage of doing outgoing firewalling is that you can reduce the damage potencial, in some way, if internal (Widows) clients get hacked or infected by virus or other malware.)
By the way I was banned and refused to log on to the contribs.org for a few days. Hopefully I will not be locked out again, even though mentioning a few words about security and firewalling.
By the way, I will try to send a suggestion to bugzilla about a "restricted traffic out" option, in the nearest future, if I'm not locked out again, as I believe such a modification (as an option) technically could be relatively easy implemented to the existing firewalling and template system, while on the other side having a major influence over the overall network security.
-
Hi Arne,
Doesn't the SME solution mentioned above your post allow exactly what you are talking about - ability to block all ports outgoing (except mail).
http://wiki.contribs.org/SME_Server:Documentation:FAQ#Firewall.2FPort_Forwarding.2COpening.2CBlocking
At least that is the way that I read it. I have read a number of your posts now, and this seems to be a recurring theme / focus for you. The issue I guess is that for any solution to be adopted it does need to fit in with the SME structure to ensure updating doesn't adversely affect (or simply remove) customisations.
You are right in respect to the difficulty of blocking some applications by port number (although research generally identifies a range to block that is effective). SME has always considered internal generated traffic as safe (correct me if this generalisation is too broad, those with more experience). In most cases this is secure enough, although hardware and other firewalls are recommended if security is a priority.
The solution given above does all you have discussed - kudos to the team, this community is alive and kicking! 8) - (and the rest of us have from time to time identified as troublesome) with the exception that it is a console based solution.
I think the project now needing encouraging and input (and possibly funding!) would be a server-manager interface for this excellent fix to a community identified need, although this really would be the icing on the cake.
-
shell (& arne)
The solution given above does all you have discussed .... with the exception that it is a console based solution.
I think the project now needing encouraging and input (and possibly funding!) would be a server-manager interface for this excellent fix to a community identified need, although this really would be the icing on the cake.
As I understand it, developers time & effort is given to the tasks with a higher priority.
Developing a server manager GUI panel for seldom used settings that can quite easily & quickly be done with db commands is probably a poor use of limited resources.
The other aspect to consider is that as the sme server (ie the server manager) is aimed at non technical administrators, then having technically complex settings available in a server manager panel will reduce the ease of use and potentially reduce security (due to possible incorrect usage).
It's therefore better for a number of reasons to leave some settings out of the GUI server manager, and only have them managed by db commands, rather than ever put them into a server manager panel.
-
Shell ->
Doesn't the SME solution mentioned above your post allow exactly what you are talking about - ability to block all ports outgoing (except mail).
The thing is that when it comes to Linux firewalling "outgoing" can meen to completely different kind of "outgoing traffic", it can be "outgoing" from the internal server processes and it can be "outgoing" from the LAN network segment.
When I read from the guide:
"I want to block outgoing traffic from my server. " I read that as: "I want to block the outgoing traffic from the internal processes on my server." (A litle bit above in the same guide they talk about opening ports and then it is reasonable clear that is a question of opening ports into the internal processes running on the server.)
When on the other hand I look into the text of the modification I find the following:
$OUT .= " /sbin/iptables --table nat --append $pf_chain \\\n";
It's still a bit unclear, but it might be you are right. Table Output is basically doing the outgoing filtering from the server while table Forward is basically doing the firewalling out from LAN. Table nat in this case should indicate something that has to do with the nat mechanism wich eventually should mean the trafic out from LAN.
I will try to look into it and also test it out.
-
To All
The location of the sme solution mentioned in this thread has changed from the FAQ to the Firewall page
http://wiki.contribs.org/Firewall#Block_outgoing_ports