Any public facing firewall should _always_ use DROP. Otherwise you leave your firewall to be used by hackers using IP spoofing for DDOS attacks (the reflective attacks I mentioned), and, at least in the United States, you are held liable for any DDOS attacks that are using your server's firewall. Its up to your policy whether or not you want your internal firewalls to use drop or reject. Usually, for internal stuff most people use reject since it makes diagnosing network issues easier. -Adam On Thu, 08 Apr 2010 10:12:06 -0500, SDALAN04 at smumn.edu wrote: > On Thursday, April 08, 2010 6:59 AM, Adam Morris wrote: >> >>Date: Thu, 08 Apr 2010 06:59:30 -0500 >>From: Adam Morris >>To: TCLUG Mailing List <tclug-list at mn-linux.org> >>cc: >>Subject: Re: [tclug-list] Trying to set up a simple firewall >> >>1) Usually, its wiser and more secure to silently drop packets to avoid >>opening yourself to certain reflective attacks. However, it really >>depends on your case. If you're on your own private network, and behind >>a router, its perfectly safe to REJECT packets and then use the router's >>firewall to DROP packets coming in on those ports from the world. >> > > Hi Adam- > > I been recently on the same boat and learning IPtables more seriously for > the first time. > > Coming from PF I always understood that when you drop packets silently > with no feed back the sender will most likely resend the unacknowledged > packets rather then drop the connection, until a timeout counter expires? > > However if you return with status codes such as connection refused this a > better option? > > Thanks. > >>2) As long as you don't have software running on one of those ports that >>could be exploited. I would recommend running a nmap scan on your >>localhost to see if there are any programs you may not realize using >>ports above 10000. nmap by default doesn't look at the full port range, >>so you'll need to specify "-p1-65535" as one of the arguments. >> >>3) That's a little difficult. Do they have dynamic DNS set up for >>themselves? That's the only way I can think you could set that up. >> >>On 4/8/2010 4:39 AM, Andrew Berg wrote: >>> On 4/7/2010 7:26 PM, Adam Morris wrote: >>>> I would recommend taking a look at Shorewall >>>> <http://www.shorewall.net/>. I can't stand dealing with IPTables >>>> myself >>>> but Shorewall simplifies the process. Its still not as easy as some of >>>> the GUI tools such as Firestarter, but once you read through the >>>> tutorials and the getting started guides then you should be able to >>>> perform most things pretty easily. >>> It took a while to figure out the roles that each config file >>> (rules/interfaces/policy/shorewall.conf) plays, but once I had that >>> down, it wasn't too difficult to set things up, so thanks! >>> Three questions: >>> Is there any reason not to use REJECT instead of DROP? Timing out could >>> be indicative of other problems, whereas if the client acts as though >>> the host is unreachable, I know I'm being locked out by the firewall. >>> Is it safe to have all ports above 10000 open to the public in order to >>> allow the server to act as a seedbox as long as transmission-daemon is >>> the only service listening on those ports? >>> How should I handle trusted users who have dynamic IPs without allowing >>> everyone who uses the same ISP as they do? >>> >>> _______________________________________________ >>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >>> tclug-list at mn-linux.org >>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> >>_______________________________________________ >>TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >>tclug-list at mn-linux.org >>http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > > > "Great Spirits Have Always Encountered Violent Opposition From Mediocre > Minds" - Einstein > > "Cuanta estupidez en tan poco cerebro!" > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list