Home > Slackware, Slax > Basic Slackware Security

Basic Slackware Security

  Submitted by oldskoolphreak Slackware, Slax 20 Comments

This article is meant to be a crash course in Slackware security. It will detail some basic steps that should be taken before you consider Slackware to be fully installed.

About The Author

Eugenia Loli

Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.

Follow me on Twitter @EugeniaLoli

20 Comments

  1. 2004-04-02 3:12 am
    Anonymous

    Eugenia,it’s a dead link???

    http://www.oldskoolphreak.com/tfiles/hack/slack_sec.txt

  2. 2004-04-02 3:36 am
    Anonymous

    Eugenia,it’s a dead link???

  • 2004-04-02 3:48 am
    Anonymous

    We’re sorry. The page you were trying to reach has either expired or is no longer valid. If you entered the link manually, please check it and try again.

    At Qwest, we’re committed to delivering the utmost in quality and reliability. If you are having trouble locating information on our Web site, please use one of the following paths for assistance:

    Search the Qwest.com Web site using keywords

    Find answers through our FAQ (Frequently Asked Question) database

    Use our Site Map

    If you are experiencing technical problems with Qwest.com, please call us at 888-235-0156, anytime.

    Your feedback is important to us. Please submit your Web site comments through our Site Feedback Form.

    Thank you for choosing Qwest.

    >>Can not

  • 2004-04-02 3:53 am
    Anonymous

    I got the same error message earlier today. It seems that depending what web router you are hitting it redirects you to a different site. It seems that someone has messed up their DNSes. I have saved the text file on my machine but I can’t reproduce it here, as the authors have left not email address to communicate with them.

    All I can say is to wait a few minutes and retry.

  • 2004-04-02 4:56 am
    Anonymous

    Thx Eugenia for ur the answer,it’s made me clearer.

  • 2004-04-02 5:47 am
    Anonymous

    hi,

    its in the google cache

    look for slack_sec.txt

    Greets

    P

  • 2004-04-02 6:11 am
    Anonymous

    http://www.google.com/search?q=cache:acXMajUbxfUJ:www.oldskoolphrea…

    it did, however, work fine for me in the first place..

  • 2004-04-02 6:26 am
    Anonymous

    it works fine now

  • 2004-04-02 7:52 am
    Anonymous

    I’ve heard many people talking about simplicity and security…and tcpwrappers/xinetd wasn’t a part of that equation.

    this article has you turning it on right off the bat.

    ?

  • 2004-04-02 11:43 am
    Anonymous

    Well where I am, it’s still a dead link…

  • 2004-04-02 1:02 pm
    Anonymous

    1. Sign up to the slackware-security mailing list.

    2. Keep your system patched. As the author mentioned, swaret is a great tool for doing that.

    3. Use Nessus to see what vulnerabilities exist on your box and do what it says in accordance with your security/ease-of-use needs. Basically, deal with all High risks it finds, seriously consider doing what it says regarding the Medium risks and you might be able to live with the Low risks without losing sleep over it.

    Of course if it’s a mission-critical server exposed to the outside world you need to tighten a lot more than this… my suggestions are for a home-based desktop/server.

    Cheers

  • 2004-04-02 1:41 pm
    Anonymous

    oldskool_phreak_.com was pointed to qwest.com on April 1…

  • 2004-04-02 3:13 pm
    Anonymous

    I’ve heard many people talking about simplicity and security…and tcpwrappers/xinetd wasn’t a part of that equation.

    I was wondering the same thing. Using tcpwrappers in addition to iptables just seems to me like a recipe for a headache. I’m not a security expert by any means, but I would only recommend that someone used tcpwrappers if iptables, for whatever reason, wasn’t an option. tpcwrappers works strictly in “user space” if I’m not mistaken? All tcp/ip traffic is technically still allowed and makes it’s way into the “system” where tcpwrappers will then deny a given service. But it’s not dropped or blocked at the same level that iptables works at.

    iptables modifies the rules of the tcp/ip traffic flow at a much lower level – in the kernel itself. The actual rules of the traffic flow are modified in such a way that the packets can be blocked and stopped before the “system” ever sees them.

    It seems to me that using tcpwrappers becomes a needless obstacle that is just bound to confuse the heck out of you sooner or later. “Is tcpwrappers blocking ssh? Or is it iptables that’s causing the block? Or …?”

    What do you guys think? Should you enable tcpwrappers as well in case iptables is somehow compromised? Is that the logic?

  • 2004-04-02 3:56 pm
    Anonymous

    I’m not a security expert either, but everything I’ve read indicates that well protected systems use multiple layers of defense. NetFilter/IPF/PF/IPFW are good first lines of defense but how could it hurt to add additional protection to applications that support tcpwrappers? Administrative load is usually only marginally increased, especially if you have decent scripts supporting your sites and use cfengine or the like for propagation. Just my $0.02……

  • 2004-04-02 4:00 pm
    Anonymous

    is shorewall ok for managing iptables?

  • 2004-04-02 4:55 pm
    Anonymous

    I’m not a security expert either, but everything I’ve read indicates that well protected systems use multiple layers of defense.

    I do think multiple layers are a good thing. For example I have a router/firewall that filters out everything on the Internet from getting on my LAN. And I use IP filterting software on my computers in the house for the sake of completeness.

    And in the case of businesses, NIC’s with integrated IP filterting or a software based IP filtering solution would be good protection from “h4x0r” wannabes who downloaded a script from some “l33t” underground website or the latest Live Linux CD (because they are incapable of actually installing it or don’t want to mess up all their Windows games) and think they are going to “0wn” the comapnies LAN with it. Or some kid who wants to impress his equally adolescent friends by taking his mommies station wagon out for a little “wardriving” session while using his daddies laptop. (I hate the mentality of a 14 year old kid.) If you leave your WAP open (to be nice), then having IP filtering at the Desktops level is a must because obviously at that point your firewall/router isn’t even being used.

    And if it were a concern for me – such would be the case on a business LAN (but as the single user on a small home network it’s not a concern for me) but IP filtering would also help protect users from themselves and each other. Like in the case of MSBlast where just by having Windows machines on your network with open ports, users would spread MSBlast to each other in a microsecond.

    But multiple software based firewall and firewall-like solutions on the same machine doesn’t seem like a good approach in my opinion. But again, I’m not a security expert.

    Another thought – if you did run multiple software based firewall solutions on the same machine, I would think they could potentially conflict and over ride each other if they were both trying to do the same thing. (In the case of tcpwrappers, since it doesn’t actually ‘tweak’ the tcp/ip layer, it wouldn’t be an issue.) But suppose you had two programs running that did both have the capability of modifying the rules of the tcp/ip packet flow … one of your rules says “telnet = bad”, and the other – against your knowledge – says “telnet = OK”, which rule applies? Scary.

  • 2004-04-02 4:56 pm
    Anonymous

    The simplest, cleanest, easiest to understand and maintain firewall rc script builder for iptables is:

    http://www.gnnix.org/base/root/tool/scripts/crimestopper-1.0.tar.gz

    It works with Slackware by default and Fedora with one or two config values changed.

  • 2004-04-02 10:21 pm
    Anonymous

    The authors make many mistakes, including poor decisions and leaving out a lot of crucial information, including mention of RPC services or firewall log analysis, etc.

    I could go on and provide more details, but if I did that, I could spend my entire life doing this with all the crap out there.

  • 2004-04-02 10:43 pm
    Anonymous

    Leaving information out is hardly a mistake, especially when the article is titled “Basic Slackware Security”.

    Im sure the articles writers decided not to add certain information out for the exact same reasons you stated. So, following that line of thought, does that make your post “poor”? ;)

  • 2004-04-03 6:53 am
    Anonymous

    Most of the suggestions are good except for the use of iptables/tcpwrappers. A better solution is a hardware firewall/NAT router which is easier to setup and gives you a centralized point of administration. Even if you have just a single computer, it’s still a better solution but how likely is it that you’re going to have only one computer? However, the real answer to security concerns is that if you want it secure then don’t put it on the Internet. If you really, really want it secure then don’t put it on a LAN. For a really, really, really secure system – lock it up in a bunker room. Something that’s mission critical shouldn’t be directly exposed to the Internet and should use some sort of gateway if it has to be on the Internet.

    However, I have a feeling that a lot of security concerns (or is it paranoia?) are due to wide use and innately poor security record of the Windows OS and it’s apps. It seems no matter what you do today to patch it will still be just as vulnerable tommorrow.

    It worries me that the media and journalists always speak about the latest computer virus/vulnerability du jour as if it were a generic thing. Eventually however, the words “Microsoft Windows” departs their lips. It is then that I take solace in the knowledge that my MicroVAX 8000 remains safe from the bad Internet for another day.