Re: secured server policies
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.
>> You should also allow some ICMP types.
>
> I think so. What ICMP types would you set?
I usually allow these types:
iptables -N ICMP
iptables -A ICMP -p icmp --icmp-type destination-unreachable -m state \
--state RELATED -j ACCEPT
iptables -A ICMP -p icmp --icmp-type source-quench -m state \
--state RELATED -j ACCEPT
iptables -A ICMP -p icmp --icmp-type parameter-problem -m state \
--state RELATED -j ACCEPT
iptables -A ICMP -p icmp --icmp-type time-exceeded -m state \
--state RELATED -j ACCEPT
iptables -A ICMP -p icmp --icmp-type echo-reply -m state \
--state ESTABLISHED -j ACCEPT
iptables -A ICMP -p icmp --icmp-type echo-request -m state --state NEW \
-m limit --limit 10/s --limit-burst 50 -j ACCEPT
>> [...]
>>> 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.
Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
Reply to: