If you need to configure a firewall behind which will be a name server it is
useful. Specifically it is useful to be able to simply block all traffic to and
from the "privileged" ports, 0-1023. If you are not already running a firewall
then your machine is probably wide open, especially if you have one of the stock
distributions installed. Having a dynamic IP does mitigate the problem and only
being online for short periods of time also mitigate the problem but they do not
solve it. My network is connected to the Internet 8~12 hours a day and the
firewall is port scanned about twice a week. I have this exact configuration
and my solution is the following:
bringup tcp 30 tcp.dest=tcp.domain
bringup tcp 30 tcp.source=tcp.domain
bringup udp 30 udp.dest=udp.doamin
bringup udp 30 udp.source=udp.domain
ignore tcp 30 tcp.dest=tcp.domain
ignore tcp 30 tcp.source=tcp.domain
ignore udp 30 udp.dest=udp.doamin
ignore udp 30 udp.source=udp.domain
accept any 300 any
While the link does indeed come up whenever I boot, in the absence of further
traffic it is dropped 30 seconds later. Running named will create some amount
of traffic. If you can not deal with the link going up for this traffic then
you probably need something like the masqdialer instead of diald.
Edward Doolittle wrote:
>
> On Thu, 4 Feb 1999, Lourdes A Jones wrote:
>
> > Bind 4 named always used port 53 and was therefore ignored, Bind 8 named
> > uses a random high port by default and is therefore suspect. (RH 5.2 comes
> > with Bind 8) Edit the /etc/named.conf file and add (or uncomment)
> > 'query-source address * port 53;' in the options section. Now named to
> > named transfers will be ignored again.
>
> I assume there's a security reason why named now uses random high ports.
> Does anyone know what the risk is? Is it something to which only
> machines continually connected to the internet are vulnerable? Does
> dynamic IP assignment mitigate the risk?
>
> >> xntpd is one service that tries to resolve names when it starts up. It
> >> could be just about anything.
>
> > Check your init settings and make sure that diald is brought up after any
> > other services that will try and make a connect. In my case the init files
> > were named S57diald (in the rc3.d, rc4.d and rc5.d directories) renaming
> > them S98diald solved the problem.
>
> Good idea ... that change should be worked into redhat, debian, etc., if
> it isn't already. However, I'm concerned that it may lengthen the boot
> process, and that packets or name resolution requests may linger on until
> diald is started. Perhaps there's another way ... some sort of named
> forwarding configuration?
>
> Ed
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
