Re: PermitRootLogin enabled by default
John Galt [EMAIL PROTECTED] writes: that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was using standard security practice at that point, it's just for convenience's sake, the user had a few things screened, including a rootshell, probably because of the traditional Conventional Wisdom of not permitting any remote logins of root. I find this kind of ironic in another sense, as Dug Song is the author of a Man in the Middle tool that works against older SSHes Depends.. if you manage to intercept the user's password, you can type it into sudo just like they do and get the same level of root privelege. In that case, not leaving screen running would have still been as bad. No doubt this is why tightening sudo down is a good idea. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: PermitRootLogin enabled by default
Is there any landscape in which you may want to allow direct root login to your host? I allow it to my firewall, since there isnt any other account on there. but then again, that system only listens to my internal interfaces.. So, not typical maybe? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis G?mez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? rsync where you want to keep userid/groupid info. -- GOVERNMENT ANNOUNCEMENT - The government announced today that it is changing its mascot to a condom because it more clearly reflects the government's political stance. A condom stands up to inflation, halts production, destroys the next generation, protects a bunch of pricks and finally, gives you a sense of security while you're being screwed! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
I tend to set it to without-password to allow a remote root entry only via RSA/DSA keys, also making sure to restrict it further with as many applicable options for AuthorizedKeysFile ( man sshd ) This is done as a restricated remote root backdoor as well as automated network backups via dump restore. Leaving it set to yes is just an invitation for people to brute force the root password. -- Steve On 26 Jun 2002, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Regards, Luis -- Luis Gómez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] [-] Steve Mickeler [ [EMAIL PROTECTED] ] [|] Todays root password is brought to you by /dev/random [+] 1024D/ACB58D4F = 0227 164B D680 9E13 9168 AE28 843F 57D7 ACB5 8D4F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias - Luis Gómez wrote: Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? disallowing direct root logins via ssh provides for auditing. you will always know which user became root. this is why i keep PermitRootLogin turned off. regards, uLI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 04:05:58PM +0200, Christoph Ulrich Scholler wrote: On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias - Luis Gómez wrote: Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? disallowing direct root logins via ssh provides for auditing. you will always know which user became root. this is why i keep PermitRootLogin turned off. Right, unless you actually want to use keys, which is the whole point. Just up the logging level and it will say which keys are logging in, and then you'll never have to transmit your root password to the server. Using su root later is worse than just logging in as root with a key. Simon- [Simon Kirby][Network Operations] [ [EMAIL PROTECTED] ][ NetNation Communications ] [ Opinions expressed are not necessarily those of my employer. ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- Christian Egli wyona: research development http://www.wyona.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 04:05:58PM +0200, Christoph Ulrich Scholler wrote: On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias - Luis Gómez wrote: Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? disallowing direct root logins via ssh provides for auditing. you will always know which user became root. this is why i keep PermitRootLogin turned off. Right, unless you actually want to use keys, which is the whole point. Just up the logging level and it will say which keys are logging in, and then you'll never have to transmit your root password to the server. Using su root later is worse than just logging in as root with a key. I don't know if I agree with that but if even if I grant you that for the sake of the argument, the sudo package is your friend. -- +-+-+ | [EMAIL PROTECTED] | Thou art the ruins of the noblest man | | Derek J. Balling | That ever lived in the tide of times. | | | Woe to the hand that shed this costly | | | blood - Julius Caesar Act 3, Scene 1 | +-+-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 05:08:32PM +0200, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? Sure. In all cases, you always depend on the security of the client, whether it be protecting a key on the filesystem or protecting the keystrokes from being logged. If the client is compromised, anything can happen, regardless of if the client has to enter one password, two passwords, a key with one passphrase, or a key with ssh-agent. So, let us look at the server. If the server is compromised, often a password sniffer and/or trojaned SSH or su daemon will be installed. With passwords, as soon as the next administrator logs in and enters the password, via su or via ssh, the password will be decrypted to cleartext by the server for verification and thus logged. If this password happens to be used on any other server, the attacker will have access to those servers (you could have a different password for every server, but often this does not happen in practice). With keys, nothing special happens. The server can either allow or refuse the connection, and logging will accomplish nothing other than being able to determine the public key (which would already have to be on the server anyway). The attacker cannot obtain any password or private key information. This combined with the fact that logging in as root (preferrably with a key) makes things like scp and other non-interactive programs possible over SSH. I don't see any reason _not_ to log in directly as root. Logging is the only potential issue, but that can be fixed by altering the log level in sshd_config. (Remember we're talking about root access here. Anybody with root access can alter logs and/or transmit decoy logging entries to remote logging servers, etc., so logs for root logins aren't really that useful except for the Alright, who broke it? case.) Simon- [Simon Kirby][Network Operations] [ [EMAIL PROTECTED] ][ NetNation Communications ] [ Opinions expressed are not necessarily those of my employer. ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Yes, there is. For example I have some servers that retrieve their user information from a database. If the database is not reachable, an ordinary user can't login, but root can, since it's the only local account with login privileges. But then this is a special case that doesn't require root logins enabled by default. On the other hand I don't see why allowing direct root logins is a problem. - Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
El mié, 26-06-2002 a las 16:39, Sebastian Rittau escribió: Yes, there is. For example I have some servers that retrieve their user information from a database. If the database is not reachable, an ordinary user can't login, but root can, since it's the only local account with login privileges. Thanks to all of you for your replies. As I expected, there exist situations in which this is necessary, it's only I couldn't imagine those situations... So, again, thanks to all! -- Luis Gómez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Sebastian Rittau [EMAIL PROTECTED] writes: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Yes, there is. For example I have some servers that retrieve their user information from a database. If the database is not reachable, an ordinary user can't login, but root can, since it's the only local account with login privileges. Yes, this is an idea, along with simple backups (over scp/rsync, without sudo server-side). Doesn't sashroot also constitute uid-0 login and fall subject to the above? But then this is a special case that doesn't require root logins enabled by default. On the other hand I don't see why allowing direct root logins is a problem. Having `PermitRootLogin yes' gives someone a known username to brute-force. Fortunately, sshd_config(5) to the rescue, here: | PermitRootLogin | Specifies whether root can login using ssh(1). The argument | must be ``yes'', ``without-password'', | ``forced-commands-only'' or ``no''. The default is ``yes''. For potentially-interactive purposes (rescuing a remote server), I'd go with without-password; if you know that root coming in via this access means is only going to want to run one command (eg for backup purposes when you have console access a matter of metres away) then you can afford the extra security of a forced-commands-only approach[0]. [0] Note FWIW that this is not you asked for the wrong command, so I'll do nothing; it's no matter what you asked, I'm going to do Foo as specified in the cmd= restriction... ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
I think there may be a compromise solution here... In short: it is good to make people log in as a normal user before trying to log in as root, because that way an attacker needs to compromise a normal user before starting on root. The standard way of doing this is to use su, but that only accepts passwords, not (more secure) keypairs. On our system, we run two ssh processes - one on the external interface which does not accept root logins, and one on the internal interface which does (keypairs only). A remote user wanting to log in as root must first log in as a normal user, forwarding a connection to the local SSH port, then log in using the key stored on their own machine. As far as I can tell, this is the best of both worlds (although it does take some setting up!) - Andrew Sayers pgp67FjB1k1aX.pgp Description: PGP signature
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? Not sure if you've seen this, but the maintainer offers an explanation in /usr/share/doc/ssh/README.Debian.gz Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
That's how monkey.org got taken over--they SCREENed a su, and the attacker reattached it after getting as user via EPIC... On 26 Jun 2002, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- FINE, I take it back: UNfuck you! Who is John Galt? [EMAIL PROTECTED], that's who! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Not IMO. I thank my lucky stars every day that it was decided to allow root logins by default. I have 194 Debian boxes to look after. I have ssh identity keys setup. I can't go login to every box individually and run sudo or su every time I want to change something. I need to automate it, and I need to touch them all at once. If it did default to off then I would have to carefully change that every single time I upgrade ssh packages, or roll my own ssh packages. Allowing root logins is such a huge convenience when you have many machines that its really a must. And when you only have a few machines its easy enough to go to each one and disable it. -- -tcole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
hi all if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... c ya alvin On Wed, 26 Jun 2002, John Galt wrote: That's how monkey.org got taken over--they SCREENed a su, and the attacker reattached it after getting as user via EPIC... On 26 Jun 2002, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
hi ya in order to update 10, 100 boxes ... with new setof changes.. you do NOT need to login into any of um ... many different ways to update each target box based on some master distribution server -- you do want to test the updates in a test farm before it goes out to production and protect that master server from foul play ( lots of sanity checking ) -- rsync, apt-get, custom-update.pl, lots of ways to update 10 or 100 or 1,000 servers once master distribution server is updated - am assuming that automated updates via cron is acceptable ( i use a custom update script of only files i allow to be changed ( based on a master server -- cant see wanting to logging into 100 or 1000 machines manually.. which means either the passwd is written down... or that there's an algorithm to its passwd ... ( i think using keys is bad... imho... if one machine is hacked... ( than they can log into all the rest of um with no effort... - guess its whatever one feels comfy with... fun stuff... :-) c ya alvin On Wed, 26 Jun 2002, Travis Cole wrote: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Not IMO. I thank my lucky stars every day that it was decided to allow root logins by default. I have 194 Debian boxes to look after. I have ssh identity keys setup. I can't go login to every box individually and run sudo or su every time I want to change something. I need to automate it, and I need to touch them all at once. If it did default to off then I would have to carefully change that every single time I upgrade ssh packages, or roll my own ssh packages. Allowing root logins is such a huge convenience when you have many machines that its really a must. And when you only have a few machines its easy enough to go to each one and disable it. -- -tcole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: PermitRootLogin enabled by default
Alvin, If the cracker can get in as a user, it's merely a matter of time before they can worm their way into becoming root. Defenses against this are difficult, the NSA version SELinux deliberately places great restrictions on user abilities to try to prevent just such things. But I don't think there is any certain way to prevent a user from gaining root access if they are capable and determined. Layered defenses are best, of course. Network firewall (or packet filtering), restricted service offering (no fingerd, no telnetd, etc), then strong authentication for login, then restricted access to root. Like you, I do not prefer to allow direct root logins so that an attacker must overcome each barrier in turn. One of my favorite features of Debian is being able to go through the packages at install time and un-select such things as fingerd and telnetd, so that the services never exist on the server. Curt- From: Alvin Oga [mailto:[EMAIL PROTECTED] hi all if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, 26 Jun 2002, Alvin Oga wrote: hi all if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was using standard security practice at that point, it's just for convenience's sake, the user had a few things screened, including a rootshell, probably because of the traditional Conventional Wisdom of not permitting any remote logins of root. I find this kind of ironic in another sense, as Dug Song is the author of a Man in the Middle tool that works against older SSHes if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... This wisdom is where things start to fall flat. The only successful security approach is layered--don't run unnecessary services, patch things immediately, use strong authentication wherever possible, and maintain strict separation of privileges via ACLs, capabilities, or other methods. other layers can include external things like IPSEC, switched networks, firewalls, and such. The most obvious rule here is don't rely on any one layer. Your above statement really relies on the patch vulnerabilities layer, which means you violated the obvious rule. c ya alvin On Wed, 26 Jun 2002, John Galt wrote: That's how monkey.org got taken over--they SCREENed a su, and the attacker reattached it after getting as user via EPIC... On 26 Jun 2002, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- FINE, I take it back: UNfuck you! Who is John Galt? [EMAIL PROTECTED], that's who! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Travis Cole [EMAIL PROTECTED] writes: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? I thank my lucky stars every day that it was decided to allow root logins by default. If it did default to off then I would have to carefully change that every single time I upgrade ssh packages, or roll my own ssh packages. Huh? If an upgrade clobbers your configuration without asking you for permission that is a bug. File a bug report. Quoting from debian-policy 11.7.3 Behavior Configuration file handling must conform to the following behavior: * local changes must be preserved during a package upgrade, and * configuration files must be preserved when the package is re- moved, and only deleted when the package is purged. -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default - yuppers
hi ya john On Wed, 26 Jun 2002, John Galt wrote: On Wed, 26 Jun 2002, Alvin Oga wrote: if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was using standard security practice at that point, it's just for convenience's sake, the user had a few things screened, including a rootshell, probably because of the traditional Conventional Wisdom of not permitting any remote logins of root. I find this kind of ironic in another sense, as Dug Song is the author of a Man in the Middle tool that works against older SSHes think some folks are better targets ( or rather a more visible target ) than relatively anonymous machines at home on at dsl or att cable ??? if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... humm .. bad choice of words ... lots of places to fix vulnerabilities not just patching apps... This wisdom is where things start to fall flat. The only successful security approach is layered--don't run unnecessary services, patch things immediately, use strong authentication wherever possible, and maintain strict separation of privileges via ACLs, capabilities, or other methods. yupp.. more the merrier ... wish i can play more with different stuff for experimenting and watching what happens other layers can include external things like IPSEC, switched networks, firewalls, and such. The most obvious rule here is don't rely on any one layer. Your above statement really relies on the patch vulnerabilities layer, which means you violated the obvious rule. wasnt meant to violate the obvious rule...but yes... more things and more layers... mroe bends.. more curves.. more traps the merrier .. which requires more time too and more $$ too ... i like to split all that up into...per their budget... - 5 minute security precautions.. - 5 hr security precautions.. good enuff for most ... - 5 days security precautions.. better for most ... - 5 weeks ... hummm...type slow and explain a lot to them ?? - but no matter which ...its always ongoing... job security !! until you lose one big battle with one good [cr/h]acker... have fun alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
