Comments inline... John Wittenberg wrote:
The LEAF version I'm using is a Dachstein floppy v1.0.2.Better depends on what you're trying to accomplish. If you only allow non-syn traffic, apps with masquerading helpers (like ftp) will not work, since no inbound connections are possible without customizing the rules. Also, since there is generally nothing of note running on the router (such as x-servers, port-mapper, and similar things you'll find on a full disto), the need to block high-port traffic is far less than for a general purpose machine.
In an effort to make my firewall more secure, and to learn more, I have been scouring the Internet for
ideas. As a result, I have a few questions regarding the rules set-up in ipfilter.conf.
1) Instead of accepting all TCP packets to the high ports per
# Accept all incoming TCP packets to the External interface on non-priveleged
# ports
$IPCH -A input -j ACCEPT -p tcp -s 0/0 -d $EX_IP 1024:65535 -i $EXTERN_IF
wouldn't it be better to only accept TCP packets that don't have the SYN bit set by using the ! -y option?
As in
$IPCH -A input -j ACCEPT ! -y -p tcp -s 0/0 -d $EX_IP 1024:65535 -i $EXTERN_IF
2) In the two statements, from ipfilter.conf,EX_IP is used for EXTERN_IP in several places. In Matthew Grant's scripts (which Dachstein is based on), EX_IP would either be 0/0 or your external IP, depending on the setting of EXTERN_DYNADDR. In Dachstein, EX_IP is "stuck" at 0/0 (all IP's), due to the ability to assign multiple IP's to an interface, create proxy-arp DMZ's, etc.
$IPCH -A input -j ACCEPT -p tcp -s 0/0 -d $EX_IP 1024:65535 -i $EXTERN_IF
and
$IPCH -A input -j ACCEPT -p udp -s 0/0 -d $EX_IP 1024:65535 -i $EXTERN_IF
what is the definition of $EX_IP? I have searched both network.conf and ipfilter.conf and have not found
any definition. It would seem that $EX_IP should be $EXTERN_IP. Then only packets intended for the
firewall (and the LAN) would be accepted. As the statement is currently written in ipfliter.conf, it
translates to the follwing rule
ACCEPT tcp ------ eth0 0.0.0.0/0 0.0.0.0/0 * -> 1024:65535
ACCEPT udp ------ eth0 0.0.0.0/0 0.0.0.0/0 * -> 1024:65535
from which the firewall accepts all packets. Instead of
ACCEPT tcp ------ eth0 0.0.0.0/0 66.235.19.223 * -> 1024:65535
ACCEPT udp ------ eth0 0.0.0.0/0 66.235.19.223 * -> 1024:65535
which would only allow tcp/udp packets bound for 66.235.19.223 (the firewall external ip address).
There are a few security considerations with this approach, especially if you've got multiple IP's and are using the EXTERN_???_PORTS variables to open ports (you should really be using the EXTERN_???_PORTn walk-list with multiple IPs).
Remember, with IPChains, an ACCEPT rule with a destination of 0/0 only guarantees acceptance of traffic that terminates on the local system. Anything remote still has to go through the forward chain, which is where the bulk of the DMZ filtering is done.
3) If you implement the two changes above, you could just change the last catch all rule for the input toUm...not entirely. The last catch all ACCEPT rule handles traffic from all non-external interfaces. I (and many other folks) use multiple interfaces with Dachstein for multiple internal and/or DMZ networks.
REJECT (or DENY) as those packets you wanted were accepted above.
Of course, if you want to setup your ruleset this way, simply create an /etc/ipchains.input file, with "$IPCH -A input -j DENY" at the end...your deny rule will drop traffic before it can hit the "catch-all" rule, and you'll be responsible for adding appropriate accept rules.
4) Is it better to use Reject instead of Deny? According to one web site,In my experience, the ICMP error produced by Reject isn't much better than the "black hole" produced by DENY, at least across the internet. ICMP traffic has a tendency to get lost (dropped, actually) due to congested routes, mis-configured firewalls, etc. Even if the ICMP error arrives, many applications and OSs don't recognize the ICMP packet as an error and you still have the same TCP timeout delay.
http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject.html, Reject will send an ICMP error, per
RFC1122, which is better as it will not slow down applications of legitimate users. For hackers it really
doesn't matter if it is Deny (Drop) or Reject. Are there any opposing opinions?
For hackers, you typically want to give away as little information as possible. Using "drop" makes the system look like a black hole (ie disconnected or unplugged). Sending an ICMP packet indicates not only that your system is online, but interested parties can also tell a lot about you just by the characteristics of the response packet (ie a linux system running an ipchains/iptables firewall).
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
