OpenBSD Journal

Securing Small Networks with OpenBSD Returns

Contributed by jose on from the back-from-the-dead dept.

Jacek Artymiak's column Secuing Small Networks with OpenBSD makes a return visit to end out October on Onlamp . This latest column is entitled Simple Things to Improve Your System's Security and includes a collection of tidbits and scripts to improve your system's security. Anyone have any others they wish to share?

(Comments are closed)


Comments
  1. By jc () on

    Am I Crazy, or do I recall that /etc/rc overwrites your custom motd on bootup? The article fails to mention this.

    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
    1. By Anonymous Coward () on

      wow haha, sorry for the extra linefeeds. I didnt get any sleep last night, and unfortunetley havent had the luxury of sleep thus far tonite either ;)

    2. By schubert () on

      do NOT add /usr/bin/false to /etc/shells, this is WHAT /sbin/nologin is for.

      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
      1. By arf () on

        No Actually, /sbin/nologin will deny FTP logins (as well as other services) and is meant for daemons. /usr/bin/false is a valid shell, but denys access to a command prompt and just returns 1.

        There's a BIG difference

        Comments
        1. By schubert () on

          man nologin, then man false. try again.

    3. By zil0g () on

      how 'bout leaving the first two lines blank?

      man afterboot

  2. By Dom De Vitto () dom@devitto.com on mailto:dom@devitto.com

    Starting from the top:
    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
    1. By W () on

      Don't be so negative. Not everyone is an 313373 H4X0R like you.

      You make me sad.

    2. By zil0g () on

      rebooting to turn over logs eh?

      "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
      1. By james () on

        He's talking about immutable logs.

    3. By Anonymous Coward () on

      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.

      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.

    4. By me () a@b.com on mailto:a@b.com

      Remind me of a unix released in the last 10 years where "uname -a" doesn't tell you exactly whats running???

      Here's one that frustrates me:

      $ uname -a Linux myname 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown

      That's a RH 7.1 system. The only way I could readily confirm the distro was by asking the owner.

      Comments
      1. By zil0g () on

        or check for some telltales....
        like uhm... /etc/redhat-release; /etc/sysconfig/rhn/*; gcc -v
        etc etc...

      2. By Anonymous Coward () on

        That's a RH 7.1 system. The only way I could readily confirm the distro was by asking the owner.

        cat /etc/redhat-release

  3. 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
    1. By Jeffrey () on

      Yes, mtree(8) and a small sh script is all you need.

      # 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
      1. By Anonymous Coward () on

        Can you explain further? I've never heard of mtree and don't have a unix box handy to go check out the manpages and play around with it.

        i'm guessing it md5's the whole filesystem, but i really have no idea.

        Comments
        1. By Jeffrey () on

          In short, it maps directory hierarchies and compares what currently
          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

    2. By zil0g () on

      less than wowed? what are you talking about?
      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.

  4. By Bye Birdie () on

    With the scarcity of OpenBSD articles and books, anything is welcome. If you have something better to say, get it written up and published some place. I welcome anything written, even if it has mistakes, because in a free society of ideas, the facts will come out. In a place where nothing is said, error rules supreme.

    I learn from his articles, and applaude his effort to lead out.

    Comments
    1. By Dom De Vitto () dom@devitto.com on mailto:dom@devitto.com

      Yes, and peope only get better through public critism and discussion - thus this forum.

      Comments
      1. By Anonymous Coward () on

        I would agree, as long as this forum doesn't degrade into slashdot-style clueless off topic posts

Latest Articles

Credits

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.]