Re: Required firewall support
On 21-Mar-05, 12:39 (CST), David Weinehall <[EMAIL PROTECTED]> wrote: > On Sun, Mar 20, 2005 at 11:22:48AM -0600, Steve Greenland wrote: > > > > And that's what we do. But some other OSs (Solaris) do support strict > > multihoming with a config parameter, it would be nice if Linux did. > > netdev@oss.sgi.com <--- patches goes that way. > linux-kernel@vger.kernel.org <--- or possibly that way. It's been discussed and rejected in the past. The multi-homing RFC (I forget which one) has unclear[1] wording on which behaviour is proper. Steve [1] Well, *I* (and others) don't think it's unclear. The trouble is that many others also don't think it's unclear, but come to an opposite conclusion. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > Either someone > cares enough to write (or adapt) the management tools and it gets included, > or they don't and it doesn't because nobody in their right mind would > deploy it in any widespread fashion. But the latter is already true, and irrelevant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Sun, Mar 20, 2005 at 11:22:48AM -0600, Steve Greenland wrote: > On 19-Mar-05, 10:00 (CST), Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > > > Umm, rp_filter is for rejecting packets whose *source* address is from the > > wrong network. > > Right. I know this. But what Joel was originally talking about was > rejection of packets on interface A that are destined for an address on > interface B; Joel seemed to be claiming that if this didn't happen by > default, then the OS was a "toy"; I was pointing out that Linux itself > fails this. Not precisely accurate; I claimed that having a way to *make it* a default was a fairly important factor. Linux does fail it, which is part of why I think the Linux network stack blows goats in a few ways (there are others, not the topic of this conversation). Nor does it have to be on-by-default; there are sane (to some views) reasons to have the Linux behavior, for example, even if I don't agree with them as a default, but being able to flip a switch so that it was the case would suffice. Of course, since it has been claimed that the Hurd basically supports all of the listed criteria anyway (or, at the very least, as many as Linux does), I'm not sure why this thread is even still going. Either someone cares enough to write (or adapt) the management tools and it gets included, or they don't and it doesn't because nobody in their right mind would deploy it in any widespread fashion. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Required firewall support
On Sun, Mar 20, 2005 at 11:22:48AM -0600, Steve Greenland wrote: > On 19-Mar-05, 10:00 (CST), Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > > > Umm, rp_filter is for rejecting packets whose *source* address is from the > > wrong network. > > Right. I know this. But what Joel was originally talking about was > rejection of packets on interface A that are destined for an address on > interface B; Joel seemed to be claiming that if this didn't happen by > default, then the OS was a "toy"; I was pointing out that Linux itself > fails this. > > > If you want to block accepting your own address as the *destination*, then > > no, there's no config parameter for that. Use iptables rules. :-/ > > And that's what we do. But some other OSs (Solaris) do support strict > multihoming with a config parameter, it would be nice if Linux did. netdev@oss.sgi.com <--- patches goes that way. linux-kernel@vger.kernel.org <--- or possibly that way. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
* Wouter Verhelst wrote: > Note that some packages, directly or indirectly, build-depend on > packages containing daemons that will be started by default if > installed. In that light, a firewall really is required to keep things > safe. IMO most notably, because many users will hit that: KDE -> famd -> portmapper While I would not judge on portmappers security, it is certainly not a service which most users need to have exposed to the internet, and so it shouldn't be by default. Of course, the proper solution would be to a) do not make fam depend on portmapper or b) alter portmapper to listen for local connections only, neither of both has been implemented for some time now... Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote: > On Wed, 16 Mar 2005 20:39:48 -0700, Joel Aelwyn <[EMAIL PROTECTED]> > wrote: > >* The first rule of securing a machine exposed to the wilds is "Deny by > > default, allow by need". > > Which is pretty well accomplished by only running needed services. Note that some packages, directly or indirectly, build-depend on packages containing daemons that will be started by default if installed. In that light, a firewall really is required to keep things safe. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On 19-Mar-05, 10:00 (CST), Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > Umm, rp_filter is for rejecting packets whose *source* address is from the > wrong network. Right. I know this. But what Joel was originally talking about was rejection of packets on interface A that are destined for an address on interface B; Joel seemed to be claiming that if this didn't happen by default, then the OS was a "toy"; I was pointing out that Linux itself fails this. > If you want to block accepting your own address as the *destination*, then > no, there's no config parameter for that. Use iptables rules. :-/ And that's what we do. But some other OSs (Solaris) do support strict multihoming with a config parameter, it would be nice if Linux did. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Hi, Steve Greenland wrote:
> On 18-Mar-05, 03:28 (CST), Blars Blarson <[EMAIL PROTECTED]> wrote:
>> >Linux fails this. Even with forwarding disabled, it will accept packets
>> >for an address on interface A via interface B.
>>
>> Enable rp_filter and it does reject such packets.
>>
>> echo 1 >/proc/sys/net/ipv4/conf/${dev}/rp_filter
>
> See, that's a nice theory, but it doesn't actually work.
Umm, rp_filter is for rejecting packets whose *source* address is from the
wrong network.
If you want to block accepting your own address as the *destination*, then
no, there's no config parameter for that. Use iptables rules. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Gunnar Wolf <[EMAIL PROTECTED]> writes: > I agree that any Debian architecture needs to provide basic networking > facilities, but I don't think firewalling is a real requirement. Yes, > of course, we expect users to actually _run_ this architecture, and > they will probably be connected to the network, and thus they can be > at risk - But right now Debian installs are done with no firewalling > rules on anyway. Moreover, the question here is not what are good features to have, but what are the features necessary for SCC (or ports, or whatever it's called). Non-released ports don't need buildds run by the Debian system administrators, and don't need lots of them; the point is that porting teams need to be making real progress to be in SCC, but not done. So I'm mostly fine with the requirements as written, but the question still remains: What features, exactly, are meant by "firewalling support" in the requirement? (I know what firewalling is as a general thing, but not which specific features are desired.) And, why is firewalling support essential for SCC? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn dijo [Wed, Mar 16, 2005 at 08:39:48PM -0700]: > Consider: > > * SCC systems have buildds. > > * Buildds must be network accessible. > > * The first rule of securing a machine exposed to the wilds is "Deny by > default, allow by need". > > Therefore, a box which does not provide basic firewalling capabilities > (whether that's achieved by configurable ACLs, mind-reading the human > traffic trigger, or pixies inspecting every packet) is thus not suitable > for running a buildd on, and thus can never achieve SCC status. > > Sorry, but being able to cope with a hostile environment *is* a requirement > in today's network, and there isn't any real way around that fact. I have > no clue where Hurd network filtering stands at the moment, so I can't > comment on how far it is from having this feature. I wouldn't be willing to > admin any such box that was plugged into a network using a ten foot pole, > and I don't see why the DSA folks should be expected to either. I would admin such a machine precisely by using a ten foot pole - That ten foot pole can be materialized into a firewall-able machine sitting between it and the network. I agree that any Debian architecture needs to provide basic networking facilities, but I don't think firewalling is a real requirement. Yes, of course, we expect users to actually _run_ this architecture, and they will probably be connected to the network, and thus they can be at risk - But right now Debian installs are done with no firewalling rules on anyway. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > However, we are not expecting the DSA people to keep the system > > secure; SCC non-released arches don't need to provide developer > > machines. > I do not believe that this is limited to debian hosts. If an OS lacks > the basic security features needed to safely stay on the internet then I > think it's obvious that it's not mature and useful enough to be worth > keeping it in the archive. Once more, we are lacking the actual information here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On 18-Mar-05, 03:28 (CST), Blars Blarson <[EMAIL PROTECTED]> wrote:
> >Linux fails this. Even with forwarding disabled, it will accept packets
> >for an address on interface A via interface B.
>
> Enable rp_filter and it does reject such packets.
>
> echo 1 >/proc/sys/net/ipv4/conf/${dev}/rp_filter
See, that's a nice theory, but it doesn't actually work.
Maybe it's not clear what I'm talking about. Consider a machine with two
interfaces eth0, eth1. Define eth0 as 192.168.0.1 and eth1 as 10.0.0.1.
Disable forwarding, set rp_filter on all interfaces. From another
machine on 192.168.0/24, set your route for 10/8 to 192.168.0.1. Now
ping 10.0.0.1. For bonus points, do 'ifconfig eth1 down', and then ping
from the other machine again. Surprise!
(All with 2.4.18, maybe it's fixed in 2.6.)
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>On 17-Mar-05, 01:01 (CST), Joel Aelwyn <[EMAIL PROTECTED]> wrote:
>> * The ability for an interface to receive, by default, only traffic that
>> is destined for that interface. (Non-promiscuous mode; promiscuous mode
>> availability is a big plus, but not required from the OS point of view)
>
>Linux fails this. Even with forwarding disabled, it will accept packets
>for an address on interface A via interface B.
Enable rp_filter and it does reject such packets.
echo 1 >/proc/sys/net/ipv4/conf/${dev}/rp_filter
--
Blars Blarson [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On 17-Mar-05, 01:01 (CST), Joel Aelwyn <[EMAIL PROTECTED]> wrote: > * The ability for an interface to receive, by default, only traffic that > is destined for that interface. (Non-promiscuous mode; promiscuous mode > availability is a big plus, but not required from the OS point of view) Linux fails this. Even with forwarding disabled, it will accept packets for an address on interface A via interface B. The rest of your points are valid for a *packet filter* firewall that exists *between* the internet and a LAN (and/or DMZ). For a machine that is directly connected, you can run only the services that you're actually supporting, and use tcpwrappers et. al. to control access to those, if you like. Packet filtering is basically irrelevant. And there are other kinds of firewalls besides packet filters. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > However, we are not expecting the DSA people to keep the system > secure; SCC non-released arches don't need to provide developer > machines. I do not believe that this is limited to debian hosts. If an OS lacks the basic security features needed to safely stay on the internet then I think it's obvious that it's not mature and useful enough to be worth keeping it in the archive. -- ciao, Marco signature.asc Description: Digital signature
Re: Required firewall support
On Thu, Mar 17, 2005 at 07:14:27PM +0100, Marc Haber wrote: > On Thu, 17 Mar 2005 10:03:15 -0700, Joel Aelwyn <[EMAIL PROTECTED]> > wrote: > >On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote: > >> I am routinely running systems without any packet filtering capability > >> on the network, and they are perfectly able to cope. They just only > >> accept network connections for needed services. > > > >And just how full of attempts to root SSH are your logs? > > A lot. What's the problem? http://www.cve.mitre.org/cve/refs/refmap/source-BUGTRAQ.html Search for "ssh". You didn't think those scripts the kiddies run appeared just to randomly annoy folks running SSH, did you? Yes, a local admin *can* just disable SSH when faced with a 0-hour announcement. So can a remote admin. The latter, however, is forced to choose between "risk a compromise" or "risk waiting until the local admin can be present", if there isn't any firewall support. If there is, they can slap on a temporary ACL limiting access to port 22 to certain machines that are trusted (maybe they run a different version of SSH that isn't believed to be vulnerable, or maybe they're local to the 'remote' admin, whatever), and be reasonably confident that the script kiddies won't be able to get *to* the SSH daemon to compromise it, until a new SSH package can be built that addresses the vulnerability. There are other concerns which may apply (such as determining whether the SSH daemon has already been compromised, if you don't happen to have an active root shell on the machine in question), but the point stands. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Required firewall support
On Thu, 17 Mar 2005 10:03:15 -0700, Joel Aelwyn <[EMAIL PROTECTED]> wrote: >On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote: >> I am routinely running systems without any packet filtering capability >> on the network, and they are perfectly able to cope. They just only >> accept network connections for needed services. > >And just how full of attempts to root SSH are your logs? A lot. What's the problem? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > If you have all of the filtering rule support, then why is this even an > issue? Write the user-space tool and you should be golden; you've got a > useable firewalling implementation. > > What's the problem? Who said there was a problem? I was asking exactly what support was required. You started talking on about what was a "toy os" and the importance of this or that. It is, however, a very low priority for development, and the people who are likely to do the work would like to know exactly what is being asked. The secondary question, why is this important, is one that perhaps only the people who were at the Vancouver meeting can explain, and unless I've missed it, they have not. > That means firewalling capabilities. It's flat ing insane to expect DSA > folks to try to keep a system secure if it doesn't have basic firewalling. > It's that simple, and it's backed by a couple of decades of best common > practice by both network and systems administrators. Are the DSA people using firewalling features now? I can't see any indication in the config files of the machines I checked when you so confidently asserted they were, but I might have missed something. However, we are not expecting the DSA people to keep the system secure; SCC non-released arches don't need to provide developer machines. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote: > On Wed, 16 Mar 2005 20:39:48 -0700, Joel Aelwyn <[EMAIL PROTECTED]> > wrote: > >* The first rule of securing a machine exposed to the wilds is "Deny by > > default, allow by need". > > Which is pretty well accomplished by only running needed services. A > port without a services is an implicit "deny". > > >Sorry, but being able to cope with a hostile environment *is* a requirement > >in today's network, and there isn't any real way around that fact. > > I am routinely running systems without any packet filtering capability > on the network, and they are perfectly able to cope. They just only > accept network connections for needed services. And just how full of attempts to root SSH are your logs? Just because you *can* cope with that (and there are situations where the fastest patch is to slap an ACL on, say, port 22 until you can fix the real problem, so that you neither lock yourself out of the box's remote access nor leave it open to the kiddies) doesn't mean it is the optimal method, or that DSA should be expected to work without fairly important security tools when asked to keep a box secure. Traffic control policy is a major part of layered security. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Required firewall support
[ Please respect the list code of conduct; I don't request CCs, nor does ] [ my M-F-T get set as such. In other words, don't send them. ] On Thu, Mar 17, 2005 at 12:16:27AM -0800, Thomas Bushnell BSG wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > Fine, if you want to get pedantic, the following is a bare minimum of > > capabilities I would expect from any network processing on a 'real' > > (non-toy) network stack, where 'network stack' means everything between > > hardware driver and delivery of data to a userland application. It's late, > > so this may not be exhaustive. > > The guidelines do not speak of "toy os". It appears that you are not > aware of why this requirement is listed in the guidelines, nor of why > it would be important for the secondary archive, nor of what the > actual practice is on buildds. > > Can we replace this with a thread involving people who do know these > things? > > The Hurd has had all the things listed on your schedule of filtering > rules for longer than Linux has. All that is necessary is simple > user-space tools to implement them. Do you have a specific tool that > should run, or anything else? If you have all of the filtering rule support, then why is this even an issue? Write the user-space tool and you should be golden; you've got a useable firewalling implementation. What's the problem? > > Unless marked as 'nice to have', everything above is a *must* for running > > even basic firewall configurations on a host expected to face the Internet. > > If you can do those, and configure them in some semi-sane fashion, then > > you probably meet the expectations reasonable people would have for "basic > > firewalling". > > But what is not said here is why this particular feature is necessary > for being in the secondary archive, as opposed to other features. > > To say, "a buildd must have that feature" is only sensible if the > buildds are actually *using* such-and-such feature, and you, in fact, > don't know that they are. Allright, since your other email said it didn't have to be hooked up to the w-b network, and seemed to miss the point: To be sane to administer a system which is exposed to general Internet traffic, including through a NAT or other proxy, it is important to be able to control the policy for what traffic is actually passed to the userspace applications, or routed to another network on router-capable OSes (note that being able to route is not, AFAIK, a buildd requirement), That means firewalling capabilities. It's flat ing insane to expect DSA folks to try to keep a system secure if it doesn't have basic firewalling. It's that simple, and it's backed by a couple of decades of best common practice by both network and systems administrators. If you want to avoid this situation, then I suggest you explain how you intend to get things needing build from incoming to your buildd, and the results back to incoming. But you say you have this capability already, perhaps modulo userspace tools to configure it. So get someone to bang them out, and you should be good to go (or, heck, get the existing firewall config tools to support whatever you use to configure this, if they aren't excessively Linux-centric; at the very least, a workalike interface is a good place to start). -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Required firewall support
On Thu, 17 Mar 2005 13:52:23 +0100, Florian Weimer <[EMAIL PROTECTED]> wrote: >* Marc Haber: >> I am routinely running systems without any packet filtering capability >> on the network, and they are perfectly able to cope. They just only >> accept network connections for needed services. > >This is a bit dangerous because any invocation of "apt-get install" or >"apt-get upgrade" can start new server daemons. I do not do that when I am directly on the 'net. otoh, policy-rc.d exists, but is a little clumsy to use these days (remedy is in NEW). Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Required firewall support
* Marc Haber: > I am routinely running systems without any packet filtering capability > on the network, and they are perfectly able to cope. They just only > accept network connections for needed services. This is a bit dangerous because any invocation of "apt-get install" or "apt-get upgrade" can start new server daemons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Wed, 16 Mar 2005 20:39:48 -0700, Joel Aelwyn <[EMAIL PROTECTED]> wrote: >* The first rule of securing a machine exposed to the wilds is "Deny by > default, allow by need". Which is pretty well accomplished by only running needed services. A port without a services is an implicit "deny". >Sorry, but being able to cope with a hostile environment *is* a requirement >in today's network, and there isn't any real way around that fact. I am routinely running systems without any packet filtering capability on the network, and they are perfectly able to cope. They just only accept network connections for needed services. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > Fine, if you want to get pedantic, the following is a bare minimum of > capabilities I would expect from any network processing on a 'real' > (non-toy) network stack, where 'network stack' means everything between > hardware driver and delivery of data to a userland application. It's late, > so this may not be exhaustive. The guidelines do not speak of "toy os". It appears that you are not aware of why this requirement is listed in the guidelines, nor of why it would be important for the secondary archive, nor of what the actual practice is on buildds. Can we replace this with a thread involving people who do know these things? The Hurd has had all the things listed on your schedule of filtering rules for longer than Linux has. All that is necessary is simple user-space tools to implement them. Do you have a specific tool that should run, or anything else? > Unless marked as 'nice to have', everything above is a *must* for running > even basic firewall configurations on a host expected to face the Internet. > If you can do those, and configure them in some semi-sane fashion, then > you probably meet the expectations reasonable people would have for "basic > firewalling". But what is not said here is why this particular feature is necessary for being in the secondary archive, as opposed to other features. To say, "a buildd must have that feature" is only sensible if the buildds are actually *using* such-and-such feature, and you, in fact, don't know that they are. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > For buildds, since I don't run one as either local or DSA admin, I couldn't > tell you offhand. I know what I'd *expect* them to be doing, as general > guidelines, which closely resembles what I do on servers I deploy facing > the net, but I don't know what they *are* doing. The SCC criteria do not require a buildd plugged in to the Debian w-b system. > I have no particular reason to believe that they aren't running a sane set > of firewalling rules; in fact, I would assume that they are, but I don't > feel impolite enough to annoy someone's HIDS log with random checking. What is a "sane set of firewalling rules"? Can you be more specific and less vague? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Wed, Mar 16, 2005 at 07:49:23PM -0800, Thomas Bushnell BSG wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > If you really want this fixed, I suggest finding someone who is well versed > > in both network security issues and Internet protocol fundamentals (not > > just TCP or even just IP, but all the other lovely beasties out there) and > > convincing them it's worth their time (I hear money is often an excellent > > motivator). The issues involved with writing a serious, production-capable > > network stack are really quite non-trivial (and yes, I *do* speak from > > personal experience in this). > > We have a network stack, thank you very much. > > The question is: which specific features do you want? > > "Deny by default" is all you mentioned, and that's already done. > Next? Fine, if you want to get pedantic, the following is a bare minimum of capabilities I would expect from any network processing on a 'real' (non-toy) network stack, where 'network stack' means everything between hardware driver and delivery of data to a userland application. It's late, so this may not be exhaustive. * The ability to associate a network interface with an IP host address, including network/netmask information for that IP subnet, and capable of handling CIDR networks. * The ability for an interface to receive, by default, only traffic that is destined for that interface. (Non-promiscuous mode; promiscuous mode availability is a big plus, but not required from the OS point of view) * The ability to check all inbound and outbound traffic (as well as throughbound if the system is capable of operating as a router between multiple networks) on any interface against a series of filtering rules. * Filtering rules must be able to match against any supported IP protocol, including protocol-specific information (ports for UDP and TCP, for example), as well as ICMP (including message types). IP packets must be able to be matched against source and destination network/host values, as well as additional IP information (such as TOS bits). * Filtering rules must be able to accept, reject, or drop (silent reject) network packets. The ability to manipulate the network stack decisions further (adding routing information) is a bonus, as is the ability to trigger a sub-chain of rules for evaluation. * The ability to log rejected or dropped traffic specifics. * The ability to log per-rule traffic statistics (packet count is required; packet size total is nice; other statistics may be useful). * The ability to match certain exceptionally useful flags in very common IP protocols (SYN, ACK, FIN, RST, etc, for TCP, as an example). Unless marked as 'nice to have', everything above is a *must* for running even basic firewall configurations on a host expected to face the Internet. If you can do those, and configure them in some semi-sane fashion, then you probably meet the expectations reasonable people would have for "basic firewalling". Or, in summary: * The ability to talk to a modern (CIDR) IP network. * The ability to look at the relevant header information on any protocol required to run as a buildd (includes IP, TCP, and UDP at the very least, quite possibly others I can't name offhand). * The ability to accept, reject, or drop packets based on the above. * The ability to monitor, both statistically and specifically, what the filtering rules are doing. I'm fairly sure there are things I'm forgetting, as well, but if your network stack can do the above, extending it to do anything I've forgotton is unlikely to be problematic for any code with a remotely sane internal architecture (hell, Linux can do it, and I don't consider the network internals to be all that sane...) -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Required firewall support
On Wed, Mar 16, 2005 at 07:50:13PM -0800, Thomas Bushnell BSG wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > * SCC systems have buildds. > > > > * Buildds must be network accessible. > > > > * The first rule of securing a machine exposed to the wilds is "Deny by > > default, allow by need". > > Exactly which firewalling are the existing buildds doing? (I'm asking > for information; if you don't know, then you don't know.) For buildds, since I don't run one as either local or DSA admin, I couldn't tell you offhand. I know what I'd *expect* them to be doing, as general guidelines, which closely resembles what I do on servers I deploy facing the net, but I don't know what they *are* doing. I have no particular reason to believe that they aren't running a sane set of firewalling rules; in fact, I would assume that they are, but I don't feel impolite enough to annoy someone's HIDS log with random checking. I also wouldn't expect details to be posted to the list; while security through obscurity is not *sufficient*, there are times when it is *useful*. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > * SCC systems have buildds. > > * Buildds must be network accessible. > > * The first rule of securing a machine exposed to the wilds is "Deny by > default, allow by need". Exactly which firewalling are the existing buildds doing? (I'm asking for information; if you don't know, then you don't know.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > If you really want this fixed, I suggest finding someone who is well versed > in both network security issues and Internet protocol fundamentals (not > just TCP or even just IP, but all the other lovely beasties out there) and > convincing them it's worth their time (I hear money is often an excellent > motivator). The issues involved with writing a serious, production-capable > network stack are really quite non-trivial (and yes, I *do* speak from > personal experience in this). We have a network stack, thank you very much. The question is: which specific features do you want? "Deny by default" is all you mentioned, and that's already done. Next? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Wed, Mar 16, 2005 at 03:13:16PM -0800, Thomas Bushnell BSG wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > > On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > > One of the conditions for SCC is "fully functioning Unix, including > > > DNS and firewall support." What specifically is intended by "firewall > > > support"? > > I think that simple ACLs are the bare minimum. > > Ok, can you point me at the specific feature, and why is this feature > important for packaging in SCC? Consider: * SCC systems have buildds. * Buildds must be network accessible. * The first rule of securing a machine exposed to the wilds is "Deny by default, allow by need". Therefore, a box which does not provide basic firewalling capabilities (whether that's achieved by configurable ACLs, mind-reading the human traffic trigger, or pixies inspecting every packet) is thus not suitable for running a buildd on, and thus can never achieve SCC status. Sorry, but being able to cope with a hostile environment *is* a requirement in today's network, and there isn't any real way around that fact. I have no clue where Hurd network filtering stands at the moment, so I can't comment on how far it is from having this feature. I wouldn't be willing to admin any such box that was plugged into a network using a ten foot pole, and I don't see why the DSA folks should be expected to either. If you really want this fixed, I suggest finding someone who is well versed in both network security issues and Internet protocol fundamentals (not just TCP or even just IP, but all the other lovely beasties out there) and convincing them it's worth their time (I hear money is often an excellent motivator). The issues involved with writing a serious, production-capable network stack are really quite non-trivial (and yes, I *do* speak from personal experience in this). -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Required firewall support
Adrian Bunk <[EMAIL PROTECTED]> writes:
> It seems what makes Thomas suspicous is that of all current ports of
> Debian (Linux, *BSD, GNU/Hurd), the only one that might be affected is
> GNU/Hurd - this requirement is therefore either void for all current
> Debian ports or it was meant specifically against GNU/Hurd.
I'm not so much suspicious as simply asking what the requirement means
("firewalling support" could refer to many different features), and
also why it was added.
I'm assuming that the requirements were written for their own sake,
because they represent important things that are relevant to the
particular cases they cover, and not because the authors of the
proposal were trying to achieve some pre-determined list of archs.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, Mar 17, 2005 at 12:24:00AM +0100, Marco d'Itri wrote: > On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > > One of the conditions for SCC is "fully functioning Unix, including > > > > DNS and firewall support." What specifically is intended by "firewall > > > > support"? > > > I think that simple ACLs are the bare minimum. > > Ok, can you point me at the specific feature, and why is this feature > I think that the minimum is per-interface permit/deny ACLs which could > match at least on IP protocol number, TCP/UDP ports and ICMP types. > > > important for packaging in SCC? > Because Debian should not waste resources to support a toy OS (in this > case defined as one not secure enough to stay on the internet for real > work). The statement in the announcement was: - the port must include basic unix functionality, e.g resolving DNS names and firewalling "resolving DNS names" is obviouly required. But why is "firewalling" required? It's the question what a "toy OS" is, and whether a "toy OS" might be supported by Debian. It seems what makes Thomas suspicous is that of all current ports of Debian (Linux, *BSD, GNU/Hurd), the only one that might be affected is GNU/Hurd - this requirement is therefore either void for all current Debian ports or it was meant specifically against GNU/Hurd. Thomas' question is simply whether five of your six DPL candidates have signed that they want to kick GNU/Hurd even out of the proposed SCC archive or not. Steve's announcement only listed actions without giving the rationale for each of them, and it would therefore be required that someone of the 12 people who signed this announcement should clarify this point. > ciao, > Marco cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > One of the conditions for SCC is "fully functioning Unix, including > > > DNS and firewall support." What specifically is intended by "firewall > > > support"? > > I think that simple ACLs are the bare minimum. > Ok, can you point me at the specific feature, and why is this feature I think that the minimum is per-interface permit/deny ACLs which could match at least on IP protocol number, TCP/UDP ports and ICMP types. > important for packaging in SCC? Because Debian should not waste resources to support a toy OS (in this case defined as one not secure enough to stay on the internet for real work). -- ciao, Marco signature.asc Description: Digital signature
Re: Required firewall support
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > One of the conditions for SCC is "fully functioning Unix, including > > DNS and firewall support." What specifically is intended by "firewall > > support"? > I think that simple ACLs are the bare minimum. Ok, can you point me at the specific feature, and why is this feature important for packaging in SCC? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > One of the conditions for SCC is "fully functioning Unix, including > DNS and firewall support." What specifically is intended by "firewall > support"? I think that simple ACLs are the bare minimum. > Those who felt this necessary, can you please describe which specific > features you believe are necessary, and why? Only a toy OS like Windows need an external firewall to protect them. -- ciao, Marco signature.asc Description: Digital signature
Required firewall support
One of the conditions for SCC is "fully functioning Unix, including DNS and firewall support." What specifically is intended by "firewall support"? Those who felt this necessary, can you please describe which specific features you believe are necessary, and why? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
