also sprach Adam Warner <lists@consulting.net.nz> [2002.01.21.2304 +0100]: > > 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? no. he claims that all he wanted was root access to the box for a dDoS (it was on a 2mbps line). i think he was after money, but then turned into an opportunist as he couldn't find any. when will people finally realize that i am poor :) > 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. if your news server is non-root and chrooted as well as bind, and your apache does not use suexec and runs as www-data (and is reasonably new), then you should have little to fear. then we could settle this discussion as i think we can endlessly toss the turns. there is no right and wrong in security, only gut feelings (gosh, i am repeating myself, and it isn't even that good of a quote...) > I also enable ICMP echo-requests because I believe it is a responsible > service to provide. why? > I attempt to keep up to date with security releases. you also run Debian. that's a good start ;) > Yes I am "on track". You could suggest that I chroot (jail) bind 9 and > have a better log analysis policy. you *should*, especially because with a 2.4 kernel, you can do so in 10 commands. > > 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. okay, fine. you win. > > > 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. i never said i am good. nevertheless, read on below. > > > 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."? there is nothing to be said against keeping a hint to the password written down somewhere. for instance, i once had to remember the weekly changing security code of a lab, which was four digits. i am *really* good with numbers, but not if they change every week, and so i simply carried a piece of paper around with me with a matrix. say the number was 4723, my paper would look like this: 2830 6121 2979 0045 and all i had to remember was: third column, upside down. granted, even that could be considered insecure, but you always have to trade off security vs. necessity, as you stated. you can apply the same to root passwords. as long as you don't write on the paper: "root's password to mymachine.mydomain.net [124.45.26.117] (hidden telnet at port 31776)", and possibly encrypt the passsword in a very custom and non-algorithmic way as i did above, you'd be safe. oh, and as long as you don't pull it out in front of the machine and type it off. go to the bathroom or something, and remember it for the 60 seconds it takes you to get back and onto a shell prompt. see, my thing with security is that i am actually well aware of security flaws and considerations, but i don't employ 100% secure means for everything. simply because it's overkill. i don't keep my passwords on a post-it on the screen, i do use SecurID or S/Key whenever possible, but i have had other security people or paranoid admins scream at me. usability and security are mutually exclusive, but you can find a way to combine both with respect to what the environment needs, and i am really good at that actually. and the last time i entered a root password anywhere was like 3 months ago, thanks to properly configured sudo installations. > 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. i enforce strong passwords on all my systems, and i educate my users on my techniques. i am far from a paranoid purist and perfectionist in security terms, because i don't see that as plausible. it's sort of the university theoretician versus the realistic human being. > What you provided is a solution to overcoming the problem. Not a comment > on which scenario was more secure. i didn't address it. i think that the most secure twist of your scenarios would be a combination of strong password (security by obscurity), a one-time password, and biometrics, but try making your users do that. however, i do believe that in your scenarios, the preferred way would be to have the user password be the strong one, to have an incredibly strong root password, and a perfectly configured sudo. and the root password kept away in a safe. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck (a)bort, (r)etry, (p)retend this never happened
Attachment:
pgp3TdnvYl0Dc.pgp
Description: PGP signature