On Fri, 7 Nov 2008, Theo de Raadt wrote:
>> >Peter N. M. Hansteen wrote:
>> >> Harald Dunkel <[EMAIL PROTECTED]> writes:
>> >>
>> >>> Sorry to wake this thread up again, but this problem is a severe
>> >>> security risk. IMHO it is unacceptable that a hardware failure on
>> >>> one NIC of a firewall can put the whole network at risk, just because
>> >>> the mapping between NICs and interface names gets mixed up, and PF
>> >>> suddenly treats the Internet as a subnet of the company LAN.
>> >>
>> >> Semi-random reordering of network interfaces would be a severe
>> >> problem, no doubt. However, my hazy memory was that reordering would
>> >> not occur as you describe, but ICBW, please correct me if this has
>> >> actually been demonstrated to happen.
>> >
>> >I can post 2 dmesg logs of the same machine with the NIC
>> >names mixed up. Somehow 2 NICs disappeared on a reboot. On
>> >the next reboot they were back. Attached is the diff.
>> >
>> >In the bad configuration the NIC with 00:30:48:d2:9a:06 is
>> >called "em2", in the good one it is called "em4". Maybe you
>> >can imagine how PF screws up, if this NIC would have been
>> >physically connected to the Internet.
>> >
>> >Surely it is unusual that a NIC "disappears" somehow. Maybe
>> >there is something wrong with my hardware, but this can always
>> >happen. I would like to have a secure setup even if there is a
>> >hardware failure.
>>
>> Network configuration has bugged me a bit ever since I started using
>> OpenBSD, not just the real security issue that Harald Dunkel points out
>> but general ease of administration issues. For example, on a typical
>> single-NIC system one ought to be able to set up a standard
>> configuration and not care which make/model of NIC is installed.
>
>You are joking right? In that case you use the "egress" interface
>group. It works perfectly on all machines with one network interface,
>and follows the default route.
Maybe I'm just confused, but my recollection is that one needs to set up
the appropriate hostname.<interface-name> to enable the interface before
the "egress" interface group works.
This single-NIC case is admittedly a minor one, but it would eliminate
one of the few (that I can think of) things about running a basic
OpenBSD system that requires any "arcane" setup.
>Or would you rather use eth0?
Since I never mentioned eth0, the answer is pretty obviously "no".
>> Perhaps most of these issues could be dealt with by changing the network
>> configuration procedure to have a hierarchy of interface-configuration
>> files rather than just hostname.<interface-name>.
>
>Oh, like eth0 and eth1 and eth2?
See above.
>> If hostname.<mac>
>> were used if the hardware MAC matches, then hostname.<interface-name>,
>> then (say) hostname.only if there's only one NIC found, the sysadmin
>> could assign interfaces to groups and use those group names everywhere,
>> and so not need to use the actual interface names at all.
>
>So right now you have hardware that is disappearing. What happens when
>you get hardware where the MAC reading is not 100% reliable. New problem,
>and a new solution?
Actually, it's other people who have the problem. I was just
speculating on how to minimize its harmful effects.
One can always postulate a hardware (or other) failure which can't be
dealt with by whatever the current software may be; the question is
whether it happens often enough and is serious enough to be worth doing
something about. Or if it suggests a change which is worthwhile in
itself and also solves the problem.
>> This appears to be a fairly simple change. Does it sound reasonable to
>> people with more knowledge of OpenBSD networking?
>
>No, it is not reasonble. You are inventing problems at a very high
>level just because some very low level pci-related bug is making some
>of your devices not reliably show themselves.
No, I'm thinking about a general way for those people who care about it
to tie pf rules, etc, to specific physical interfaces, regardless of
what other devices are installed or configured in a system.
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
