can't send or recive any emails

Lord of Gore lordofgore at logsoftgrup.ro
Tue Dec 19 15:28:59 UTC 2006


tamer amr wrote:
> thank you for your concerning 
>   and i really approcitiate that  and i want to tell you something i am trying to be a powerful administrator so i get some mistakes please forgive me and help me to get the right configurations 
>   by the was what is the wrong in the forward chain ? and the output chain 
>   
When a packet enters a chain it will try to match any of the rules in 
the chain. If it doesn't match any of the rules it will obey the chain 
policy.
You have to options when building up a chain. Either you opt for the 
Allow all, Deny Specific or you opt for Deny All, Allow Specific. First 
is less secure than the second but they all have their appliances. When 
you build a server like many of us do you will end up with many services 
on it that in most cases should not be visible to outside world (like 
for instance mysql). So you use DROP policy on INPUT chain and allow 
only specific services through the rules inside the chain.
But your rules do not comply with any of those policies that I mentioned 
earlier. Try and imagine a packet arriving in the OUTPUT chain. It 
either matches a rule inside the chain or doesn't:
1. if it matches:
say it has in header destination port 80. He will match the first rule 
and exit chain and therefore *it will be ACCEPTed*
2. if it doesn't:
say it has in the header source port 81 and destination port 82. It will 
not match any rule so it will obey the policy of the chain and therefore 
*it will be ACCEPTed*.
In both cases the packet will be accepted. So why the rules? Chain 
should have DROP policy in order to have a meaning. Or the rules should 
have target DROP.
>    
>   thank you 
>
> Lord of Gore <lordofgore at logsoftgrup.ro> wrote:
>   First of all I want to say that *I know* that the problem is solved but 
> I see the same mistake done over and over again and I hate this.
> For anyone having problems. You should post *consistent* and *correct* 
> info about your problem. Otherwise your post could sound like this:
> "Hello, I have a service that is not working. What is the problem?"
>
> Here is how I interpret your mail:
>
> tamer amr wrote:
>   
>> when i send an e-mail form yahoo or my mail server i get this error 
>>
>> Remote host said: 550 5.0.0 Access denied
>> what is the problem ?
>>
>>     
> What mail server said this? Yours or another? From whom did the mail 
> originated and was addressed to whom?
>   
>> this is my configurtion for my iptables firewall
>>
>>     
> I believe that your iptables rules are a bit messed up...
>   
>> Chain INPUT (policy ACCEPT)
>>
>>     
> policy for input chain is ACCEPT all packets
>   
>> target prot opt source destination
>> DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
>>
>>     
> here you accept all packets that do not correspond to any established 
> communication? Why? This includes packets that start a new connection.
>   
>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
>>
>>     
> this should be ok if you'd have DROP policy on the INPUT chain but as 
> you have ACCEPT policy it doesn't make any sense.
>   
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:143
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:53
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:67
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:443
>>
>>     
> All this is useless given the fact that you have ACCEPT policy. All 
> these are already accepted.
> This config would make sense if you would have DROP policy on INPUT 
> chain and you'd erase the NEW state rule. Then you would have opened 
> only http, imap, domain, 67??? (maybe you moved ssh to this port...) and 
> https. Then you should experience problems on port 25 and as a response 
> you'd "pierce" your firewall with a ACCEPT --dport 25 rule.
>   
>> LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
>>
>> Chain FORWARD (policy ACCEPT)
>> target prot opt source destination
>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
>>
>>     
> Useless given the policy on FW chain...
>   
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source destination
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
>>
>>     
> same 67 port, I wonder what you use it for...
>   
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state RELATED,ESTABLISHED
>>
>>     
>
> Also useless for the same reason.
>
> >From here I can draw only two conclusions either you sent another 
> iptables config (maybe from another machine) or you should be wide open 
> to incoming traffic.
> So, having said that I wonder how this is resolved by unblocking 
> something that wasn't blocked in the first place...
> My belief is that:
> You were trying to solve the problem on your own and modified all 
> policies to accept to see if the firewall was the problem. Then you 
> posted the modified config to the list. The next step was mr Waleed and 
> mr Nilesh not reading the rules correctly and erroneously sending you to 
> the answer to the problem. Well a few of you will say "What's your 
> problem? The guy had it's problem solved!". Well I think that solving 
> the problem by making two incorrect decisions would not benefit to 
> anyone. This list's scope (from my point of view) is not about solving 
> problems but mostly about evolution. I read threads that I find 
> interesting and could teach me new stuff and I think so do others. And 
> from those others a few might have not understood nothing from this 
> thread although it's about basics on firewalling with iptables...
> So, again: guys, if you have problems post as many info regarding the 
> problem as you have and try not to post incorrect info.
> Maybe this will be added to the etiquette of this list and it will be 
> reminded to everyone that does not respect it.
>
> Thank you for your patience,
> LoG
>
>   




More information about the redhat-list mailing list