Common *nix Security Practice's - Page 3
Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: Common *nix Security Practice's

  1. #21
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,883
    LOL,

    Yes, I know exactly what you are referring to. I promise one day....
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  2. #22
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    NOOO, don't give up Where you able to walk when you where born? No. Did you fall on your face trying to stand up? Probably alot. Did you eventually get the hang of it? I sure hope so. Making mistakes is all part of the learning process. Nobody get's it right the first time (and some people the second, third, fourth etc.). It's all about making progress and learning from the mistakes you make. Just look at my sig and think about it.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  3. #23
    Junior Member
    Join Date
    Jan 2004
    Posts
    20
    tzu
    NIX password handling goes beyond that, including special chars and encouraging to include lower and upper case. Here is a very good password example: 0MfG_4Ev@_
    ok i agree with you tzu

    but when you are jumping around using different keyboard sets and mappings these weird characters can create a lot of problems
    i don't know how many times i have to try to figure out were a certain special characters is located on a system where the mapping is wired.
    (try VAX machines they can drive you nuts, with that damm gold key to get a special character, hours of fun)

  4. #24
    but when you are jumping around using different keyboard sets and mappings these weird characters can create a lot of problems
    i don't know how many times i have to try to figure out were a certain special characters is located on a system where the mapping is wired.
    shift+1= !
    shift+2= @
    shift+3= #

    I'm not talking about oddly special chars like: ǽ and Ữ Just normal shift+# special chars. And that should be universal on keyboard mappings.

  5. #25
    Junior Member
    Join Date
    Jan 2004
    Posts
    20
    sorry tzu but they are not universal shift + 2 is " on my Swedish key board i utilize a french site(don't know if its just that site though) and there " its shift + 3 and so on it can get interesting some times.

    but like its just a small point if one is jumping around swapping systems back and forth like i get tricked into doing

  6. #26
    AO Guinness Monster MURACU's Avatar
    Join Date
    Jan 2004
    Location
    paris
    Posts
    1,002
    pooh sun tzu
    That only works on a qwerty(english) keyboard. better advice is to learn your asci table and use alt with the asci code. For example :
    ALT 64 gives @
    ALT 33 gives !
    ALT 35 gives #
    Of course i dont know if this works on a unix machine.

    edit :
    di0strb lol you got in before me
    end edit
    \"America is the only country that went from barbarism to decadence without civilization in between.\"
    \"The reason we are so pleased to find other people\'s secrets is that it distracts public attention from our own.\"
    Oscar Wilde(1854-1900)

  7. #27
    Ah Thanks for clearing that up guys! I was unaware that something so minor could be so different. I -still- recommend using special chars on security passwords. A bit of keyboard frustration until the movements are memorized versus a broken network.

  8. #28
    Senior Member
    Join Date
    Mar 2003
    Posts
    245
    I realize that this is almost a month old, apologies in advance for that.....

    I can't help but notice that a lot of the 'UNIX Security' stuff assumes one or a couple of boxes with a small handfull (if not just one) user. Keep in mind that in an installation of any significance and depending on what the environment is setup like, much of what is frequently mentioned here on A.O. is not the least bit scalable, if it will work at all.

    Medium to large installation reality check:

    - There are going to be several users who have the root password. It is not uncommon for something on the order of 30 - 50 people (or more) to know the root password at large installations.

    - Much of the time you are going to be building/patching a system and then handing it over to a customer (e.g. engineering dept.). From that point you become a fireman, chasing after and fixing the messes they make.

    - Restricting access to 'safe' activity is only going to work until the 50th time they call you at home at 03:00 on a Sunday to fix something or run some command for them.

    - Honeypots and the like belong on DMZ's and serve absolutely no purpose on a machine that anyone would ever actually use.

    - Viruses aren't a real threat in the UNIX world, but Worms and Trojans are among the worst possible scenarios next to mass internal network comprimise.

    - You can't always run the latest and greatest, or even the lastest patch level for that matter. Software vendors often have specific requirements and if you aren't at the OS version and patch level they require you won't get support.

    - Real UNIX environments run things like NIS+ and LDAP which aren't exactly a security freaks idea of a secure environment. Of course, only fools run either of these on a machine that is accessible from the outside.

    Real world tips:

    - Only allow root access via console. Have some kind of serial console (e.g. lantronix) set up on all of your machines, and only allow root to log in there. Disallow direct login everywhere else (e.g. telnet, ssh)

    - NEVER put . or :: in root's path! Doing so is begging to run somebody's trojaned command. For that matter, use a minimum PATH for root . Something along the lines of /sbin:/usr/bin:/usr/sbin:/usr/lib/nis:/etc (Solaris) or /sbin:/usr/bin:/usr/sbin:/etc:/usr/etc (AIX and IRIX), etc. Personally, I prefer to unset PATH in roots .profile

    - Get in the habbit of using the full path to the command, e.g. /bin/su - instead of just su. The theme is to always know exactly which command you are running.

    - root passwords should change every 30 days, should be a generous mix of non-alphanumeric (e.g. # @ _ ? ^) characters, and should follow an agreed upon convention to make them easier to remember

    - The root password on servers and workstations should be different.

    - Important log files from all hosts should be sent to a loghost if possible and written to some type of 'write once' media.

    - Properly secure and audit each machine before putting it into production. This will greatly reduce the work involved in security monitoring once users get a hold of it.

    Just my thoughts...

    -- spurious
    Get OpenSolaris http://www.opensolaris.org/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides