Re: ESTABLISHED makes possible to connect to internal servers

[Arnd-Hendrik Mathias <arnd-hendrik.mathias@nefkom.net>]

Hi Anton,

>>it is possible to access my internal web server (and not only web
>>server) from outside
>>    
>>
sorry, for the silly question: How exactly do you test this and where 
are your server and your test client running?

>>despite I did not open port 80 in FORWARD chain and policy for FORWARD
>>is DROP.
>>    
>>
By the way DROP is your last rule and thus a somewhat "implicit policy". 
Corresponding to your script your policy is ACCEPT. But that won't 
affect the behavior you described. Anyway it will be more secure to set 
your real policies to DROP and as a following of this you can omit the 
last rules of each chain.

>*filter
>:INPUT ACCEPT [0:0]
>:FORWARD ACCEPT [0:0]
>:OUTPUT ACCEPT [0:0]
>
>-A INPUT -i lo -j ACCEPT
>-A INPUT -i vlan101 -j ACCEPT
>-A INPUT -i vlan82 -j ACCEPT
>
>-A INPUT -p 47 -j ACCEPT
>
>-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
>-A INPUT -p tcp --dport 179 -j ACCEPT
>
>-A INPUT -j DROP
>
>-A FORWARD -i vlan101 -j ACCEPT
>-A FORWARD -i vlan82 -j ACCEPT
>
>-A FORWARD -p 47 -j ACCEPT
>
>-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>-A FORWARD -j DROP
>
>COMMIT
>  
>
Maybe messing around with other protocols like "Border Gateway Protocol" 
or "General Routing Encapsulation" is unlikely to ease debugging your 
HTTP connections. So I'd disable these rules temporaryly for debugging 
purposes.
One other silly question: Do you flush your tables before appending 
these rules? Sorry for this kind of questions, but we're all humans and 
sometimes the problems are closer (and easier) than we expect them to be 
;°) At least these information will help to judge your scenario and find 
out the nature of your problem.
Cheers

Arnd-Hendrik