Results 1 to 6 of 6

Thread: Ipchains Question.

  1. #1

    Ipchains Question.

    I am running Slackware 8.0 and I was wondering if it is possible to use ipchains to stop incoming traffic on all ports, but to allow certain services (ssh for example) to be able to have outgoing connections. I have been able to shut down all traffic coming in and going out. If at all possible can someone help me put together a basic set of rules for this box? Thanks in advance.
    \"I am trying to beat it but it is a losing fight.\" - My dad said this the day before he died. I will make him proud.

  2. #2
    For now, get a firewall working. Afterwards, learn how ipchains/iptables works in depth. So, the first step would be to get, compile, and install a frontend interface to your firewall rules:

    http://firestarter.sourceforge.net/

    Also, consider moving up to slackware 9.1, since when it comes to slack, newer is better. You could always do a full upgrade from 8.1 to 9.1, but that's risky. I say just download CD 1 from slackware 9.1 and then toss me an AIM message. I'll walk you through slackware from top to bottom. Much faster than here

  3. #3

  4. #4
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207

    Re: Ipchains Question.

    Originally posted here by melakii
    [B]I am running Slackware 8.0 and I was wondering if it is possible to use ipchains to stop incoming traffic on all ports, but to allow certain services (ssh for example) to be able to have outgoing connections.
    Yes, it is.

    I have been able to shut down all traffic coming in and going out.
    The main thing that firewall newbies miss, is the fact that to allow outgoing connections, you still have to allow incoming packets (in some cases).

    The easiest way of doing it for TCP, is to use flag-based rules - so you block incoming tcp packets with syn set and ack clear. This is great, but it does nothing against UDP - which is tougher. And it doesn't prevent various fingerprinting systems.

    To do that, ensure that you have (iptables) connection tracking enabled, and only allow incoming packets that are part of (or related to to allow valid icmp traffic) an existing connection.

    Some UDP protocols work in a way which is unfriendly to this kind of rule (mostly games). They don't generally work very well with other types of firewall either.

    Slarty

  5. #5
    Quick question:

    The main thing that firewall newbies miss, is the fact that to allow outgoing connections, you still have to allow incoming packets
    Now, local port usage is randomized (AFAIK) and thus wouldn't a port 80 connection to a remote webserver possibly involve a local port 10512 (for example)? How can we predict local port usage?

  6. #6
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    Originally posted here by pooh sun tzu
    Now, local port usage is randomized (AFAIK) and thus wouldn't a port 80 connection to a remote webserver possibly involve a local port 10512 (for example)?
    Not necessarily, but by and large that is true. Notable exceptions would be DHCP and DNS traffic.

    How can we predict local port usage?
    As for your question, what slarty was referring to was connections that have been established or are related to other connections (both show with the ESTABLISHED, and RELATED keywords in netfilter). If you simply drop ALL incoming traffic you won't be able to establish outbound connections as the reply packets will get dropped. You must make an exception for established connections as well as potentially related connections.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

Posting Permissions

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