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.
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
* 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
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
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
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
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
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
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
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,
[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
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
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
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
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
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
* 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
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
[ 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
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
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
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
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
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
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
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,
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
[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
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
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
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
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
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
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;
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
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
36 matches
Mail list logo
