Hi -
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled. The following services are listening on external network interfaces:
Port State Service 22/tcp open ssh 68/udp open dhcpclient 111/tcp open sunrpc 111/udp open sunrpc 123/udp open ntp 1010/udp open unknown 6000/tcp open X11
ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient (both manually configured during install) are reasonably justified, IMHO, but what is the justification for having rpc.statd, portmap and X11 listening by *default* (especially on a machine that hasn't been configured to use NIS)?
Given the problems that Windows has with network services listening by default, shouldn't we be learning from their mistakes? Yes, the user needs to disable firewalling at install time to expose these services, but I can't help thinking that plenty of naïve users will do so...
Best Regards, Alex.
On Mon, 2003-08-25 at 13:50, rhldevel@assursys.co.uk wrote:
111/tcp open sunrpc 111/udp open sunrpc
both are necessary for NFS mounts to work, since these requests go through portmap.
1010/udp open unknown
check with netstat to see what is running here, have no idea.
6000/tcp open X11
AFAIK this doesn't mean anyone can connect; there's still a lot of X authority stuff to get through (specifically, the X runner needs to authorize outside connections).
I think this setup is pretty safe :) What exactly do you not trust ?
Thomas
Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> en in jouw handen was ik een zieke hond die je smeekte geef je over <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
On Mon, 25 Aug 2003, Thomas Vander Stichele wrote:
On Mon, 2003-08-25 at 13:50, rhldevel@assursys.co.uk wrote:
111/tcp open sunrpc 111/udp open sunrpc
both are necessary for NFS mounts to work, since these requests go through portmap.
Sure, but no NFS mounts were configured on install. Perhaps anaconda should parse /etc/fstab if an upgrade install is being performed to determine whether portmap is likely to be necessary or not.
1010/udp open unknown
check with netstat to see what is running here, have no idea.
rpc.statd. See above.
6000/tcp open X11
AFAIK this doesn't mean anyone can connect; there's still a lot of X authority stuff to get through (specifically, the X runner needs to authorize outside connections).
I'm thinking in terms of DoS and zombies-via-buffer-overflow of the X server (which is running with root privs, too, of course). Any listening service is a potential risk, even if it requires authentication before it can be used in the "normal" way.
I think this setup is pretty safe :) What exactly do you not trust ?
Everyone and everything, but that's a topic for another thread entirely. ;-)
Thomas
Best Regards, Alex.
On Mon, 2003-08-25 at 14:04, Thomas Vander Stichele wrote:
check with netstat to see what is running here, have no idea.
6000/tcp open X11
If you intend to only run X11 apps locally (DISPLAY=:0.0 using local socket transport), you can add "-nolisten tcp" to /etc/X11/xdm/Xservers. This will definitively close the port 6000/tcp.
111/tcp open sunrpc 111/udp open sunrpc
both are necessary for NFS mounts to work, since these requests go through portmap.
Yes, that is true, but they shouldn't be open at all until the user configures them to be open. IIRC, the installer doesn't set up nfs mounts. Personally, I'm of the opinion that nfs in particular should be deliberately hard to setup for newbs.
-Chuck
On Mon, 2003-08-25 at 13:50, rhldevel@assursys.co.uk wrote:
Hi -
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled. The following services are listening on external network interfaces:
Port State Service 22/tcp open ssh 68/udp open dhcpclient 111/tcp open sunrpc 111/udp open sunrpc 123/udp open ntp 1010/udp open unknown 6000/tcp open X11
ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient (both manually configured during install) are reasonably justified, IMHO, but what is the justification for having rpc.statd, portmap and X11 listening by *default* (especially on a machine that hasn't been configured to use NIS)?
rpc.statd and portmap aren't the exclusive domain of NIS. Both are enabled by default and used by NFS as client or server. I think they could be disabled by default instead of being enabled by default.
You can disable both services:
# chkconfig --level 12345 portmap off # chkconfig --level 12345 nfslock off
If you don't want the NFS server:
# chkconfig --level 12345 nfs off
On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote:
On Mon, 2003-08-25 at 13:50, rhldevel@assursys.co.uk wrote:
Hi -
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled. The following services are listening on external network interfaces:
Port State Service 22/tcp open ssh 68/udp open dhcpclient 111/tcp open sunrpc 111/udp open sunrpc 123/udp open ntp 1010/udp open unknown 6000/tcp open X11
ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient (both manually configured during install) are reasonably justified, IMHO, but what is the justification for having rpc.statd, portmap and X11 listening by *default* (especially on a machine that hasn't been configured to use NIS)?
rpc.statd and portmap aren't the exclusive domain of NIS.
Sure, but that was my best guess as to why they might be enabled by default (but which would still be irrelevant to the installation scenario I gave).
Both are enabled by default and used by NFS as client or server. I think they could be disabled by default instead of being enabled by default.
You can disable both services:
# chkconfig --level 12345 portmap off # chkconfig --level 12345 nfslock off
If you don't want the NFS server:
# chkconfig --level 12345 nfs off
*We* know this, but I suspect a large number of users don't and won't. I wouldn't like for RH Linux to become the target of a worm with the impact of Blaster, /even if/ the default RH firewall setup would prevent it, and errata had already been released.
Leaving unnecessary ports open on a default install (firewall or not) is a security and PR disaster waiting to happen, IMHO. There's no reason why a install shouldn't be more tolerant of user stupidity, especially when turning those services on is no more difficult than turning them off. ;-)
Best Regards, Alex.
On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote:
rpc.statd and portmap aren't the exclusive domain of NIS. Both are enabled by default and used by NFS as client or server. I think they could be disabled by default instead of being enabled by default.
sgi_fam is an RPC service and needs portmap and is used, i think, by some of the GUI stuff (eg nautilus). portmap needs to be locally accessible.
i do think portmap and rpc.statd should be firewalled off by default though. redhat-config-nfs or similar could enable portmap access if nfs mounts are configured.
regards,
On Mon, 25 Aug 2003, Paul Jakma wrote:
On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote:
rpc.statd and portmap aren't the exclusive domain of NIS. Both are enabled by default and used by NFS as client or server. I think they could be disabled by default instead of being enabled by default.
sgi_fam is an RPC service and needs portmap and is used, i think, by some of the GUI stuff (eg nautilus). portmap needs to be locally accessible.
i do think portmap and rpc.statd should be firewalled off by default though. redhat-config-nfs or similar could enable portmap access if nfs mounts are configured.
.. and maybe even a default /etc/hosts.allow deny for portmap etc. to be double sure and protect against people turning off the firewall. :-)
Could create a lot of confusion and support reqs though.
On Mon, 25 Aug 2003, Paul Jakma wrote:
On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote:
rpc.statd and portmap aren't the exclusive domain of NIS. Both are enabled by default and used by NFS as client or server. I think they could be disabled by default instead of being enabled by default.
sgi_fam is an RPC service and needs portmap and is used, i think, by some of the GUI stuff (eg nautilus). portmap needs to be locally accessible.
i do think portmap and rpc.statd should be firewalled off by default though.
I'm pretty sure they are. What I object to is having them listen on *non-loopback* interfaces needlessly.
redhat-config-nfs or similar could enable portmap access if nfs mounts are configured.
Quite.
Best Regards, Alex.
Felipe Alfaro Solana wrote:
On Mon, 2003-08-25 at 13:50, rhldevel@assursys.co.uk wrote:
Hi -
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled. The following services are listening on external network interfaces:
Port State Service 22/tcp open ssh 68/udp open dhcpclient 111/tcp open sunrpc 111/udp open sunrpc 123/udp open ntp 1010/udp open unknown 6000/tcp open X11
ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient (both manually configured during install) are reasonably justified, IMHO, but what is the justification for having rpc.statd, portmap and X11 listening by *default* (especially on a machine that hasn't been configured to use NIS)?
rpc.statd and portmap aren't the exclusive domain of NIS. Both are enabled by default and used by NFS as client or server. I think they could be disabled by default instead of being enabled by default.
You can disable both services:
# chkconfig --level 12345 portmap off # chkconfig --level 12345 nfslock off
If you don't want the NFS server:
# chkconfig --level 12345 nfs off
statd (i.e. nfslock) probably does not need to be running if NFS is not configured but tunning off portmapper is a bit extreme... Not only do local process expect portmapper to be there, remote process also expect portmapper to be there ... The point being turning off portmapper could (and probably will) cause unexpect process to fail in unexpect ways making very difficult to debug especially during installation...
Portmapper has been around quite a long time making it pretty bullet proof... So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason...
SteveD.
So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason...
I agree. It makes "client usage" much easier and servers should anyway get protection via firewalls and special security changes.
greetings,
Florian La Roche
On Mon, 25 Aug 2003, Florian La Roche wrote:
So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason...
I agree. It makes "client usage" much easier and
There's always a trade-off between security and ease-of-use. What proportion of the installed base of Linux clients use RPC-based protocols? Not many I'd wager, suggesting that the trade-off can be biased towards security, with little-to-no impact on the majority of users.
servers should anyway get protection via firewalls and special security changes.
"should" and "do" are quite different things. Servers should also have security updates applied in a timely manner, but they frequently tend not to in the real world.
Where security is concerned, it's best not to rely upon single points of failure.
greetings, Florian La Roche
Best Regards, Alex.
On Mon, 25 Aug 2003 rhldevel@assursys.co.uk wrote:
There's always a trade-off between security and ease-of-use. What proportion of the installed base of Linux clients use RPC-based protocols? Not many I'd wager, suggesting that the trade-off can be biased towards security, with little-to-no impact on the majority of users.
Most Linux client systems, in my experience, are NFS clients and therefore need portmap, statd, and lockd out-of-the-box.
later, chris
On Mon, 25 Aug 2003, Chris Ricker wrote:
On Mon, 25 Aug 2003 rhldevel@assursys.co.uk wrote:
There's always a trade-off between security and ease-of-use. What proportion of the installed base of Linux clients use RPC-based protocols? Not many I'd wager, suggesting that the trade-off can be biased towards security, with little-to-no impact on the majority of users.
Most Linux client systems, in my experience, are NFS clients and therefore need portmap, statd, and lockd out-of-the-box.
For libraries, labs, schools and universities, that wouldn't surprise me. Such organisations generally have good-to-excellent security awareness.
But for small-to-medium businesses (who have the least security awareness and infrastructure) and home users (similarly), I'd categorically disagree. If any file/print sharing is happening in these environments, it's usually SMB based. Samba doesn't get enabled by default, so why the exception for portmap and rpc.statd?
later, chris
Best Regards, Alex.
rhldevel@assursys.co.uk wrote:
On Mon, 25 Aug 2003, Chris Ricker wrote:
On Mon, 25 Aug 2003 rhldevel@assursys.co.uk wrote:
There's always a trade-off between security and ease-of-use. What proportion of the installed base of Linux clients use RPC-based protocols? Not many I'd wager, suggesting that the trade-off can be biased towards security, with little-to-no impact on the majority of users.
Most Linux client systems, in my experience, are NFS clients and therefore need portmap, statd, and lockd out-of-the-box.
For libraries, labs, schools and universities, that wouldn't surprise me. Such organisations generally have good-to-excellent security awareness.
But for small-to-medium businesses (who have the least security awareness and infrastructure) and home users (similarly), I'd categorically disagree. If any file/print sharing is happening in these environments, it's usually SMB based. Samba doesn't get enabled by default, so why the exception for portmap and rpc.statd?
later, chris
Best Regards, Alex.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
Apache is quite possibly used in by more users than NFS and it is not enabled by default either. I think that if portmap is really that necessary, and I don't think it is, having it configured to only listen on loopback - akin to the stock sendmail configuration - would be a good step. If the admin wants to enable NFS, they tweak the config or a sysconfig entry and voila, they are on the network. Asking an admin that wants to use NFS to do a couple of chkconfig statements is not much, especially when it reduces the network footprint of the stock install.
On Mon, 2003-08-25 at 11:05, David T Hollis wrote:
that wants to use NFS to do a couple of chkconfig statements is not much, especially when it reduces the network footprint of the stock install.
Incorrect.
A "stock" install has the firewall "enabled" (the high/medium stuff is gone) and no remote hosts can initiate RPC/NFS connections to a "stock" installed machine.
A "stock" machine can act a NFS client with no problem however.
Dax Kelson Guru Labs
So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason...
I agree. It makes "client usage" much easier and servers should anyway get protection via firewalls and special security changes.
And Microsoft issued fixes for the exploited holes a long time ago.
You'd be amazed at how many of my customers don't realize the need for a firewall. Some of them became my customers because they did an "everything" install and put the box right on the net. I agree, that's just an absurd thing to do. The fact remains, they do do it.
-Chuck
Chuck Wolber wrote:
You'd be amazed at how many of my customers don't realize the need for a firewall. Some of them became my customers because they did an "everything" install and put the box right on the net. I agree, that's just an absurd thing to do. The fact remains, they do do it.
So are support to try to build a systems that are idiot proof? I would say not... If someone neglect to lock their front door and is robbed, is that the builders fault because he didn't install automatic locking doors?
Firewalls is the best way to deal with network security.... and there no system configuration that we can do to change that fact...
SteveD.
You'd be amazed at how many of my customers don't realize the need for a firewall. Some of them became my customers because they did an "everything" install and put the box right on the net. I agree, that's just an absurd thing to do. The fact remains, they do do it.
So are support to try to build a systems that are idiot proof? I would say not... If someone neglect to lock their front door and is robbed, is that the builders fault because he didn't install automatic locking doors?
No, it's absurd to say that we should build something idiot proof. My point is that even when the fixes are in, people just don't apply them.
Firewalls is the best way to deal with network security.... and there no system configuration that we can do to change that fact...
I think we're in violent agreement here...
-Chuck
On Mon, Aug 25, 2003 at 12:03:04PM -0700, Chuck Wolber wrote:
Firewalls is the best way to deal with network security.... and there no system configuration that we can do to change that fact...
I think we're in violent agreement here...
However, this is the basic nonsense upon which the others are built on. The best way to deal with network security is not relying on a single thing; but using firewalls, configuration, IDS, policies, ... literarly anything you can, to support it.
Too many people thinking `I'm safe, I have a firewall' have been 0wned...
Firewall is no excuse for running redundant services. Thus the question is not about what firewalls are good for, but how much or how often is portmap (and others) redundant.
Regards,
Yeti
-- Do not use tab characters. Their effect is not predictable.
On Mon, 2003-08-25 at 20:39, Steve Dickson wrote:
So are support to try to build a systems that are idiot proof? I would say not... If someone neglect to lock their front door and is robbed, is that the builders fault because he didn't install automatic locking doors?
Of course no, but we need to build idiot-proof doors. In security I think that "you'd better disable it if you don't know for sure if you're going to use it" is the way to go.
We all should run firewalls, we all should run antivirus, we all shouldn't open attachments from unknown parties... and so on, but *we* doesn't mean the whole world. Thus, we must build idiot-proof systems, with high security enabled by default, if we don't want to become News Headlines (i.e. Another Worm Exploits a Vulnerability in Red Hat Linux Portmap Daemon).
Just my 0,0172 Euros.
On Monday 25 August 2003 14:39, Steve Dickson wrote:
Firewalls is the best way to deal with network security.... and there no system configuration that we can do to change that fact...
Security is not so one-dimensional to fall to a one-dimensional solution.
I would say that people who are interested in this problem should look at offering patches. Looking over the list in /etc/rc.d/rc.sysinit the proper runtime level people who want complete lockdown is RunLevel 2 or configuring 4 to be that.
Depending on a firewall as the only protection is not a solution. There are too many people who probably will turn off RH firewalls because the one in 8 and 9 broke too many NFS etc environments.
Also a complete audit of portmap should be in order because it has had a long history of problems. [That may be a bit hard as it seems to have been written by Wietse Venema, but the readme hasnt been touched since 1996 so bit rot may have occured.]
XFree86 should have stronger protection than just the firewall. Having it only listen locally with the best practices of using SSH to forward connections would seem to be best.
On Mon, 25 Aug 2003, Lamar Owen wrote:
On Monday 25 August 2003 14:39, Steve Dickson wrote:
Firewalls is the best way to deal with network security.... and there no system configuration that we can do to change that fact...
Security is not so one-dimensional to fall to a one-dimensional solution.
On Mon, 2003-08-25 at 21:06, Stephen Smoogen wrote:
Depending on a firewall as the only protection is not a solution. There are too many people who probably will turn off RH firewalls because the one in 8 and 9 broke too many NFS etc environments.
I got fed up with breakage and submitted a patch that was accepted.
The *new* RH firewall that will be in 10 and RHAS3 no longer breaks RPC apps.
Tell Bryan Croft hi for me when you see him tomorrow.
Dax Kelson
On Mon, 25 Aug 2003, Steve Dickson wrote:
Felipe Alfaro Solana wrote:
On Mon, 2003-08-25 at 13:50, rhldevel@assursys.co.uk wrote:
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled. The following services are listening on external network interfaces:
Port State Service 22/tcp open ssh 68/udp open dhcpclient 111/tcp open sunrpc 111/udp open sunrpc 123/udp open ntp 1010/udp open unknown 6000/tcp open X11
ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient (both manually configured during install) are reasonably justified, IMHO, but what is the justification for having rpc.statd, portmap and X11 listening by *default* (especially on a machine that hasn't been configured to use NIS)?
[snip]
statd (i.e. nfslock) probably does not need to be running if NFS is not configured but tunning off portmapper is a bit extreme... Not only do local process expect portmapper to be there,
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
remote process also expect portmapper to be there ...
And I expect there have been similar arguments in Redmond regarding their RPC implementation. In my experience it's not used commonly enough that it deserves to be listening for random connections.
The point being turning off portmapper could (and probably will) cause unexpect process to fail in unexpect ways making very difficult to debug especially during installation...
As a matter of course, I disable portmap and rpc.statd on any machine not expected to perform NFS or NIS and have not noticed any side effects as a result.
Portmapper has been around quite a long time making it pretty bullet proof...
Funny, 'cos in my universe, the portmapper is regarded as one of the most vulnerable pieces of UNIX software, along with rpc.statd, sendmail and BIND.
So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason...
...but there is a reason - making new installs secure by default. For a admin who's already configuring NFS or similar, the extra step of chkconfig'ing portmap and rpc.statd isn't much of a burden.
SteveD.
Best Regards, Alex.
rhldevel@assursys.co.uk (rhldevel@assursys.co.uk) said:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
Set up a firewall, as is the default in the install...
Bill
On Mon, 25 Aug 2003, Bill Nottingham wrote:
rhldevel@assursys.co.uk (rhldevel@assursys.co.uk) said:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
Set up a firewall, as is the default in the install...
Certainly, and allowing easy configuration of Linux's IP filtering functionality at install time was a very responsible move by RH.
But to a lot of naïve users, firewalls are deeply technical things, that they worry will interfere with normal usage. As a result, I believe a number of such users will install with the firewall disabled, or stop it when attempting to get things working - perhaps never to (re-)enable it. Having things like X11, portmapper and rpc.statd listening on an external interface is asking for trouble, IMHO.
Bill
Best Regards, Alex.
Why not configure portmapper to listen on localhost, then have the services (mountd, ypserv, etc.) that need it enable listening on the wire when they start? You'd need a cooperative arrangement whereby the init scripts would shut down external portmapper if they were the last service that needed it on service shutdown.
Of course, you can argue that an admin that is configuring NFS or NIS should understand the security implications and other requirements of these services, but we don't live in a perfect world.
and therefore be able to On Mon, 2003-08-25 at 08:45, rhldevel@assursys.co.uk wrote:
On Mon, 25 Aug 2003, Bill Nottingham wrote:
rhldevel@assursys.co.uk (rhldevel@assursys.co.uk) said:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
Set up a firewall, as is the default in the install...
Certainly, and allowing easy configuration of Linux's IP filtering functionality at install time was a very responsible move by RH.
But to a lot of naïve users, firewalls are deeply technical things, that they worry will interfere with normal usage. As a result, I believe a number of such users will install with the firewall disabled, or stop it when attempting to get things working - perhaps never to (re-)enable it. Having things like X11, portmapper and rpc.statd listening on an external interface is asking for trouble, IMHO.
Bill
Best Regards, Alex.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
Howard Owen (hbo@egbok.com) said:
Why not configure portmapper to listen on localhost, then have the services (mountd, ypserv, etc.) that need it enable listening on the wire when they start? You'd need a cooperative arrangement whereby the init scripts would shut down external portmapper if they were the last service that needed it on service shutdown.
Having 'mount' try and configure services would be exceedingly messy.
Bill
I actually was thinking the init script could do it, though that too would be contrary to standard practice.
On Mon, 2003-08-25 at 09:09, Bill Nottingham wrote:
Howard Owen (hbo@egbok.com) said:
Why not configure portmapper to listen on localhost, then have the services (mountd, ypserv, etc.) that need it enable listening on the wire when they start? You'd need a cooperative arrangement whereby the init scripts would shut down external portmapper if they were the last service that needed it on service shutdown.
Having 'mount' try and configure services would be exceedingly messy.
Bill
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
On Mon, 25 Aug 2003 rhldevel@assursys.co.uk wrote:
But to a lot of naïve users, firewalls are deeply technical things, that they worry will interfere with normal usage. As a result, I believe a number of such users will install with the firewall disabled, or stop it when attempting to get things working - perhaps never to (re-)enable it. Having things like X11, portmapper and rpc.statd listening on an external interface is asking for trouble, IMHO.
Bill
Best Regards, Alex.
I agree with Alex. If nfs is being used, it is because there is a knowledgeable person around to set it up. (Is there a client included by default with MS systems?). Better to have it off and close one more potential hole.
------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com
Jim Wildman (jim@rossberry.com) said:
I agree with Alex. If nfs is being used, it is because there is a knowledgeable person around to set it up. (Is there a client included by default with MS systems?). Better to have it off and close one more potential hole.
Counterargument: If the default firewall that already protects you is changed, it is because there is a knowledgeable person that changed it, right?
You can't have it both ways.
Bill
On Mon, 2003-08-25 at 10:44, Bill Nottingham wrote:
Counterargument: If the default firewall that already protects you is changed, it is because there is a knowledgeable person that changed it, right?
You can't have it both ways.
Except that's not following the KISS principle; turning the services off is.
Wil
Quoting Bill Nottingham notting@redhat.com:
Jim Wildman (jim@rossberry.com) said:
I agree with Alex. If nfs is being used, it is because there is a knowledgeable person around to set it up. (Is there a client included by default with MS systems?). Better to have it off and close one more potential hole.
Counterargument: If the default firewall that already protects you is changed, it is because there is a knowledgeable person that changed it, right?
You can't have it both ways.
The difference is that enabling/disabling firewall is a single click of mouse in the installer in all of the installation modes and IIRC anaconda doesn't nag about dangers of disabling the fw in any way (apart from help text perhaps) -> you don't need much knowledge to disable that, but you do need a little bit of knowledge to turn on services post install.
I'd have to agree with Alex & others: most home users are not going to use/need NFS and where NFS servers exist, there exists knowledgeable persons to set the clients up. My +1 for disabling NFS client services by default.
On Tue, 2003-08-26 at 07:47, Panu Matilainen wrote:
The difference is that enabling/disabling firewall is a single click of mouse in the installer in all of the installation modes and IIRC anaconda doesn't nag about dangers of disabling the fw in any way (apart from help text perhaps) -> you don't need much knowledge to disable that, but you do need a little bit of knowledge to turn on services post install.
I'd have to agree with Alex & others: most home users are not going to use/need NFS and where NFS servers exist, there exists knowledgeable persons to set the clients up. My +1 for disabling NFS client services by default.
I would say that, additionally, running a firewall shouldn't be the only line of defense. Imagine that, by any reason, a non-root user downloads a compromised binary that tries to use an unknown exploit on portmap, for example. By not running portmap, we eliminate one additional piece of trouble.
On Tue, 26 Aug 2003, Panu Matilainen wrote:
I'd have to agree with Alex & others: most home users are not going to use/need NFS and where NFS servers exist, there exists knowledgeable persons to set the clients up. My +1 for disabling NFS client services by default.
I dont think that Taroon is meant for Home Users...
On Tue, 26 Aug 2003, Stephen Smoogen wrote:
On Tue, 26 Aug 2003, Panu Matilainen wrote:
I'd have to agree with Alex & others: most home users are not going to use/need NFS and where NFS servers exist, there exists knowledgeable persons to set the clients up. My +1 for disabling NFS client services by default.
I dont think that Taroon is meant for Home Users...
No, but it gives an insight into what's planned for Red Hat 10 (X?) and the AS/WS 3.0 products.
Best Regards, Alex.
On Tue, 26 Aug 2003 15:16:55 +0100 (BST), you wrote:
I dont think that Taroon is meant for Home Users...
No, but it gives an insight into what's planned for Red Hat 10 (X?) and the AS/WS 3.0 products.
Taroon has nothing do to with Red Hat 10, the severn beta is what will become Red Hat 10.
Taroon is what will be the next release of the Red Hat Enterprise line, and NFS is appropriate for a business oriented product.
On Tue, 26 Aug 2003, Gerald Henriksen wrote:
On Tue, 26 Aug 2003 15:16:55 +0100 (BST), you wrote:
I dont think that Taroon is meant for Home Users...
No, but it gives an insight into what's planned for Red Hat 10 (X?) and the AS/WS 3.0 products.
Taroon has nothing do to with Red Hat 10, the severn beta is what will become Red Hat 10.
Beg pardon. I wasn't paying attention to the beta announcements... ;-)
Taroon is what will be the next release of the Red Hat Enterprise line, and NFS is appropriate for a business oriented product.
...but I bet Severn has the same (or larger) set of services enabled by default. Anyone care to comment?
Best Regards, Alex.
On Tue, 2003-08-26 at 01:47, Panu Matilainen wrote:
The difference is that enabling/disabling firewall is a single click of mouse in the installer in all of the installation modes and IIRC anaconda doesn't nag about dangers of disabling the fw in any way (apart from help text perhaps) -> you don't need much knowledge to disable that, but you do need a little bit of knowledge to turn on services post install.
It's easy enough to add a nag to the installer about turning the firewall off if someone files an RFE (otherwise, I'll forget by the time I have a round 'tuit :)
Jeremy
On Tue, 2003-08-26 at 11:12, Jeremy Katz wrote:
On Tue, 2003-08-26 at 01:47, Panu Matilainen wrote:
The difference is that enabling/disabling firewall is a single click of mouse in the installer in all of the installation modes and IIRC anaconda doesn't nag about dangers of disabling the fw in any way (apart from help text perhaps) -> you don't need much knowledge to disable that, but you do need a little bit of knowledge to turn on services post install.
It's easy enough to add a nag to the installer about turning the firewall off if someone files an RFE (otherwise, I'll forget by the time I have a round 'tuit :)
Done; see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103102
--Jeremy P.
rhldevel@assursys.co.uk wrote:
On Mon, 25 Aug 2003, Bill Nottingham wrote:
But to a lot of naïve users, firewalls are deeply technical things, that they worry will interfere with normal usage. As a result, I believe a number of such users will install with the firewall disabled, or stop it when attempting to get things working - perhaps never to (re-)enable it. Having things like X11, portmapper and rpc.statd listening on an external interface is asking for trouble, IMHO.
For network security firewalls are the answer... not disabling network applications... All we can do is give them the tools... but we can not shooting themselves in the foot...
SteveD.
On Mon, 2003-08-25 at 11:28, Steve Dickson wrote:
For network security firewalls are the answer... not disabling network applications... All we can do is give them the tools... but we can not shooting themselves in the foot...
How is leaving something turned off shooting them in the foot?
Wil
Steve Dickson wrote:
rhldevel@assursys.co.uk wrote:
On Mon, 25 Aug 2003, Bill Nottingham wrote:
But to a lot of naïve users, firewalls are deeply technical things, that they worry will interfere with normal usage. As a result, I believe a number of such users will install with the firewall disabled, or stop it when attempting to get things working - perhaps never to (re-)enable it. Having things like X11, portmapper and rpc.statd listening on an external interface is asking for trouble, IMHO.
For network security firewalls are the answer... not disabling network applications... All we can do is give them the tools... but we can not shooting themselves in the foot...
SteveD.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
Wrong. Security in-depth is the answer.
Good - IP ports are firewalled Better - application is not running Best - application is not even installed
On Mon, 2003-08-25 at 20:41, David T Hollis wrote:
Wrong. Security in-depth is the answer.
Good - IP ports are firewalled Better - application is not running Best - application is not even installed
I agree 500% ... If we can:
1. We shouldn't even install portmap or nfs-utils 2. If we can't do 1, then disable portmap and nfs* 3. If we can't achieve neither 1 nor 2, make them bind to localhost 4. Else, enable firewall by default and get picky if the user tries to disable it.
Hear, hear!
The "soft chewy inside" is dead. Long live defense-in-depth!
On Mon, 2003-08-25 at 11:41, David T Hollis wrote:
Steve Dickson wrote:
rhldevel@assursys.co.uk wrote:
On Mon, 25 Aug 2003, Bill Nottingham wrote:
But to a lot of naïve users, firewalls are deeply technical things, that they worry will interfere with normal usage. As a result, I believe a number of such users will install with the firewall disabled, or stop it when attempting to get things working - perhaps never to (re-)enable it. Having things like X11, portmapper and rpc.statd listening on an external interface is asking for trouble, IMHO.
For network security firewalls are the answer... not disabling network applications... All we can do is give them the tools... but we can not shooting themselves in the foot...
SteveD.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
Wrong. Security in-depth is the answer.
Good - IP ports are firewalled Better - application is not running Best - application is not even installed
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
Bill Nottingham wrote:
rhldevel@assursys.co.uk (rhldevel@assursys.co.uk) said:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
Set up a firewall, as is the default in the install...
Yes.... firewalls the answer.....
SteveD.
rhldevel@assursys.co.uk wrote:
statd (i.e. nfslock) probably does not need to be running if NFS is not configured but tunning off portmapper is a bit extreme... Not only do local process expect portmapper to be there,
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
third party applications of our beloved customers... There are *probably* a few more applications other than NFS and NIS that need to advertise ports.... Remember the RPC subsystem has been around for a very long time which means we really don't what we would be breaking by turning it off... Just because you don't know about something..... does not mean they don't exist....
The point being turning off portmapper could (and probably will) cause unexpect process to fail in unexpect ways making very difficult to debug especially during installation...
As a matter of course, I disable portmap and rpc.statd on any machine not expected to perform NFS or NIS and have not noticed any side effects as a result.
So we can assume that your system is an *exact* clone of every other linux system out there... so what works in your world will work everywhere.... I'm sorry but I just don't by your logic...
Portmapper has been around quite a long time making it pretty bullet proof...
Funny, 'cos in my universe, the portmapper is regarded as one of the most vulnerable pieces of UNIX software, along with rpc.statd, sendmail and BIND.
Educate me... How has it *recently* (i.e within the that 3 years) been exploited? And what damage was caused?
So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason...
...but there is a reason - making new installs secure by default. For a admin who's already configuring NFS or similar, the extra step of chkconfig'ing portmap and rpc.statd isn't much of a burden.
Again.... NFS and NIS are not the only user of portmapper... We have to keep in mind the entire industry... not just or own little worlds....
SteveD.
Steve Dickson wrote:
rhldevel@assursys.co.uk wrote:
statd (i.e. nfslock) probably does not need to be running if NFS is not configured but tunning off portmapper is a bit extreme... Not only do local process expect portmapper to be there,
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
third party applications of our beloved customers... There are *probably* a few more applications other than NFS and NIS that need to advertise ports.... Remember the RPC subsystem has been around for a very long time which means we really don't what we would be breaking by turning it off... Just because you don't know about something..... does not mean they don't exist....
Your missing the point here. No one is saying don't ship portmap or nfs utilities. Just raising the question as to whether they should be enabled by default.
The point being turning off portmapper could (and probably will) cause unexpect process to fail in unexpect ways making very difficult to debug especially during installation...
As a matter of course, I disable portmap and rpc.statd on any machine not expected to perform NFS or NIS and have not noticed any side effects as a result.
So we can assume that your system is an *exact* clone of every other linux system out there... so what works in your world will work everywhere.... I'm sorry but I just don't by your logic...
I also disable them on my systems since I don't typically utilize NFS (nor NIS, or any other RPC based service) and I have not had any problems either. Using the recent MS DCOM problems, MS' technical information for the problem suggested a workaround of disabling DCOM with the following nebulous disclaimer:
*Warning* If you disable DCOM, may you may lose operating system functionality. After you disable support for DCOM, the following may result:
* Any COM objects that can be activated remotely may not function correctly. * The local COM+ snap-in will not be able to connect to remote servers to enumerate their COM+ catalog. * Certificate auto-enrollment may not function correctly. * Windows Management Instrumentation (WMI) queries against remote servers may not function correctly.
(http://support.microsoft.com/default.aspx?scid=kb;en-us;825750)
It translates to most folks as "If I disable DCOM, no one knows what is going to break". With a stock RH install, how many RPC using services are available? NFS, NIS, sgi_fam, and?? Unlike MS, you know what will not function if portmap is not running. 3rd party apps are certainly a different ballgame, but that is the 3rd parties responsibility to mention the requirement of portmap.
Portmapper has been around quite a long time making it pretty bullet proof...
Funny, 'cos in my universe, the portmapper is regarded as one of the most vulnerable pieces of UNIX software, along with rpc.statd, sendmail and BIND.
Educate me... How has it *recently* (i.e within the that 3 years) been exploited? And what damage was caused?
So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason...
...but there is a reason - making new installs secure by default. For a admin who's already configuring NFS or similar, the extra step of chkconfig'ing portmap and rpc.statd isn't much of a burden.
Again.... NFS and NIS are not the only user of portmapper... We have to keep in mind the entire industry... not just or own little worlds....
SteveD.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
David T Hollis wrote:
third party applications of our beloved customers... There are *probably* a few more applications other than NFS and NIS that need to advertise ports.... Remember the RPC subsystem has been around for a very long time which means we really don't what we would be breaking by turning it off... Just because you don't know about something..... does not mean they don't exist....
Your missing the point here. No one is saying don't ship portmap or nfs utilities. Just raising the question as to whether they should be enabled by default.
I'm not sure how you interpreted that I want to stop ship nfs or portmapper..... but let me assure that is *NOT* the case... I just don't want to turn of a long standing subsystem that third parties my or may not depend for simply no good reason....
Steved
On Mon, 2003-08-25 at 20:18, Steve Dickson wrote:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
third party applications of our beloved customers... There are *probably* a few more applications other than NFS and NIS that need to advertise ports.... Remember the RPC subsystem has been around for a very long time which means we really don't what we would be breaking by turning it off... Just because you don't know about something..... does not mean they don't exist....
In my humble opinion, sometimes we must take decisions that make difficult mantaining compatibility. However, if these decisions are targeted to achieve improved security, I think we have a reason in our favor. NFS is not very secure by nature (except NFSv4).
If we want to mantain compatiblity with third-party products, I suggest that during upgrades, the portmap and company be left at their original settings. However, for new installations, I think we should disable them, or at least, force them to bind to the loopback interface exclusively. Then, I would put a *big* note into the Release Notes stating behavior changes in those services.
Red Hat (or anyone) can't be liable for a behavior change that is well documented in the Release Notes and aims at security: if an administrator performs a fresh install of Red Hat Linux, then installs third-party products and checks that some things don't work, then, if he/she hasn't read the Release Notes, he/she should be sent to the IT hell ;-)
Just my two cents of Euro.
I agree with this.
While it wouldn't help with third party apps, the init scripts for nfs and ypserv could (briefly) explain the changed behavior wrt the portmapper. In this way the admin could be pointed to documentation that would explain how to turn on the service, together with why you really shouldn't. 8)
As Linux gets more and more market penetration, particularly on the desktop, we will start to suffer from many of the syndromes that Microsoft is so poor at coping with. I'm confident we will do better when dealing with increased visibility and less clueful users and admins. That's because of an inherently better platform, and because people will have thought longer, better and with more experience backing them about the challenges widespread success will raise.
On Mon, 2003-08-25 at 12:36, Felipe Alfaro Solana wrote:
On Mon, 2003-08-25 at 20:18, Steve Dickson wrote:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
third party applications of our beloved customers... There are *probably* a few more applications other than NFS and NIS that need to advertise ports.... Remember the RPC subsystem has been around for a very long time which means we really don't what we would be breaking by turning it off... Just because you don't know about something..... does not mean they don't exist....
In my humble opinion, sometimes we must take decisions that make difficult mantaining compatibility. However, if these decisions are targeted to achieve improved security, I think we have a reason in our favor. NFS is not very secure by nature (except NFSv4).
If we want to mantain compatiblity with third-party products, I suggest that during upgrades, the portmap and company be left at their original settings. However, for new installations, I think we should disable them, or at least, force them to bind to the loopback interface exclusively. Then, I would put a *big* note into the Release Notes stating behavior changes in those services.
Red Hat (or anyone) can't be liable for a behavior change that is well documented in the Release Notes and aims at security: if an administrator performs a fresh install of Red Hat Linux, then installs third-party products and checks that some things don't work, then, if he/she hasn't read the Release Notes, he/she should be sent to the IT hell ;-)
Just my two cents of Euro.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote:
favor. NFS is not very secure by nature (except NFSv4).
hmm... just to but in, but the above is a common myth:
- whatever security problems NFS has, they are /not/ the fault of the NFS
- connection authorisation/transport security are /not/ within the remit of NFS, it is the /RPC/ layer which is responsible.
- NFSv4 is /not/ more secure than NFSv3. However, NFSv4 makes secure RPC mechanisms mandatory. NB: NFSv3 will (should) be able to avail of this too.
anyway, blame RPC and the lack of secure RPC mechs in glibc/linux - not NFS, if authunix is the only mech available, then authunix is all NFS can make use of.
regards,
On Mon, 2003-08-25 at 09:27, rhldevel@assursys.co.uk wrote:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
Incorrect.
You are forgetting what you yourself stated in the message that started this whole thread.
You said, "I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled."
We/you are NOT talking about a _default_ install.
The whole premise for this entire discussion is flawed.
Dax Kelson
On Tue, 26 Aug 2003, Dax Kelson wrote:
On Mon, 2003-08-25 at 09:27, rhldevel@assursys.co.uk wrote:
Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install?
Incorrect.
You are forgetting what you yourself stated in the message that started this whole thread.
You said, "I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled."
We/you are NOT talking about a _default_ install.
The whole premise for this entire discussion is flawed.
Read one of my later posts where I explain that I believe that a number of inexperienced users will disable the firewall either fearing it will cause unknown breakage, or leave it as "something to configure once I've got the machine working".
Regardless, through experience, I'm a firm believer in defense-in-depth, and nothing will change that belief.
I think I've said all I can on the topic now. Red Hat can choose to do whatever they wish, and I'll continue to disable unnecessary services regardless of whether they're firewalled. But if they continue to ship OSs with unnecessary services running, they may end up regretting this discussion... (not a threat, just a prediction - my hat is white!)
Dax Kelson
Best Regards, Alex.
Portmapper has been around quite a long time making it pretty bullet proof...
Longevity has nothing to do with how secure an app is. Any evidence to the contrary is anecdotal ;)
-Chuck
On Mon, 25 Aug 2003, Steve Dickson wrote:
Portmapper has been around quite a long time making it pretty bullet proof... So I see no reason what so ever to turn off portmapper.
General paranoia sounds like a legitimate enough reason to me.
Lets not make a system more difficult to deal with for simply no reason...
Meaning we should start the portmapper as soon as we start some service that needs it and not start the portmapper if it's not needed.
If we can determine and configure this automagically, I don't see how we'd be making life harder for anyone.
Rik van Riel wrote:
On Mon, 25 Aug 2003, Steve Dickson wrote:
Portmapper has been around quite a long time making it pretty bullet proof... So I see no reason what so ever to turn off portmapper.
General paranoia sounds like a legitimate enough reason to me.
Lets not make a system more difficult to deal with for simply no reason...
Meaning we should start the portmapper as soon as we start some service that needs it and not start the portmapper if it's not needed.
If we can determine and configure this automagically, I don't see how we'd be making life harder for anyone.
Begins to suggest that program that I can't remember the name of for the life of me. It actually in Rawhide briefly before 9 came out. It used an XML format to define services and what they depended on. With that app, you would add portmap as a dependency for nfs or xinetd (for sgi_fam) or any other apps and it would ensure that portmap was started before them.
Now I certainly realize that going towards something like that is a massive change to the boot process and is not something that would happen anytime soon, but it is an interesting idea.
On Mon, 2003-08-25 at 05:50, rhldevel@assursys.co.uk wrote:
Hi -
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled
Realize at this point you are NO longer talking about securing a "stock" install.
You are now running a "custom" install, the responsibility now rests on your shoulders. If you remove the installed-by-default air filter from your automobile, that is your prerogative. Deal with the consequences.
The stock RH install is secure by default. The firewall created at installation time prohibits ALL inbound connection requests except for ICMP echo requests (ping).
The firewall created at install time allows ALL outbound connection requests initiated by the host to work with no problems (this was not the case in previous RHL versions).
There is an extremely simple UI for the user to manually ENABLE selected inbound connection requests while leaving the rest of the firewall intact.
I strongly disagree with claim that very few small and medium business Linux environments use NFS and instead use Samba.
Leave my daemons required for client-side NFS running by default please.
I'm all for security in-depth, however, a tunnel vision approach to this results in the end game of setting your default runlevel to 0.
Dax Kelson Guru Labs
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled
Realize at this point you are NO longer talking about securing a "stock" install.
That's simply not the case. It's an option during the install, hence it's a stock install. Going beyond a stock install should mean bolting stuff on after the new machine has come up and is ready for general use.
You are now running a "custom" install, the responsibility now rests on your shoulders. If you remove the installed-by-default air filter from your automobile, that is your prerogative. Deal with the consequences.
Removing the installed-by-default air filter is something that happens after the car arrives in your driveway. What happened above, happened while the "car" was still in the factory. Sure, the customer asked for some "special options". In that case, the factory shouldn't break the "car" just because you asked for options. To use your terminology...
The stock RH install is secure by default. The firewall created at installation time prohibits ALL inbound connection requests except for ICMP echo requests (ping).
Which stock install is that? The desktop? The server? Perhaps you mean the laptop? Or were you talking about the upgrade install?
I strongly disagree with claim that very few small and medium business Linux environments use NFS and instead use Samba.
Agreed. Samba uses SMB locking semantics and NFS uses POSIX locking semantics. Don't call a plumber to do your brain surgery...
-Chuck
On Tue, Aug 26, 2003 at 12:17:30PM -0700, Chuck Wolber wrote:
I strongly disagree with claim that very few small and medium business Linux environments use NFS and instead use Samba.
Agreed. Samba uses SMB locking semantics and NFS uses POSIX locking semantics. Don't call a plumber to do your brain surgery...
We can care about POSIX locking sematics. But do you really think the small businesses care about it too?
They often had a mixed environment for some time (or still have it) so Samba was necessary, and once Samba works, they will hardly replace it with NFS.
Yeti
-- Do not use tab characters. Their effect is not predictable.
Agreed. Samba uses SMB locking semantics and NFS uses POSIX locking semantics. Don't call a plumber to do your brain surgery...
We can care about POSIX locking sematics. But do you really think the small businesses care about it too?
Nope, not one single bit. They wouldn't know POSIX if it jumped out of the toilet while they were sitting on it.
From personal experience, what they do know is that NFS is for UNIX<->UNIX
file sharing and SAMBA is for *<->WINDOWS file sharing (and printing). Inevitably the question comes up, "why can't we use just one or the other". I've posed this question directly to Jeremy Allison and he echoed the usual response that the behaviour is not predictable due to said locking semantics.
In the end, the brain surgery and plumber analogy usually gets the point across.
They often had a mixed environment for some time (or still have it) so Samba was necessary, and once Samba works, they will hardly replace it with NFS.
No reason to replace SAMBA with NFS. They work fine together. Just be aware that using 100% one or the other will lead to unpredictable results.
-Chuck
Chuck Wolber wrote:
No reason to replace SAMBA with NFS. They work fine together. Just be aware that using 100% one or the other will lead to unpredictable results.
How's that? I've used 100% NFS setups without problems for a long time. Never had "unpredictible results". It's adding samba, more specifically MS Windows into the mix that causes problems.
-Thomas
No reason to replace SAMBA with NFS. They work fine together. Just be aware that using 100% one or the other will lead to unpredictable results.
How's that? I've used 100% NFS setups without problems for a long time. Never had "unpredictible results". It's adding samba, more specifically MS Windows into the mix that causes problems.
I think you missed my point. If you are just using POSIX type systems, use a POSIX type file sharing protocol. If you are using SMB type systems use a SMB type file sharing protocol. If you are using both types of systems, use both sharing protocols...
-Chuck
On Tue, 26 Aug 2003, Chuck Wolber wrote:
I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled
Realize at this point you are NO longer talking about securing a "stock" install.
That's simply not the case. It's an option during the install, hence it's a stock install. Going beyond a stock install should mean bolting stuff on after the new machine has come up and is ready for general use.
And so is a 'custom' install by this logic. I am guessing that Red Hat should really just have a Henry Ford[1] install option with one choice of minimal for installing. Makes Red Hat's job much easier.. you can always customize the distro afterwords.
[1] Paraphrase of Henry Ford: You can have a model T in any color you want, as long as it is black.
I also think minimal ports should be the default. Maybe adding some inteligence to the scripts or redhat-config-services to allow know that if you start NFS you also need to start portmapper. Maybe by adding a requires flag to the NFS init script.
Why do we have a bias towards the machine being a server machine? If we argue that we should start portmapper because alot of Unix machines use it to intercommunicate, the same argument could be used for other protocols like FTP, Telnet, samba ...
A machine should be running minimal services to start and then make it easy for the user to start up services. Interaction between tools like redhat-config-services and the firewall would be nice.
Dan