Buchan Milne <[EMAIL PROTECTED]> writes:
Hello,
> Firstly thanks to all the developers of SNF, it is a very easy-to-use
> product.
We're very happy about it but we're aware that there are plenty of things
on our TODO list.
>Unfortunately I have some issues with it:
>
> 1)Desire for a DMZ:
> If there is anyone considering adding a DMZ feature for SNF, I cast my
> vote for it now, and would be happy to help.
yes, there are some plans in using shoreline firewall script instead of
bastille which was initially not designed to use DMZ. You can create though
a sort of a DMZ with two firewalls in a row. The zone between the two
firewalls will be the DMZ and each firewall will have only
internal/extrenal sides and not three NICs like most of the DMZs. Of
course, you'll need two firewalls instead of one.
> 2)DHCP and WINS:
> I am currently using the dhcp server on SNF for our network. Unfortunately
> the default values for the following dhcp options are incorrect, and could
> result in very BAD THINGS (tm) on a mainly windows network (ok, so most of
> our desktops are windows, but all but one of the servers are Mandrake, and
> the one Windows machine was not my decision):
>
> option netbios-name-servers
>
> This should be set to the ip address of a netbios name server (aka WINS
> server). This can either be a Windows NT/2000 server or a samba server,
> set up to be a wins server. This is currently set by the web interface to
> be the IP of the SNF. This is going to have all the windows machines
> throwing packets at the SNF, which is a bad thing unless samba is going to
> be part of SNF.
>
> option netbios-node-type
>
> This option sets how the windows machines resolve computer names (similar,
> but not as configurable as the samba parameter "name resolve order"). The
> default in SNF is 8, which means (according to the dhcp-options man page)
> use WINS only.
>
> These 2 options together will TOTALLY kill browsing (ie Network
> Neighborhood) on a windows network, since the machine will try resolving
> names by WINS, which will fail. They will even not try broadcasting (the
> defaultif now WINS server is specified by dhcp)
>
> There needs to be an option somewhere to specify the WINS server address
> somewhere, or the node-type should be changed to something less than 8.
> (If the WINS is outside the internal network (as in our case) it might be
> nice to add an option to allow WINS traffic through the firewall.) For
> example, node-type 4 is WINS first then broadcast which might be feasible
> ....
You're absolutely right. I was thinking of a more complicated dhcp
configuration, also with samba configuration, etc but I was asked to
simplify to the minimum so that a newbie can configure it.
You can, of course, modify the /usr/share/naat/templates/etc/dhcpd.conf
template file and comment/modify the netbios lines and reconfigure dhcp
through the web interface.
> 3)Allowing smb traffic over the firewall
> We are actually migrating over the firewall at the moment, but I have had
> trouble allowing smb traffic to cross the firewall. To ensure things work
> for the moment (well, kind of) I have put a 2nd interface on our samba
> Primary Domain Controller, and routed some printing through it with CUPS
> and samba. However, in the future we might want to be able to allow
> traffic from selected hosts to access smb service on our network. I have
> added rules allowing ports 137-139 both TCP and UDP, but this does not
> seem to work. It would appear that this is prohibited in
> /etc/rc.d/init.d/bastille-firewall (~ line 306):
>
> ${IPCHAINS} -A forward -p tcp -s 0.0.0.0/0 137:139 -d 0.0.0.0/0 -j
> ${REJECT_METHOD} ${LOG_FLAG}
> ${IPCHAINS} -A forward -p udp -s 0.0.0.0/0 137:139 -d 0.0.0.0/0 -j
> ${REJECT_METHOD} ${LOG_FLAG}
>
> It seems that this might also mess with WINS (I tried to use the external
> WINS server, but no addresses got updated ....)
you should activate the logs of the rejected packets and then check the result.
> 4)Routing without masquerading
> (Disclaimer: I have only started reading up on ipchains etc in the past
> few days, so I might be incorrect here. However, I believe users of SNF
> shouldn't have to read man ipchains to get this to work IMHO)
>
> We implemented a firewall to protect us from users inside the firewall on
> our ISPs network. We have a real (public) subnet, and thus would like to
> have routing and firewalling, with no masquerading (except maybe a DMZ,
> see above ;-)). At present, the output of "service bastille-firewall
> status" includes the following:
>
> MASQ all ------ <our_real_internal_subnet> 0.0.0.0/0
> n/a
>
> which appears to be incorrect. Tracking the problem down, it seems that
> the interfaces for masquerading are determined as follows
> (/etc/bastille-firewall.conf):
>
> for i in ${INTERNAL_IFACES} ; do
> IP_MASQ_NETWORK="${IP_MASQ_NETWORK} `LANG=en LANGUAGE=en ifconfig ${i} |
> grep "inet addr" | awk '{print $2":"$4}' | awk -F: '{print $2"/"$4}'`"
> done
> Should this not include only private (192.168., 10., 172.16.-172.31)
> networks? Then there should probably also be a rule allowing traffic
> (routing)?
you're right again, this firewall was designed for small offices and
therefore we assumed that will be no public internal networks. We are
masquerading everything and did not give the opportunity to route
without masquerading ...
As I said, we still have a lot to do ...
have a nice day,
--
Florin http://www.mandrakesoft.com
