Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Martijn Lievaart <m@rtij.nl>
To: Maxim Veksler <hq4ever@gmail.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: can't ssh outside with OUTPUT (policy ACCEPT)
Date: Thu, 09 Aug 2007 07:16:17 +0200	[thread overview]
Message-ID: <46BAA321.1040503@rtij.nl> (raw)
In-Reply-To: <b400c69a0708081546r394f0123x108cec305d3dda55@mail.gmail.com>

Maxim Veksler wrote:
>   
>> Add LOG rules for dropped traffic.
>>     
>
> I would appreciate an example for this tip.
>   

At the end of any of the {INPUT,OUTPUT,FORWARD} chains where policy is 
DROP, add the rule

-j LOG --log-prefix "(default): "
-j DROP

(that last one is optional, it duplicates the policy. But it is 
considered good style, plus you have counters on this rule, another 
debugging aid).

Another good way to debug such things is to add specific log rules at 
the top of all chains:

-A INPUT -s aaa.bbb.216.35 -j LOG --log-prefix "debug INPUT: "
-A INPUT -d aaa.bbb.216.35 -j LOG --log-prefix "debug INPUT: "

>   
>> Get out wireshark (formerly ethereal)
>>     
>
> Got it, tcpdump -w /tmp/iptables_lock.cap, it seems that iptables hook
> drops the packet before libpcap has a chance on seeing it.
>   

No, tcpdump/wireshark/ethereal sees the packets before netfilter on 
input and after netfilter on output. I think you did something else 
wrong here.

I personally never run a gui on my firewalls, but do have the X 
libraries installed. That way I can ssh -X into the box and run 
wireshark on it.

>   
>> to see what goes on at the line. Read up on how to construct good
>> rulesets
>>     
>
> Would very much appreciate good links here.
>   

I don't know any, but the documentation section of www.netfilter.org is 
a good start. I still want to write a document/site on writing good 
iptables rules, but don't have the time. Maybe I should make the time.

Anyway Rusty Russels unreliable packet filtering guide is a good read 
for the basics, especially on the -m state.

 >> and maybe even on IP (no sorry, I don't have any links).

>
> rfc791, that's for IP. Please correct me if I'm wrong but you meant
> read on TCP because IP is stateless and has no verification what so
> ever buildin, the only tracking IP does is for fragmentation and
> reconstruction of packets. I don't think this was the case here and
> further more I don't see how --state ESTABLISHED,RELATED could have
> any effect on it. Again, please correct me if I'm wrong.
>   

No, you're quite right.

HTH,
M4



      reply	other threads:[~2007-08-09  5:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-08 16:42 can't ssh outside with OUTPUT (policy ACCEPT) Maxim Veksler
2007-08-08 17:45 ` Martijn Lievaart
2007-08-08 19:35   ` Maxim Veksler
2007-08-08 21:46     ` Martijn Lievaart
2007-08-08 22:46       ` Maxim Veksler
2007-08-09  5:16         ` Martijn Lievaart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46BAA321.1040503@rtij.nl \
    --to=m@rtij.nl \
    --cc=hq4ever@gmail.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox