Interesting scenario… a couple of ideas how this could work:
- My general preference is to keep the Yast interface working as much as
possible, so I’ll start there.
Within the framework of the default Firewall the SUSE folks anticipated a
need to extend in known and unknown ways. The way to see all of the
SuSEfirewall2’s options is to look through /etc/sysconfig/SuSEfirewall2
and set things in there as appropriate. I usually do this for setting up
port forwarding on a host so that services, such as Apache Tomcat, can be
bound to a port like TCP 8443 and magically (per the firewall) get data
sent to the system’s TCP 443 ports which is done with the FW_REDIRECT
option in there. I’m hoping that one of the options in there can let you
do what you want without going to the “unknown ways” option, which I’m
pretty sure will work for you.
The way SUSE let people do anything else while keeping SuSEfirewall2 is by
using the following directive from that file:
## Type: string
#
# 25.)
# Do you want to load customary rules from a file?
#
# This is really an expert option. NO HELP WILL BE GIVEN FOR THIS!
# READ THE EXAMPLE CUSTOMARY FILE AT
/etc/sysconfig/scripts/SuSEfirewall2-custom
#
#FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
FW_CUSTOMRULES=""
Note the disclaimer in there about not being supported, etc. With this we
basically create a file somewhere (as defined above usually) and then put
our iptables rules directly in there.
A quick note on defaults for the firewall: by default a firewall is (and
should in my opinion) be setup as a whitelist, meaning you block
everything and then allow specific, known things. In your case I believe
what you want is basically a default of block everything with a couple of
exceptions around your internal network (allow anything there) and then
accessing one remote system for mail purposes. Unusually, you want to do
this for both incoming AND outgoing traffic, where usually firewalls focus
on incoming traffic and allow outgoing stuff to just happen (at least by
default).
Because the SUSE firewall is pretty close to this by default (it blocks
everything incoming, and allows everything outgoing) I would think you
could accomplish this by leaving the firewall in its default state, and
then adding a FW_CUSTOMRULES file that basically allows anything from the
internal network, allows traffic to (but not from?) the external mail
server, and then explicitly blocks anything else outgoing,
Warning: before tinkering with the firewall you should be sure you have a
way into the system that doesn’t require a working firewall, just in case
you block yourself, such as the physical or VM console.
The lines to add to your custom file MAY be the following based on
freeform typing on my end and not actually testing (since if I implement
this I’ll lose access to my system entirely); be sure to define NIC as
your valid NIC device (eth0 usually) and the internal network as well:
#Setup some variables
IPT='/usr/sbin/iptables'
NIC='eth0'
INTERNALNET='192.168.0.0/24'
#Allow outgoing stuff to the internal network
${IPT} -A OUTPUT -o ${NIC} -d ${INTERNALNET} -j ACCEPT
#Block everything else outgoing
${IPT} -A OUTPUT -o ${NIC} -j DROP
#Allow incoming stuff from the internal network
${IPT} -A INPUT -o ${NIC} -d ${INTERNALNET} -j ACCEPT
#Any other traffic incoming should DROP by default
If that does not work properly one reason why may because of how the
SUSEfirewall2 service sets up other chains from INPUT, such as input_ext.
iptables is really neat because you can do this, but it makes customizing
dynamically a little harder. Also iptables is neat because rules are
applied in order, and it also allows inserting rules in specific spots in
the order (using -I instead of -A), but knowing that correct spot can be
tricky. As a result, if the above does not work, then post he output from
‘/usr/sbin/iptables-save’ and let’s look at it.
Be sure when you modify that custom file with those commands above that
you restart the firewall to apply the changes:
rcSusEfirewall2 restart
- The other option is to disable the SuSEfirewall2 service and instead
use your own scripts to setup the system’s firewall using iptables as most
other distributions will. This has the advantage of infinite
customizability, and the downside of no use of Yast, plus maybe being a
non-standard system that you (or coworkers, or successors, or others)
forget or do not realize is not using Yast in the future.
A good read on a custom firewall comes from a guy at SUSE who is very
knowledgeable on the topic:
https://www.novell.com/coolsolutions/feature/18139.html
He had a follow-up article as well where he did a bit more:
https://www.novell.com/coolsolutions/feature/19967.html
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…