Printable View
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.
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 :)
here you go
http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html
Yes, it is.Quote:
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.
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).Quote:
I have been able to shut down all traffic coming in and going out.
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
Quick question:
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?Quote:
The main thing that firewall newbies miss, is the fact that to allow outgoing connections, you still have to allow incoming packets
Not necessarily, but by and large that is true. Notable exceptions would be DHCP and DNS traffic.Quote:
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)?
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.Quote:
How can we predict local port usage?