On Tue, 2002-01-22 at 03:11, martin f krafft wrote: > also sprach Adam Warner <[EMAIL PROTECTED]> [2002.01.21.1444 +0100]: > > Martin, it's a server in my spare room :-) The only person installing a > > backdoor on the server would be an unlawful intruder. Or a cat who can > > type ;-) Your points are well taken and I would follow the same security > > practices as you. > > as sad as it sounds, unlawful intruders happen. this being a true story, > i have 11 machines in my spare room, and my house was broken in once. > the *only* thing the intruder did was reboot one of the machines (that > was his mistake) and install a backdoor via init=/bin/sh at the boot > prompt. my logs screamed (i have redundant logging), i found the > backdoor, had a honeypot on, and didn't have to wait 3 hours for the > intruder to try to login. he didn't have to wait 3 hours for the police > to show up.
An amazing story. Did you ever find out why the intruder did that? What data he/she was after? > > Martin, I'm only an individual writing from one of my "servers". And if > > I can save resources by using a server for a workstation as well I think > > that's OK. > > okay. but your "server" has a permanent internet connection, and though > you might not have mission-critical and confidential data, it is a prime > target for hackers because of distributed denial of service attacks. so > it needs to be secured, and you are on track. > > what's your server serving? It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. I also enable ICMP echo-requests because I believe it is a responsible service to provide. I attempt to keep up to date with security releases. Yes I am "on track". You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. > > > i don't have the time to research and present an escalation exploit at > > > this moment, but i do want you to accept one point, which in itself will > > > already flaw your approach of handling login and usage of the > > > workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and > > > it's an accounting thing. there's a reason why the group "wheel" exists > > > on traditional UNIX systems (*why* does Linux *not* have it); noone > > > without a local account should be allowed root, and it's good to know > > > who became root when; to become root, you have to know two passwords > > > *and* an account name. > > > > I do not see that there is any significant security issue in logging in > > as root from a LOCAL console. > > it depends on the environment, how many admins there are, and the > physical security around you. with several tens of admins, it's > important to keep track of every usage of root privileges with names and > outside of those admins' control. In other words it's not relevant to my situation. > > > you have it backwards. usually, you login as user and su to root. > > > logging in as root and su'ing to a user is the wrong way around. i even > > > think it's wrong to allow password-less su and suggest to disable it. > > > > Whenever I use a remote login procedure like SSH I log in as a user and > > then su to root when necessary. > > good. > > > Since you "even think it's wrong to allow password-less su and suggest > > to disable it" you're really going to like trying to refute this > > "heretical" scenario I created: > > why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. > > This indicates to me that the increased risks of using su - to log in as > > a user may be offset by the decreased risks of a superior user password > > that you actually have to write down and consult to remember. > > there's no excuse. enforce strong passwords. period. libpam-cracklib for > a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario "the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember."? You just rewrote the scenario because you didn't like the idea of someone using an easy to use password--even though this is a relatively common scenario. What you provided is a solution to overcoming the problem. Not a comment on which scenario was more secure. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
