I don't want to seem unhelpful, but I am aware that, at best, I will seem to be nit picking. I would allege that there is no useful statement that can be made on this subject without being careful about the exact meaning, but if you like, you can try to construct a firewall that only approximately does the right thing...
Quote:
Originally Posted by cwhiteacre
I am having a little trouble with the correct syntax for iptables so any advice would be appreciated
|
So, you have warmed me up for a specific question on the syntax of IPTABLES commands...
Quote:
When deleting a rule, when is better to use DROP instead of REJECT and vice versa??
|
...and that isn't it. Over at frozentux there is a tutorial (close to a manual) that will tell you everything that you wanted to know about the syntax of iptables commands, and much more besides. (Download a version, rather than use the html...you'll want to look at it several times.)
Deleting a rule, deletes a rule. The rule isn't there any more. It has gone. It has become an ex-rule and joined the choir invisible.
A rather different question is whether it is better to drop or reject. This applies to chains and is a matter of taste and/or which bad thing you dislike the least. If you 'drop' ....perhaps better described as 'silently drop'... you just discard the packet and don't send any message to the packet's originator. This isn't entirely RFC-compliant, so you have broken one of the standards that holds the internet together (boo! hiss! dead parrots!*), but there are some situations in which you have deprived a potential miscreant of some information that they would have considered helpful (hurray! wonderful! live parrots!), so this may be considered more secure.
OTOH, if you reject (send a helpful message back to the originator telling them that you didn't think much of their beautiful packet and are putting it in the bit bucket) the opposite happens; you have complied with the appropriate standard (RFC) but you may have helped someone who maybe you would rather not helped.
If you are happy with actually thinking about the situations which occur, you may be able to think of some situations which can only occur on your internal network and you may feel for those situations 'help in debugging' outweighs 'RFC compliance' and for situations in which some external actor could take advantage 'security' outweighs 'RFC compliance' and/or 'help in debugging'. Or not, to taste.
And, while I am here, it is sometimes said that setting a chain's policy (I know that you didn't mention the word 'policy' but it is one of the things that could underlie this question) to drop is somehow rather better than anything else. Bear in mind that a chain with a policy of drop is, functionally, the same as a chain which has drop as its last command, so the advantage for a policy of drop is essentially clarity (if it is more clear) and an obstacle in the way of accidentally (or malevolently) making a mess of the behaviour of the chain.
* PS, broadly, in spite of packet dropping being somewhat non-RFC-compliant, the internet goes on, seemingly without caring that you have done this. Which is perhaps as well.