On Tue, 28 Mar 2000, Warrl wrote:
On Tue, 28 Mar 2000, Rogier Maas wrote:
Hi,
I have a question regarding ipchains. What I would like to accomlish is to allow all outgoing traffic from my masqueraded network to the outside no matter what, while denying (not answering) all inbound connections (except a few).
That's easy.
The catch is, you DO want to accept inbound responses to outgoing packets. And doing that, while closing off the ports, is apparently not possible with ipchains or its predecessor ipfwadm. Because the forwarding chain operates *between* the input chain and the output chain - a packet to be forwarded has to go through all three.
Let me emphasize that, when it comes to firewalling, there is no substitute for a good grasp of the concepts of IP networking. There is an old (but very useful) tutorial among the collection of Internet RFCs: RFC 1180. You need to know the difference between the network behaviors of TCP and UDP, and the consequences for packet filtering. First of all, your 'ipchains -I input -j DENY', if otherwise not limited by preceeding rules or chains, will serve to block packets from your internal network from being accepted by your firewall's internal interface--they won't even get to the forward/masq stage. Probably better would be to put the DENY/REJECT rule last in your input chain, and qualify it with '-i ppp0' (or whatever your external interface is), to prevent denial of packets on your internal network. TCP is a connection-oriented protocol, so it gives you a criterion by which you can tell at the transport level which packets are connection initiation attempts, and which are part of an ongoing connection, possibly initiated by a host behind your firewall. To accomplish what you want, you use the '-y' flag in ipchains in some fashion, either to deny packets from the outside with the SYN bit set and ACK bit cleared (if your default policy is to accept packets; these are attempts to initate a connection), or to allow packets from the outside with the ACK bit set (if your default policy is to deny packets; these are part of an ongoing connection). UDP is a connectionless protocol, good for individual datagrams and streams of data where performance matters more than integrity. You therefore have no convenient way at the network or transport level of detecting direction. My strategy is to decide what UDP services I want to permit, and with what hosts. As a consequence, I pretty much only allow UDP datagrams from the outside coming from port 53 of my nameservers, and from port 123 of my timeservers. I also accept datagrams on external port 7070, which, with the ip_masq_raudio.o module permits UDP RealNetworks streams. If you play Quake and such, you will need to accept UDP datagrams on other ports as well, and possibly to use further kernel modules. Until you get the basic services working, there is little point in worrying about ICMP. Perhaps if I have time later, I will post a basic ruleset you might be able to modify for your purposes. I hope this helps. Chuck ====================================================================== Chuck Bearden cbearden@rice.edu Electronic Resources Librarian Fondren Library--MS44 713 / 527-8101 x3634 Rice University 713 / 737-5859 (fax) P.O. Box 1892 Houston, TX 77251-1892 ====================================================================== -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/