Hi Michael,

thanks for reply,
no i don't have ip_conntrack_ftp enabled, just conntrack

# lsmod | grep conn
ip_conntrack           47156  4 ipt_MASQUERADE,xt_state,iptable_nat,ip_nat
nfnetlink                  6680  2 ip_nat,ip_conntrack

your setup got me a bit confused,
because you drop after accepting. In stateful talk, i tend to understand that DROP would refer to NEW packets
I should check iptables docs, but at a first look
it seems to me logically that when you don't specify the connection state, the rule
automatically sets if for you as NEW,ESTABLISHED,RELATED. (all three states)

> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -p tcp --sport 12345 -o eth0 -j DROP

And i still don't get it why it works in your use-case setup and not in mine, connections are tracked (or not _o? )
i intend to think it's not conntrack related, but to firewall design.

iptables -A OUTPUT -p tcp --sport 12345 -o eth0 -j DROP is equivalent of not writing it and stating:
iptables -P OUTPUT DROP

>>Oh, I forgot to mention, that the fwknopclient.exe binary was
>>contributed by Sean Greven; I didn't write that code.

Sean was very kind, thanks again, sending an message that he's going to incorporate CMD_EXEC
very soon into the GUI.

By the way, as mailing list manager, do you agree to some emails related to the win32 GUI client ?

Last but not least, sorry if this mailing list isn't a proper place to this:
"ShmooCon 2007 - Attack Detection and Response with Linux Firewalls" i suggest you should update your blog-post (
ShmooCon Talk: Attack Detection and Response with Linux Firewalls,Thursday, 01 March 2007 )
with the presentation video/link, http://www.shmoocon.org/2007/videos/
Nice one :)

On Dec 8, 2007 6:00 PM, Michael Rash <mbr@cipherdyne.org> wrote:
On Dec 08, 2007, Michael Rash wrote:

> On Dez 06, 2007, Marius Rugan wrote:
> > Hi all,
> > first of all @developers thanks for your great work.
> >
> > I'm currently using an iptables approach on one of my machines
> > which is DROP-ing everything, so explicit ACCEPTs should be generated
> > for traffic to occur.
> >
> > # Set the default policy to drop
> > iptables -P INPUT DROP
> > iptables -P OUTPUT DROP
> > iptables -P FORWARD DROP
> >
> > # FTP in
> >
> > iptables -A INPUT -i $INTERNAL_INTERFACE -p TCP -m state --state
> > --sport $UNPRIVPORTS --dport 21 -s $MY_INT_FTP_CLIENT -d $INTERNAL_IP -j
> >
> > iptables -A OUTPUT -o $INTERNAL_INTERFACE -p TCP -m state --state
> > --sport 21 --dport $UNPRIVPORTS -s $INTERNAL_IP -d $MY_INT_FTP_CLIENT -j
> >
> > however fwknop/SPA implementation is injecting only one rule for the INPUT
> > subchain. I need also a OUPUT rule
> > to be injected so traffic could occur between both sides (client server)
> I think the state rule in the OUTPUT chain should handle this since
> conntrack should allow return traffic back out even though there is only
> one ACCEPT rule in the FWKNOP_INPUT chain.  For example with the rules
> below I was able to start a netcat server on tcp/12345 and still reach
> it over eth0 from a separate system even though there is no explicit
> ACCEPT rule in the OUTPUT chain to allow packets associated with the
> connection back out (except for the state rule):
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A INPUT -p tcp --dport 12345 -m state --state NEW -i eth0 -j \
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -p tcp --sport 12345 -o eth0 -j DROP
> Out of curiosity, do you have the ip_conntrack_ftp module loaded?
> I do think it is a good idea to offer support for the OUTPUT chain
> though, because not everyone may be using the conntrack modules, and I
> will try to get this into the next release (1.8.4).  I'll add you to the
> credits file for making the suggestion.
> > Is there any way of doing it / hacking the fwknop code so this could occur?
> > I thought of implementing it by sending it packed as a command using *
> > ENABLE_CMD_EXEC* but my target is having a win32 client
> > doing it, and this isn't yet implemented in the gui
> > fwknopclient.exe(excelent work also)
> Yes, the fwknopclient.exe binary is excellent.  OUTPUT chain support
> should be built into the fwknopd server side via a config tweak though,
> so I'll add it.

Oh, I forgot to mention, that the fwknopclient.exe binary was
contributed by Sean Greven; I didn't write that code.


SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Fwknop-discuss mailing list