Contributed by jose on from the back-from-the-dead dept.
(Comments are closed)
OpenBSD Journal
Contributed by jose on from the back-from-the-dead dept.
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By jc () on
To override, add your own command to /etc/rc.local (preferred), or just vi /etc/rc and pull out the lines that touch the motd file.
Instead of not allowing root to login to SSH, I prefer to leave it enabled, but firewall off who can access port 22. If I leave it up to trusted hosts/networks only.
IMO disallowing root to log in over SSH doese not really improve security. If someone knows the root password, they are going to get in one way or another.
Another tip,
Add /usr/bin/false to /etc/shells. Set that as the shell for any users who dont need a command prompt (vipw). They will still be able to FTP, etc, etc.
Giving users shell access isnt necessarily a security issue, but is far from a good idea unless its explicitly necessary.
Another,
If you have the self-discipline, always execute binaries using the full path. i.e.
# /usr/sbin/httpd
instead of
# httpd
This is a good idea in case someone was able to slip a trojan/other into a directory ahead of the actual binary dir in $PATH.
Comments
By Anonymous Coward () on
By schubert () on
And you don't need to execute binaries with the full path provided you properly set your PATH and don't do stupid things like add "." to the end of it.
Comments
By arf () on
There's a BIG difference
Comments
By schubert () on
By zil0g () on
man afterboot
By Dom De Vitto () dom@devitto.com on mailto:dom@devitto.com
1)
Preventing root from logging in over SSH assumes that the root password can be guessed.
If you are worried about this then you should not allow password logins, only publickey ones.
2)
Though immutable files are great, user ones I've always thought pointless.
Doing chflags -R schg /bin is a great idea, but he doesn't mention it!
So what files would a normal user have, that makes immutability any better than "chmod og=" ? None. (logs would be good choice, but then you'd have to reboot to switch or prune them)
3)
/etc/motd ? What is this guy on? Remind me of a unix released in the last 10 years where "uname -a" doesn't tell you exactly whats running??? So he's hoping that a hacker doesn't know about "uname", right ??! The *ONLY* reason for pulling the OS out of the motd would be to case it came up in a telnet snoop, and well, that would be the least of his problems.
4)
Use good passwords? Wow, breaking news. Even better use good passwords and don't allow people to use them - see point #1 above.
5)
MD5 checksums eh? Thanks for that! But did you make the scripts, the output files, perl, the perl libraries, the system libraries etc. system immutable? No? Great, I'll just change fopen so you never spot that sshd and libc.so have been changed.
I presonally prefer to use a modified version of md5sum that supports -r (maybe I'll commit the change one day). It's statically linked too.
Really tho' this is just a cheap and dirty way of making files crypto signed.
Comments
By W () on
You make me sad.
By zil0g () on
"logs would be good choice, but then you'd have to reboot to switch or prune them"
how about setting up newsyslog to keep 'em for say a month, and THEN once a month at 3AM you have a sk!pt that kills init (heh) and somehow stays alive and actually turns the logs over, and brings the system back up?
hmmm... I might be smokin' crack again...
but in theory you'd get to keep that valuable uptime(1) with a minimum of actual downtime.
Comments
By james () on
By Anonymous Coward () on
no. preventing root login also assures admins follow best practices - that they dont login as root but instead use either su or sudo, and thus a log will be kept of that priv escalation.
as far as motd's go, i prefer a usage note (while here actions monitored, etc) plus warning (authorized use only) - sure like the "no trespass" sign it doesnt prevent but it does add in court. plus, not everyone knows about uname, as he mentions, anyone with experience will get around this.
Use good passwords? Wow, breaking news.
i know plenty of people who still use "john1234" as their password.
All in all, i am unsurprised that people with experience find this "Simple Things" article too simple.
By me () a@b.com on mailto:a@b.com
Here's one that frustrates me:
That's a RH 7.1 system. The only way I could readily confirm the distro was by asking the owner.
Comments
By zil0g () on
like uhm... /etc/redhat-release; /etc/sysconfig/rhn/*; gcc -v
etc etc...
By Anonymous Coward () on
cat /etc/redhat-release
By Ben Goren () ben@trumpetpower.com on http://www.trumpetpower.com/
Like others, I'm less than wowed by this installment. What especially caught my attention is that he re-invented mtree (8) but didn't get it quite right....
Cheers,
b&
Comments
By Jeffrey () on
# mtree -c -Ksha1digest -p
Of course, setting the schg flag on mtree is advisable. I always do anyway =) Of course, keeping your initial spec files offsite (on a floppy perhaps) helps. Otherwise, you would also need to do schg on the initial spec files as well.
mtree is the most useful tool on the whole system ;) I like it anyway... Yay!
Cheers to all =)
Comments
By Anonymous Coward () on
i'm guessing it md5's the whole filesystem, but i really have no idea.
Comments
By Jeffrey () on
exists in the hierarchy rooted at '-p ...' (or current directory)
against a specification containing the way this particular hierarchy
is supposed to be (uid, gid, mode, digest, etc...).
You can refer to the www man pages. Heres the URL for mtree(8).
http://www.openbsd.org/cgi-bin/man.cgi?query=mtree&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
By zil0g () on
I learned lots of stuff! like... uhm... hmmm well THINGS! kinda.
and I doubt that guy has been ON an OBSD system for long enough to actually notice the mails... I mean, they only show up once a day.
By Bye Birdie () on
I learn from his articles, and applaude his effort to lead out.
Comments
By Dom De Vitto () dom@devitto.com on mailto:dom@devitto.com
Comments
By Anonymous Coward () on