Daniel Troeder wrote: > On Fri, 2009-04-24 at 18:40 +0000, Marco wrote: >> On Fri, Apr 24, 2009 at 5:23 PM, Daniel Troeder <dan...@admin-box.com> wrote: >>> On Fri, 2009-04-24 at 12:00 -0500, Chris Frederick wrote: >> [...] >>> While all that is correct, I would also consider it "bad network >>> behavior" (no offense intended). >> So you consider my 'reject-with' settings to be good practice? > Yes :)
I'll have to agree and disagree with Daniel on this point. I agree that it is "bad network behavior", but the people we are trying to keep out don't stick to using "good network behavior", so why should we? There's a number of dirty tricks people use to circumvent firewalls/networks, and I strongly believe that it is better to hide your presence as best as you can on a network. Now I'm also keeping in mind that you are on a laptop with no remote services. If you start allowing services, then that will change things. If clients are going to be connection to you for certain services, you should be more accommodating to them and play nice with the network where possible. This is more of a personal preference thing. >>> It feels like "security through obscurity". I agree that it is "security through obscurity", but that's not a bad thing. Relying on "security through obscurity" for protection is a bad thing, but adding a layer of obscurity over a defense in depth strategy is not. >>> It may hamper the well-working of a TCP/IP network, as that relies heavily >>> on ICMP. On a server level, yes. But this is a client with no active/accessible services. A server shouldn't rely on ICMP from a client, but the ICMP packets from the server will be picked up by the RELATED flag on the second rule, allowing the client to see the ICMP error from the server. >> I was not really sure how to configure ICMP (ping) correctly. Any input >> appreciated! > That is really difficult, because ICMP is a family of lots of protocols, > from which ping is just one. Others are important too, like telling > routers/hosts about network congestion, and so on... I don't feel > competent enough to give directions. I do always allow ping, as this is > needed in a server environment to check for uptime, but your case may be > different. I agree with Daniel again. Unless you know what you are doing, blocking ICMP is just going to cause problems. And I would argue that iptables is not the tool to use, even if you know what you are doing. If you really want to filter your ICMP packets, look to /proc/sys/net/ipv4/. The kernel will give you some nice options that are a lot safer that an iptables rule. >>> Also: if you wish to scan (nmap) yourself to check your system >>> (configuration), you'll wish for REJECT instead of DROP :) >> You mean as the default policy? > Yes, and also everywhere you use DROP. It's just, that you'll have to > wait less for timeouts, when connecting to a closed port. <segway> I would recommend running nmap in crontab if you want to scan your network (look up ndiff on nmap's website). </segway> > If you decide to go with DROP, then you could make it globally > switchable in your script, to change between testing and production > environment/situation. This is great advice. You may not benefit much from it now with this small script, but as it grows, you really want to keep this in mind. If you modularize your tables, you can turn them on and off with a single insert/delete rather than trying to insert/delete large blocks from the rules, or worse, reloading the whole rule set. Chris P.S. Daniel, no offense taken. I enjoy these debates, it helps us think differently and learn new tricks. If we are not challenged once in a while we get complacent, and that's typically when we start making mistakes.
