Quote:
Originally Posted by giobaxx
Some weeks ago i wrote a thread about how it works iptables now iìm back...a friends of mine gave his scripts that works as basic rule. but i'm still unsure about it....
|
i) You are right to feel unsure
ii) If you read the
manual/tutorial, you'll know everything about iptables and be able to write your own rule set. OK, its a bit long and has more information than you want, but think of the advantages! ('man iptables' is good, too.)
iii) If you really want a firewall that meets your requirements, you are going to have to define your requirements. The closest that you've got to that here is 'a firewall', so, whether you put the information into a script or tell us, there is some further work needed.
Quote:
Originally Posted by giobaxx
The Police were DROP for INPUT and FORWARD CHAIN and ACCEPT for OUTPUT CHAIN.
|
Policies, presumably. I can't think of any of their songs that were relevant. 'Please don't send that packet to me' (which doesn't scan all that well) maybe.
Quote:
Originally Posted by giobaxx
iptables -A FORWARD -i $lan -o $wan -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
|
If nothing else did, that would ring (small) alarm bells with me. That's basically every valid state. OK, maybe dropping invalid packets at the top of the rule set might be a good idea, but then you would be using the stateful bits of iptables (with some overhead, even if it is relatively small, compared to everything else that's going on, but it is inelegant, if nothing else).
And that, as you say, is in a rule that will never be applied, so this suggest a ruleset written by someone not in full possession of the facts, or, to be a bit more generous, slightly sloppy with their editing.
Quote:
Originally Posted by giobaxx
2) the 2nd rule "iptables -A FORWARD -i $wan -o $lan -j ACCEPT" say "let pass all the packet from Internet to the lan" is not dangerous?...seem to open the firewall for all kind of packet directed to the client into the LAN....is so?
|
Yes, it allows all packets coming from the wan to the lan. This is a lot more permissive than many people would want to be, but the extent to which that might be a risk is rather dependant on whether the devices on the lan are locally firewalled. I don't think that I'd be happy about that for a general lan upon which any device could be connected, but I'd get a bit more relaxed if I could say it will only be from a certain list of devices, and that all of them would be linux and all of them would have firewalls. I can't see that as being a realistic set of pre-conditions in many cases.
I'd go as far as to say that it is inappropriate for a general iptables script where you have no knowledge of the devices connected, so take into account that this ruleset seems to be inappropriate for unrestricted use when you decide what you think of it.
Code:
iptables -A INPUT -i $wan -p udp -s 208.67.222.222 --source-port 53 -d 0/0 -j ACCEPT
Now this is more difficult; without knowing what this box is supposed to be doing with DNS. If the box is authoritative and supplying look ups to the outside world, then one arrangement would be appropriate, if it is caching look ups (of names on the internet, for machines on the lan) a completely different arrangement of access would be appropriate.
In general, IIRC, DNS isn't only UDP, so that would be a concern (although it might still work, but badly). Whether 208.67.222.222 should be the only source for look ups (in your situation, not that of the person who supplied the rules) seems questionable. And then you have to worry about what this box is supposed to do. There is no possibility of saying whether it is doing what is required if you don't know what is required (well, unless you write something that works in all use cases, and that could imply a lower degree of protection and a higher degree of complexity than is fundamentally required).
Quote:
|
a response form DNS is a not a packet with state established? the rules that open the ports1024:65535 are not packet in response to the Firewall so with state estabilshed? more in extreme ipotese, if i should know the NAT table i should forge packet directed and accepted by the Firewall even if state of the packet is NEW?
|
I can't quite understand what you are saying, but you seem to be asking whether, once the dns interchange is underway the packets should be in state 'established' - not necessarily. Probably true for a 'caching only' box, but not for the recursion process, which may or may not be relevant if we don't know whether this server recurses (I'd have to guess probably not for you, but maybe for your friend, but you need to define more clearly).
And, if this box is supplying look ups to other boxes on the internal net, then the first packet from the other box, at the start of the interchange, will be in the state 'new'.
Quote:
|
...i have a lot of dubs...
|
Doubts?
In any case, this looks like a slightly random collection of rules that may have made more sense in the context of the person who first wrote them (although, still with quite a few rather questionable elements, and, at least some redundancy, and maybe some holes compared to a better-organised set of rules - you could probably argue that the redundancy is in no way as as important as the security holes - inelegant, but not inherently risky. It does, however, add to the extent to which you are forced to worry about whether the ruleset is really doing what is intended and what is appropriate).
As a rule set that can be transferred to someone else, with a rather different network set-up, I think you'd be better off writing your own or getting some established script, of which there are quite a number scattered round the internet. (Or doing so much fixing that its almost the same as starting again. That would be an option, but not one with any particular advantages.)
