Re: secured server policies
Ansgar Wiechers wrote:
> On 2008-11-08 daniel wrote:
>> Ansgar Wiechers wrote:
>>> On 2008-10-31 daniel wrote:
>>>> iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
>>>> iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED,RELATED -j ACCEPT
>>> You need TCP for fully functional DNS as well.
>> Why do I need TCP for fully functional DNS?
>> TCP must be used for zone transfers.
>
> TCP is also used when the response to a name lookup exceeds 512 bytes
> (the size of a UDP packet).
>
>> In the rule iptables -A INPUT -p udp --sport 53 -m state --state
>> ESTABLISHED,RELATED -j ACCEPT, the module state is not necessary,
>> because it uses UDP, although it works.
>>
>> So, the correct form is:
>> iptables -A INPUT -p udp -j ACCEPT
>
> Wrong. netfilter does keep track even of UDP connections, so a rule
> checking for state ESTABLISHED,RELATED will match only those packets
> that relate to some other connection. Which usually is what you want at
> that point.
Hummm, I thought that ESTABLISHED,RELATED worked with SYN, SYN/ACK, etc...
Please, do you know where do I learn more about that?
>
[...]
>>>> iptables -A INPUT -p tcp -m multiport --dports 22,80 -m state --state NEW -j ACCEPT
>>>> iptables -A OUTPUT -p tcp -m multiport --sports 22,80 -m state --state ESTABLISHED,RELATED -j ACCEPT
>>> What reasons are there to have --sport in the ESTABLISHED,RELATED rule?
>>> Making rules too specific will adversely affect maintenance.
>> I agree with you. But I think if a process on that host (i.e. trojan
>> horse on the door 12345) tries to connect to an external host, it will
>> not work.
>> Is it correct?
>
> To a degree. First of all: when a trojan horse is running on your
> system, your security is already compromised and you should immediately
> take the box off the 'net, investigate how the incident happened, and
> then reinstall the system.
>
> That said, yes, with those rules a process probably won't be able to
> connect outbound. However, that's not because of the ports specified
> there, but because the rule in the OUTPUT chain allows only packets of
> already established connections, and the rule in the INPUT chain allows
> only new inbound connections. Of course I'm assuming here that a) no
> other rules in either chain allows packets in or out, and b) the default
> policies for both chains are set to DROP.
>
> If you're worried about response packets from connections to some
> program listening on port 12345 being allowed by an ESTABLISHED,RELATED
> rule: I'd suggest you rather ask yourself why the connection to port
> 12345 could be established in the first place.
Very good explanation.
Thanks.
>
> Regards
> Ansgar Wiechers
Reply to: