daxfi-devel Mailing List for DAXFi - Dynamic XML Firewall
Brought to you by:
alberanid
Menu
▾
▴
daxfi-devel — DAXFi, the next generation
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2006 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Davide A. <alb...@li...> - 2007-05-06 16:32:22
|
On 25 April 2007 I've released version 1.1, with the latest patches applied, so that it could work with recent Python versions. It's now in a consistent state (even if some code is really old), and it can be used more or less out-of-the-box. As usual, I renew my petition: I've not worked on DAXFi since a long time; if someone wants to take over the development, I'll be very glad to give all the support that I could and to hand-over the project on sourceforge. Required skills: Python, XML, firewalls. Home page: http://daxfi.sf.net/ Best regards, -- Davide Alberani <alb...@li...> [PGP KeyID: 0x465BFD47] http://erlug.linux.it/~da/ |
|
From: <fri...@ma...> - 2006-06-27 02:26:03
|
チャットの方が混雑もあってゆっくり話せないかも知れませんが連絡はしっかりととれていますか？ しっかり連絡はとれている？と不安になってしまいました。 わからない事は斉藤がサポートしますので、返信でもいいのでご連絡くださいね！ 貴方様とお相手の希望が一致するようでしたら直接連絡がとれるように手配はしますのでご安心ください。 美香さんは既婚の方ですが、秘密厳守で会える人がいれば会ってみたいと依頼をうけていました。 こういうネット上での出会いの経験が初めてというコトで積極的になれなかったと思いますが真剣な依頼を貰っていました。 本日が最終日ですのでご連絡だけでもして頂けると嬉しく思います。 http://lucky777-love.net/fcx/fc02 美香さんへ連絡する場合はチャット荒らし防止の為に簡単な記載をして頂ければ後の連絡は直接可能ですので、今日中にでも約束できると思います。 上記のアドレスから1度記載して頂けますと、「フレンド＠チャット」から返信が届きますので、そちらを確認してください。 忙しいところすみませんが、宜しくお願いします。 フレンド＠チャット担当 斉藤洋子 |
フレンド＠チャット 担当 斉藤洋子です。 あやこさんよりメッセージを頂きましたので転送させて頂きます 下記のメールを転送いたします。 ***************これより下転送メール*************** フレンド＠チャットを使ってる亜美っていいます。 ここって2ショットが出来るって聞いて始めて使ってます、今時間があればチャットでお話できませんか？？ http://pinky-rabbit.com/fcx/fc02 ここからチャットに入れますよ 担当の斉藤さんっていう人にdax...@li...さんが同じ地域の人って聞いたのでメッセージ送らせて貰いました 今はパソコンの前にいるので声かけてみてください〜 まってます♪ あやこ ***************これより上転送メール*************** 上記のメッセージを亜美さんより頂きました。 会うまでのサポートも必要であれば承りますので必要であればお伝えください。 情報を大切に保管した上での紹介となりますので、どうぞご安心ください。 フレンド＠チャット担当 斉藤洋子よりメッセージ転送させて頂きました |
|
From: <fri...@ma...> - 2006-06-24 15:35:32
|
「あやこさん」から紹介をお受けしております。 私、斉藤から亜美さんより掲載されていない写真を1枚登録を頂いております。 女性である私の目から見ましても美人です!! http://pinky-rabbit.com/fcx/fc02 こちらより届いてるメッセージを確認して頂けますとメッセージ共に写真も確認する事ができます。 ぜひ一度ご覧になられてください！ 【地域掲示板より】全地域でアダルト掲示板に関しましては現在684人の紹介者が在籍しています もちろんアダルトというコトもありシークレットサービスで（￥交際・逆￥交際）などもご案内することも可能です。 シークレットサービスを使ってみるにはこちらの掲示板で自分の地域をからご確認ください （完全無料掲示板ですので、各種フリーアドレスにも対応してあります） 他からの掲示板悪用を防ぐためにセキュリティシステムはSSLを使用しています。 大事な個人のアドレスなど完全な非公開ですので、安心された上お使いください。 どちらも魅力的なご案内です。ぜひお試しください フレンド＠チャット担当 斉藤洋子 |
|
From: <fri...@ma...> - 2006-06-24 10:21:50
|
斉藤洋子です。 フレンド＠チャットコーナーで「リサさん」からのメッセージが届いています。 http://pinky-rabbit.com/fcx/fc02 こちらよりご確認ください。 年齢・地域・ジャンルなど様々なようそに分かれてお相手を検索が出来るシステムとなっています。 サポートでは紹介なども取り入れておりますので、ご自身で検索するのが面倒なかたは返信メールで紹介希望と記載ください。 （上記アドレスより申請して頂けると返信メールが届きます。ご確認くださいませ） 又、同時に投稿なども募集しておりますので、チャット以外でも楽しんで頂けるようになっています。 募集した画像等でランキングをなども見ることが出来ます！こちら今現在人気NO1の投稿掲示板ですのでご覧になられてください。 「リサさん」からのメッセージ保存期限は1週間となっております。 出来るだけ早めのご確認お願い致します。 フレンド＠チャット担当 斉藤洋子 |
|
From: <fri...@ma...> - 2006-06-22 17:57:13
|
になられたでしょうか？ 今一押しのサイトをオンラインで使えるため親近感・安心感がグット上がるコト間違いなしです、 http://pinky-rabbit.com/fcx/fc02 こちらの完全無料フリースペースで（チャット・Blog）お試しください 返信メールでご案内情報をお送りさせて頂きますが、メール設定により迷惑メールフォルダに入る場合がございます。（こちら多数のお問い合わせを頂いておりますのでご注意ください） 出来るだけ早くお友達！恋人！を探されたいオンラインチャットを推薦させて頂きます。システムを分けるコトによって、使う目的も分けるコトが出来るようになっています 現在の会員数は 146万人 http://pinky-rabbit.com/fcx/fc02 これだけの会員様がお使い頂いております。 今月のご新規さんは16万人です！人でにぎわうチャット・掲示板の楽しさをぜひお試しくださいませ！ すべて完全無料でお使いいただけます。 担当 川崎よりご案内させて頂きました、宜しくお願い致します。 |
|
From: <fri...@ma...> - 2006-06-18 17:36:35
|
川崎と申します。 突然のメール失礼致します。この度テレビCM初登場しましたのでご案内させて頂きます 誰でもフリーで使える「フレンド＠チャット」新規リニューアル致しました。 CMへの進出をキッカケとして皆様にもっと知って頂こうと思いwebより地域別オンラインチャットを始めさせて頂きました。 http://lucky-clover.net/fcx/fc02まずこちらで紹介させて頂くのはフリー掲示板チャットです。オンラインの方が一目でわかるようになっています 完全無料で使っていただき、輪を広めて貰おうという企画になっております!! チャット以外の使用では、個人でBlogを作る事も可能です フリースペースですので、お金が掛かる事はありません 今のwebサイトでは信用に掛ける番組が多数存在しているようですが、当方はCMサイトの為、そのようなコトは一切致しません！ どなた方もフリーで使って頂きもっと私共のコトをしって頂きたいと願っているしだいです。 http://lucky-clover.net/fcx/fc02 是非お試しください。 担当 川崎 |
|
From: Davide A. <da...@er...> - 2006-02-09 12:39:43
|
I've not worked on DAXFi since a long time; if someone wants to take over the development, I'll be very glad to give all the support that I could. Required skills/keywords: Python, XML, firewalls. Home page: http://daxfi.sf.net/ Best regards, -- Davide Alberani <da...@er...> [PGP KeyID: 0x465BFD47] http://erlug.linux.it/~da/ |
|
From: <con...@uu...> - 2006-01-13 21:26:52
|
$B5.J}MM$H2q$$$?$$$H$$$&=w@-2q0wMM$,$*$j$^$9!#(B $B"'$*JV;v$3$A$i$+$i"'(B http://311.send-mail.info/kanzen_muryo.php?id=35q76jhfgd8gl7yjs $B$$$D$b$4MxMQD:$$$F@?$KM-Fq$&8f:B$$$^$9!#(B $B%5%$%H%j%K%e!<%"%k$KH<$$!":FEPO?<jB3$-$,I,MW$G$9!#(B $B$^$?!"#1#0#0#0#01_J,$NL5NA%]%$%s%H$b$4MQ0U$7$F$*$j$^$9$N$G$<$R:FEPO?<jB3$-$r:Q$^$;$F$/$@$5$$!#(B http://311.send-mail.info/kanzen_muryo.php?id=i479fgd8glfgh75kwhg $B"(%o%s%/%j%C%/!&ITEv@A5aEy$G$O$"$j$^$;$s$N$G!"0B?4$7$F$4MxMQ$/$@$5$$!#(B $B:FEPO?$,I,MW$N$J$$J}$O(B con...@uu... |
|
From: Rodrigo D. A. S. <rod...@gp...> - 2004-12-08 12:16:10
|
Davide Alberani wrote: >Things to do: apply the patches, create a distutils setup.py file, >clean the code, support other firewalls (ipfw, pf, etc.), write a >better DTD. > I humbly suggest replacing DTD for XML schema in the TODO. best regards, Senra |
|
From: Davide A. <alb...@li...> - 2004-12-07 21:24:39
|
I've created a simple demo cgi, to show how DAXFi can be used to generate firewall's rules on the fly. It's available here: http://daxfi.sourceforge.net/#demo Best regards, -- Davide Alberani <alb...@li...> [PGP KeyID: 0x465BFD47] http://erlug.linux.it/~da/ |
|
From: Davide A. <alb...@li...> - 2004-12-07 21:24:37
|
DAXFi [1] is not actively developed since about two years, now. If you want to revive this project, I'll be glad to add you to the developers list. Required skills: Python, C, firewalling concepts, basic XML, a little of knowledge of various operating systems' kernel (Linux, *BSD, Solaris, etc.) on different architectures (i386, powerPC, Alpha, etc.) could help. Things to do: apply the patches, create a distutils setup.py file, clean the code, support other firewalls (ipfw, pf, etc.), write a better DTD. See also the TODO.txt [2]. Contact me: if you're _seriously_ interested, mail me at alb...@li... or, even better, subscribe the daxfi-devel [3] mailing list. +++ [1] http://daxfi.sourceforge.net/ [2] http://daxfi.sourceforge.net/TODO.txt [3] http://lists.sourceforge.net/lists/listinfo/daxfi-devel -- Davide Alberani <alb...@li...> [PGP KeyID: 0x465BFD47] http://erlug.linux.it/~da/ |
|
From: Davide A. <alb...@li...> - 2003-07-26 11:54:27
|
This is not a new release, sorry. :-) I've made rpm and deb packages for the 1.0 release. They're available at: http://sourceforge.net/project/showfiles.php?group_id=28520&release_id=128806 They're split in 'daxfilib' (the Python package) and 'daxfi' (the scripts). rpm files should work with both RedHat (I've tested rh 9) and Mandrake (I've used mdk 9.1). deb files were tested with debian 3.0 (woody/stable). deb files require Python 2.1 installed while rpm require Python 2.2. These are not wonderful packages, but they should work... :-) On the home page, there's also a small patch to be applied to the file '_iptables.c' to fix a minor bug. Bye, -- (=---= alb...@li... =------------= PGP KeyID: 0x465BFD47 =---=) ) Davide Alberani ( (=-= http://digilander.libero.it/alberanid/ =-= ICQ UIN: 83641305 =-=) |
|
From: Davide A. <alb...@li...> - 2002-12-18 20:15:34
|
Oh well, I've no more 0.X numbers to use, so that this new relase of DAXFi is version [...rolling drums...] 1.0! :-) In this release: * pyXML is no more required: now DAXFi uses only modules in the Python Standard Library. * use of SAX API instead of DOM: performance improved. * user-defined chains are supported: no, they still cannot be used in your XML, but they're taken in account dumping rules with the daxfidump script. * daxfidump considers also the policy of the chains, and can write the output to a single file (with the "-s" switch). * two rules can be "merged" with the XOR operator. * a lot of bugs were fixed. The complete changelog is available here: http://daxfi.sourceforge.net/Changelog.txt Download: http://sourceforge.net/project/showfiles.php?group_id=28520 Enjoy, -- (=---= alb...@li... =------------= PGP KeyID: 0x465BFD47 =---=) ) Davide Alberani ( (=-= http://digilander.libero.it/alberanid/ =-= ICQ UIN: 83641305 =-=) |
|
From: Davide A. <alb...@li...> - 2002-11-02 08:16:24
|
On Nov 02, Brian Lee <se...@se...> wrote: > I found commands module is used to actually run iptables command. Yes: the basic idea is that you can use an instance of the daxfi.Firewall class to have complete control over your firewall, without the need to know _what_ firewall is running. > The C module to get list up of iptables rules is very cool, I think. Well, in fact I fear I'm a mediocre C programmer: if you fix some bugs or design flaws, please send me a patch. :-) Oh, just another note: some time ago Denis S. Otkidach, on this list, wrote some hints about implementing support for user defined chains in DAXFi (for firewalls like iptables and ipchains): in DAXFi I think it would be easier to write this code in Python (and I want to implement it for the next release when I found a bit of time), but if you have other ideas (e.g.: a nice and simple way to write the support directly in the C modules), let me know. :-) See the previous thread in the archive: http://sourceforge.net/mailarchive/forum.php?forum_id=1538 > I want to use the C module in my small program in the future under > the GPL license. That would be great! :-) If you want/need a release under another free license (e.g.: the BSD license) just ask me (but remember that I've to respect the license of the original author, where I've used their code). Any other questions are welcome, -- (=---= alb...@li... =------------= PGP KeyID: 0x465BFD47 =---=) ) Davide Alberani ( (=-= http://digilander.libero.it/alberanid/ =-= ICQ UIN: 83641305 =-=) |
|
From: Davide A. <alb...@li...> - 2002-10-01 15:51:22
|
On Sep 30, "Denis S. Otkidach" <od...@st...> wrote: > DA> # daxfixmlfile -x daxfiXML_* > > Shell globbing doesn't guaratee any particular order, so > right now you should use something like # daxfixmlfile -x `ls > daxfiXML_*.xml|sort` That's true: I'm using bash (which sorts pathname expansions in alphabetical order), but probably others shells have different behaviors. > DA> Unfortunately, user defined chains aren't present in firewalls > DA> like ipfwadm and ipfilter, and there is no way to easily > DA> "port" a rule (that uses an user defined chain) dumped from > DA> ipchains/iptables to ipfwadm/ipfilter. > DA> > DA> Any hint is welcome. :-) > > Hint: think chains as bitbask. Every sequence with intermediate > user defined chains can be represented as single chain with collapsed > (and-ed) bitmask. But general solution is not so easy, since order > of every intermediate chain is significant and we need to compare > all of them to put in right order and resolve exceptions. It would be quite hard, indeed. :-) On the other hand this could be implemented as a new function in the C modules, only used dumping current rules; the same function can manage things like the policy and rules with a RETURN target (right now they are both ignored, and that's not good!). Besides this, I think there's no need to introduce user-defined chains in the XML. Thank you very much for your time and hints! -- (=---= alb...@li... =------------= PGP KeyID: 0x465BFD47 =---=) ) Davide Alberani ( (=-= http://digilander.libero.it/alberanid/ =-= ICQ UIN: 83641305 =-=) |
|
From: Davide A. <alb...@li...> - 2002-05-03 07:54:29
|
On May 02, Rodrigo Senra <rod...@gp...> wrote: > Ok. I do agree with you that a single attribute can (and probably should) > be used to represent both protocol-integer-id or protocol-string-id. > At least that is what I understood when you said "two separate attributes > for the same stuff". That's correct. :-) And pardon my worse then ever English: here in Italy we're at the end of a looong session of national feasts, and I'm a bit... confused. :-) > As regards the name of the attribute is the same name of the entity or not, Oh, that's not needed. I agree with you: it's better if entity != attribute. Again: the problem is what's a good name for the attribute? "name"? "type"? "kind"? > I tried to converge the efforts of several projects > (including DAXFi) in respect of achieving a single xml dialect for > firewalling. I did not received any response from that e-mail. > So I guess that is not going to happen. Who knows? Today, many projects are still in their first stages... Moreover, within a month or so, everyone will be watching world games of soccer: no one wants to start a new project _now_! ;-) > (DAXFi, by the way why the name?). Oh, well, it's quite embarrassing! :-) The very first release was not meant to be published, so that I named it "Davide Alberani Xml FIrewall". Nowadays I pretend it means "Dynamic Xml Firewall". Yes, the 'A' is still out for sale. ;-) > AFAIK, there is no such mapping for netfilter/iptables yet. Therefore, > I'm planning to take a shoot at it. There's another person that is writing a tool to configure a firewall (in Ruby) with XML; you can contact him at: pj...@pc... > So I study netfilter/iptables a bit further, study > DAXFi dtd (thx for publishing it!) and when ready I submit it here > for us to discuss. What do you think ? That's ok for me. Every discussion is welcome. > > Again: there are (at least) two ways to describe firewall specific > > portionsections: for every firewall you can define what tags/attributes > > are allowed e.g.: > > <firewall_dependent compatible="iptables"> > > <mac mac-source="XX:XX:XX:XX:XX:XX" /> > > ... > > </firewall_dependent> > > I prefer this one. Me too. > I'm planning to build them in Python. Even though DAXFi is more comprehensive > than that (multiple firewall targets), I offer to discuss such tools here and > if you like to add them under DAXFi umbrella. Certainly! Take a look at the 'README.daxfiPackage' (and at the library reference in the lib/ directory); maybe you can use it to develop your applications. Thank you again for your help, -- (=---= alb...@li... =------------= PGP KeyID: 0x465BFD47 =--=) ) Davide Alberani ( (=--= http://digilander.iol.it/alberanid/ =-= ICQ UIN: 83641305 =--=) |
|
From: Rodrigo S. <rod...@gp...> - 2002-05-02 18:12:10
|
|On Wed, 1 May 2002 11:07:07 +0200 |Davide Alberani <alb...@li...> wrote | about Re: [DAXFi-devel] About XML DTD - actions shouldn't be different from rules ?: > > > I think "id" is not enough descriptive: what about "name", "kind" > > > or "type"? > I like the "kind" word. :-) That's very kind of you. ;o) > > In this case, should we use the same attribute used by name, or a different > > one ? > > IMHO, using the same attribute is much better: it's easier to teach, > learn, remember and understand. Moreover two separates attributes for > the same stuff will create _many_ problems in the code (e.g.: comparing > two XMLs). Ok. I do agree with you that a single attribute can (and probably should) be used to represent both protocol-integer-id or protocol-string-id. At least that is what I understood when you said "two separate attributes for the same stuff". As regards the name of the attribute is the same name of the entity or not, well I guess that is pretty much stylistic. So, even though I prefer names where entity!=attribute, I can live with and accept ypur argument. =) > > We could have slightly modified DTD's depending on the backend ? > > I don't like this, but I suppose that DAXFi can continue using > the common part of the DTD, ignoring the others. Well, as you have seen. I tried to converge the efforts of several projects (including DAXFi) in respect of achieving a single xml dialect for firewalling. I did not received any response from that e-mail. So I guess that is not going to happen. > Anyway, if you begin mapping one specific firewall in a DTD, > you'll find that _almost everything_ is firewall-dependent. That is why I said that there should be different DTD's according to the chosen backend. But I do agree a single super-structure DTD would be better. The fact is I do not need firewall independence for the time being. I am focusing on netfilter/iptables for my immediate needs. > If you want a _really_ firewall-independent DTD In fact I don't, I was just trying to do things by the book. > Instead, in DAXFi [1], I've introduced even options that are present > in the majority of firewalls, that can be useful and/or that can be > ignored if a firewall doesn't support them. Python is my language of choice (whenever possible and adequate). So, that is why I contacted you (DAXFi, by the way why the name?). > I don't like the idea to put stateful inspection support only > in iptables/ipfilter-dependent sections. I guess coming up with a xml that precisely models netfilter/iptables (dependent) would be a already useful thing. Than, the same thing should be done to others. Only then the common denominator should be derived. I suggest that because I do not have enough expertise to factorize such features from scratch. AFAIK, there is no such mapping for netfilter/iptables yet. Therefore, I'm planning to take a shoot at it. I guess that could be integrated to DAXFi DTD (with a dependent section or not, but the idea is to be feature-rich). So I study netfilter/iptables a bit further, study DAXFi dtd (thx for publishing it!) and when ready I submit it here for us to discuss. What do you think ? > Again: there are (at least) two ways to describe firewall specific > portionsections: for every firewall you can define what tags/attributes > are allowed e.g.: > <firewall_dependent compatible="iptables"> > <mac mac-source="XX:XX:XX:XX:XX:XX" /> > ... > </firewall_dependent> I prefer this one. Since it is dependent, better to keep it simple. Moreover, we could skip the dependent entity all together. You see, a specific configuration tool for netfilter/iptables would read the xml-config-file and accept what makes sense and ignores the rest. Much like what is done with html content. So, I think it suffices to add the features, and let the tools decide what would be translated and what discarded. > [1] to tell all the truth: DAXFi is not the bible. :-) Amem. > It's just my overgrown pet project: it never meant to be a > well designed/well engineered program. > I've used (and I'm still using) it to play with Python and > XML, mostly. Well, I guess I want to play along. =) I do also want to exercise XML in Python. But I have a specific goal. I want to create a xml-like syntax to setup netfilter/iptables, and tools to read/write such syntax. Moreover, I'd like to manage netfilter/iptables remotely. All these tools I'm planning to build them in Python. Even though DAXFi is more comprehensive than that (multiple firewall targets), I offer to discuss such tools here and if you like to add them under DAXFi umbrella. best regards, Senra -- Rodrigo Senra MSc Computer Engineer (GPr Sistemas Ltda) rod...@gp... http://www.ic.unicamp.br/~921234 (LinUxer 217.243) (ICQ 114477550) |
|
From: Davide A. <alb...@li...> - 2002-05-01 09:07:59
|
On Apr 29, Rodrigo Senra <rod...@gp...> wrote:
> Wouldn't it be nice to keep the current DTD (or a complex enough example)
> of the current XML syntax in DAXFi home page.
Done.
> > I think "id" is not enough descriptive: what about "name", "kind"
> > or "type"?
>
> Indeed, "name" is better for a string form like 'tcp' . Then I ask,
> can we specify protocol by number (using 6 instead of tcp) ?
I like the "kind" word. :-)
> In this case, should we use the same attribute used by name, or a different
> one ?
IMHO, using the same attribute is much better: it's easier to teach,
learn, remember and understand. Moreover two separates attributes for
the same stuff will create _many_ problems in the code (e.g.: comparing
two XMLs).
> > <ruleset>
> > <append>
> > <rule a1></rule a1>
> > <rule a2></rule a2>
> > ...
> > </append>
> > <delete>
> > <rule d1></rule d1>
> > <rule d2></rule d2>
> > ...
> > </delete>
> > ...
> > </ruleset>
>
> To carry on with your example, the above is a <ruleset> or a <actionset> ?
True: "actionset" is much better.
> > - the "limit" tag is used only by iptables.
>
> We could have slightly modified DTD's depending on the backend ?
I don't like this, but I suppose that DAXFi can continue using
the common part of the DTD, ignoring the others.
Anyway, if you begin mapping one specific firewall in a DTD,
you'll find that _almost everything_ is firewall-dependent.
If you want a _really_ firewall-independent DTD you need the
greatest common divisor amongst the firewalls you choose to
support: IP addresses, port/protocol numbers, a target (drop,
accept, etc.) and not much more. Everything else is more or
less firewall-dependent.
Instead, in DAXFi [1], I've introduced even options that are present
in the majority of firewalls, that can be useful and/or that can be
ignored if a firewall doesn't support them.
E.g.: in DAXFi I've defined the "log-facility" attribute, in the
log tag; only some firewall can use this information, the others
simply ignore it.
On the other hand, the stateful inspection is really useful (and,
in my opinion, it is a feature that _must_ be present in my
"abstract/ideal firewall"); firewalls without support for it write
an error message in the logs and return an empty string.
I don't like the idea to put stateful inspection support only
in iptables/ipfilter-dependent sections.
To summarize: firewall-dependent DTD are acceptable to me, but only
if the common section is _really_ feature rich (mapping my
"ideal firewall", that doesn't have _everything_, but only _every
important feature_)
Again: there are (at least) two ways to describe firewall specific
portionsections: for every firewall you can define what tags/attributes
are allowed e.g.:
<firewall_dependent compatible="iptables">
<mac mac-source="XX:XX:XX:XX:XX:XX" />
...
</firewall_dependent>
where you have to define that the "mac" tag and the "mac-source"
attribute are acceptable for iptables, or you can use a generic
syntax like:
<firewall_dependent compatible="iptables">
<option name="TheName" value="TheValue" />
<option name="AnotherName" value="AnotherValue" />
<option name="mac-source" value="XX:XX:XX:XX:XX:XX" />
...
</firewall_dependent>
I'm still investigating pros and cons of these designs.
+++
[1] to tell all the truth: DAXFi is not the bible. :-)
It's just my overgrown pet project: it never meant to be a
well designed/well engineered program.
I've used (and I'm still using) it to play with Python and
XML, mostly.
--
(=---= alb...@li... =------------= PGP KeyID: 0x465BFD47 =--=)
) Davide Alberani (
(=--= http://digilander.iol.it/alberanid/ =-= ICQ UIN: 83641305 =--=)
|
|
From: Rodrigo S. <rod...@gp...> - 2002-04-29 14:17:51
|
Hi,
Following the immediate contact between WallFire and DAXFi,
I guess focusing in the intersection would be more procdutive ;p)
From WallFire : "The goal of the WallFire project is to build a
very general and modular firewalling application
based on Netfilter or any kind of low-level framework.
It will enable to manage every aspect of a firewall
administration, from configuration to monitoring,
intrusion detection, etc..."
From DAXFi : "DAXFi is a Python package that helps configure several
different kinds of firewalls in a consistent way."
From PCXFirewall: "The PCX Firewall is a perl script that generates a
customized shell script to start, stop and restart the
IPTables based firewall. You can build a MULTI-homed
system or a Standalone system. DNAT, SNAT, Redirection,
Blocking, etc. are all supported."
From FirewallBuilder: "Firewall Builder consists of an object-oriented GUI
and a set of policy compilers for various firewall
platforms. In Firewall Builder, a firewall policy is a
set of rules; each rule consists of abstract objects that
represent real network objects and services
(hosts, routers, firewalls, networks, protocols).
Firewall Builder helps users maintain a database of objects
and allows policy editing using simple drag-and-drop
operations. Preferences and object databases are
stored in XML format."
Intersection ---> Firewall independent configuration <-----
---> Both projects focusing on XML technology <---
Moreover, I'm under the impression that these projects (there might be
others) are aiming at any firewalls but are slightly favouring
netfilter/iptables ? ;P) (No criticism here, just searching common grounds)
Specially because to do just the intersection is already a very huge and
hairy task, I think we can benefit here from mutual effort/knowledge.
Furthermore, achieving a common XML configuration dialect would only
stenghten these projects and draw attention to themselves.
Each project could always develop its own cfg scheme and them cook
translators. I'm taking all this trouble to avoid precisely that, to
avoid waste of energy. So far I mentioned 3 projects: That means to
implement 6 binary translators, or an all-purpose translator with 3
parses, 3 generators and a intermediate representation format, right ?
If we come with such intermediate representation format from start everybody
wins !
Therefore, focusing in the common goal:
The definition of a XML (DTD or schema) to configure different firewall
engines, either at bootstrap or incrementally.
I have some questions I'd like to ask you project managers/developers:
1) Do you think it is worth to pursue such goal together or independently ?
2) If you've answered the previous question affirmatively =),
what is the suggested approach to carry on:
a) set up an independent mailing list ?
b) forward the discussion to all project mailing lists involved ?
c) offspring a sub-project ?
Thank you all very much for your attention.
best regards
Rod Senra
--
Rodrigo Senra
MSc Computer Engineer (GPr Sistemas Ltda) rod...@gp...
http://www.ic.unicamp.br/~921234 (LinUxer 217.243)
|
|
From: Rodrigo S. <rod...@gp...> - 2002-04-29 13:03:17
|
|On Sat, 27 Apr 2002 13:34:45 +0200
|Davide Alberani <alb...@li...> wrote
| about Re: [DAXFi-devel] About XML DTD - actions shouldn't be different from rules ?:
Thanks Davide for your promptly response.
> I'll prefer to have a XML easy to be
> handwritten (or at least read) by a human.
That is indeed desirable.
> It would be nice to have a single DTD, but right now the DTD
> of DAXFi needs many changes.
Wouldn't it be nice to keep the current DTD (or a complex enough example)
of the current XML syntax in DAXFi home page. Therefore, people could
drop by, check it out, and then comment about it in the list ?
> Maybe, one day, there will be a XSL to convert amongst formats.
Yes, historically translation has proved to be more feasible than consensus.
> I think "id" is not enough descriptive: what about "name", "kind"
> or "type"?
Indeed, "name" is better for a string form like 'tcp' . Then I ask,
can we specify protocol by number (using 6 instead of tcp) ?
In this case, should we use the same attribute used by name, or a different
one ?
> But you can write something like:
> <ruleset>
> <append>
> <rule a1></rule a1>
> <rule a2></rule a2>
> ...
> </append>
> <delete>
> <rule d1></rule d1>
> <rule d2></rule d2>
> ...
> </delete>
> ...
> </ruleset>
To carry on with your example, the above is a <ruleset> or a <actionset> ?
>
> Removing the "ruleset" enclosed in the action tag.
> Some action requires no more than one rule definition,
Indeed, actions should not force a sub-tag ruleset that would be
annoying in single-rule situations.
> Only <tcp />, <udp /> and <icmp /> are valid tags: <8 /> to describe
> egp is not accepted.
> Internally they are converted to the format: <target target='accept' />
> Using this syntax (or <target kind="accept" /> or <target id="accept" />)
> in user-defined XML would only simplify the code. :-)
Yes, you're right. Point taken.
> One exception: the "reject-with" attribute is only valid within a
> "reject" tag.
>
> The new syntax would be:
> <target>
> <reject reject-with="tcp-reset" />
> </target>
>
> Oh, well, this example opens just another can of worms:
> in theory the "tcp-reset" value must be used only if the protocol
> is "tcp", but honestly right now I prefer to completely ignore
> this fact... :-)
Maybe, there is a way in the DTD to tie 'tcp-reset' with the alias tag
<tcp> ? But I am not certain if this would not be a dirty hack.
> While, for other protocols:
> <protocol kind="egp" />
> Or:
> <protocol kind="8" />
>
> Obviously this makes necessary some internal conversion to an
> homogeneous "style", so that DOM can be compared easily.
IMHO, different things should be different. So,
<protocol name="egp" id="8">
and to ensure validity 'protocol [name|id]'.
> There are many other open issues; from the TODO:
> - the "limit" tag is used only by iptables.
We could have slightly modified DTD's depending on the backend ?
I'll have to study XML spec by DTD or by XMLSchema to learn the
alternatives better.
> - "set-policy" is meaningless with ipfilter.
Same case as before: backend dependent settings. A quick&dirty
solution would be to create a section something like:
<firewall_dependent>
<ruleset compatible="iptables">
<set-policy ....> /* whatever */
</ruleset>
</firewall_dependent>
All of it could be inserted in a action. The tool using the XML db could
skip or treat <firewall_dependent> sections.
> - the "state" tag (for stateful inspection) can be merged in the
> "protocol" tag, since it contains just an attribute.
Yep.
> - I don't know if the actual design for NAT is good: I only use
> NAT for very basic situations...
I took a peek at xmlrules.html, but I really have to study further
before saying something useful here ;o)
My interest in such a XML-interchange-format is to accomplish a format
that serves a two fold purpose:
1) Serve as static/persistent configuration for a firewall.
2) Serve as the common language to configure such firewall remotely.
To my needs independence is desirable but not indispensable ;o)
> Thank you for your support,
You're welcome. Hope I can be of any help in the future.
regards,
Senra
--
Rodrigo Senra
MSc Computer Engineer (GPr Sistemas Ltda) rod...@gp...
http://www.ic.unicamp.br/~921234 (LinUxer 217.243) (ICQ 114477550)
|
|
From: Davide A. <alb...@li...> - 2002-04-27 11:35:41
|
On Apr 26, Rodrigo Senra <rod...@gp...> wrote:
> First of all congratz on this project.
Thanks! :-)
As you can see, the project is under heavy development: the code
(both Python and C) is quite ugly, and many things are needed.
Oh, and pardon my poor English...
> I was unable to find any effort to standardize a XML DTD to describe
> firewall rules. I know for a fact that project 'Firewall Builder' has
> a xml config file.
Yes. AFAIK the XML of fwbuilder is really complex and contains many
tags/attributes only used by the program/parser and, moreover, it's
firewall-dependent. I'll prefer to have a XML easy to be
handwritten (or at least read) by a human.
> And that project 'WallFire' is on the verge of cooking
> one too.
I don't know this project (Searching with google ... ok, downloading)
> Wouldn't it be nice to gather uo people from every major project
> and try to come up with some common dtd ?
Sure! Unfortunately, as said before, DAXFi is still quite
immature and there are many differences in these projects.
It would be nice to have a single DTD, but right now the DTD
of DAXFi needs many changes.
Maybe, one day, there will be a XSL to convert amongst formats.
> 1) Instead of <protocol protocol='' .../> wouldn't it be more explicit
> (and elegant) something like <protocol id='' .../>, same applies to
> all tags that have identical attributes ?
Yes. Probably almost every "special case" (<drop />, <accept />, etc.)
I've defined must disappear: they are useful writing XML, but they
complicate the code.
I think "id" is not enough descriptive: what about "name", "kind"
or "type"?
> 2) Action tags define rules within themselves with attributes. I would
> rather see rules as independent tags.
Good idea.
This is also useful managing "strange" attributes like "rule-number",
that aren't really part of a rule.
> So If I had to manipulate some
> ruleset, I would just need to enclosed it in a different action tag
> without touching the ruleset itself. Example:
>
> <append>
> <ruleset>
> <rule chain='input' source-ip='127.0.0.1/8' interface='ppp0'>
> </ruleset>
> </append>
A small flaw: with this design you can't mix, in a single XML file,
different action tags.
But you can write something like:
<ruleset>
<append>
<rule a1></rule a1>
<rule a2></rule a2>
...
</append>
<delete>
<rule d1></rule d1>
<rule d2></rule d2>
...
</delete>
...
</ruleset>
Removing the "ruleset" enclosed in the action tag.
Some action requires no more than one rule definition, but this can
be forced with the DTD.
> 3) In a rule such as the one below:
>
> <replace source-ip='1.2.3.4' chain='input' rule-number='2'>
> <udp />
> <accept />
> </replace>
>
> The xml layout does not carry the information that udp is a protocol
> and that accept is an 'action'. IMHO, this should be more descriptive.
> Obviously UDP is a protocol, but things like merit-inp or leaf-1 wouldn't
> be so obvious, not mention the use of their respective numbers.
Only <tcp />, <udp /> and <icmp /> are valid tags: <8 /> to describe
egp is not accepted.
> Something similar could be done to accept,drop, reject cases too.
Internally they are converted to the format: <target target='accept' />
Using this syntax (or <target kind="accept" /> or <target id="accept" />)
in user-defined XML would only simplify the code. :-)
One exception: the "reject-with" attribute is only valid within a
"reject" tag.
The new syntax would be:
<target>
<reject reject-with="tcp-reset" />
</target>
Oh, well, this example opens just another can of worms:
in theory the "tcp-reset" value must be used only if the protocol
is "tcp", but honestly right now I prefer to completely ignore
this fact... :-)
> Then, I'd suggest using something wrapping it in a protocol tag:
> <protocol>
> <tcp syn-only='no' source-port='! 123:239' />
> </protocol>
That's ok.
For "special" protocols:
<protocol>
<icmp icmp-type="3/1" />
</protocol>
While, for other protocols:
<protocol kind="egp" />
Or:
<protocol kind="8" />
Obviously this makes necessary some internal conversion to an
homogeneous "style", so that DOM can be compared easily.
There are many other open issues; from the TODO:
- the "forward" chain is firewall-dependent: the behavior changes in
ipchains and iptables, and is completely absent in ipfilter...
- the "limit" tag is used only by iptables.
- "set-policy" is meaningless with ipfilter.
- the "state" tag (for stateful inspection) can be merged in the
"protocol" tag, since it contains just an attribute.
- I don't know if the actual design for NAT is good: I only use
NAT for very basic situations...
Other issues are more code-related, and can be ignored defining the DTD.
Thank you for your support,
--
(=---= alb...@li... =------------= PGP KeyID: 0x465BFD47 =--=)
) Davide Alberani (
(=--= http://digilander.iol.it/alberanid/ =-= ICQ UIN: 83641305 =--=)
|
|
From: Rodrigo S. <rod...@gp...> - 2002-04-26 18:11:59
|
Hi,
First of all congratz on this project. It is supposed to do
exactly what I need to do myself, generate XML intermediate file
and process it to generate firewall rules (netfilter/iptables).
Moreover, doing it in Python.
So I'll bother you people a little bit about it from now on ;o)
First question:
I was unable to find any effort to standardize a XML DTD to describe
firewall rules. I know for a fact that project 'Firewall Builder' has
a xml config file. And that project 'WallFire' is on the verge of cooking
one too. Wouldn't it be nice to gather uo people from every major project
and try to come up with some common dtd ?
Some initial comments on DTD layout:
1) Instead of <protocol protocol='' .../> wouldn't it be more explicit
(and elegant) something like <protocol id='' .../>, same applies to
all tags that have identical attributes ?
2) Action tags define rules within themselves with attributes. I would
rather see rules as independent tags. So If I had to manipulate some
ruleset, I would just need to enclosed it in a different action tag
without touching the ruleset itself. Example:
<append>
<ruleset>
<rule chain='input' source-ip='127.0.0.1/8' interface='ppp0'>
</ruleset>
</append>
instead of (from daxfi docs):
<ruleset>
<append chain='input' source-ip='192.168.1.0/24'>
<tcp />
<accept />
</append>
</ruleset>
If I'm using a DOM tree representation, the former is more flexible
to transform than the later, isn't it ? I could change the action
of whole ruleset just wrapping the ruleset sub-tree in a different action
tag ? Another argument, is that actions are more transient than rules.
3) In a rule such as the one below:
<replace source-ip='1.2.3.4' chain='input' rule-number='2'>
<udp />
<accept />
</replace>
The xml layout does not carry the information that udp is a protocol
and that accept is an 'action'. IMHO, this should be more descriptive.
Obviously UDP is a protocol, but things like merit-inp or leaf-1 wouldn't
be so obvious, not mention the use of their respective numbers. Therefore,
that could be replaced by the aforementioned <protcol id =''> tag.
Something similar could be done to accept,drop, reject cases too.
But this decision of made to allow xml validation in case of
<tcp syn-only='no' source-port='! 123:239' />
Then, I'd suggest using something wrapping it in a protocol tag:
<protocol>
<tcp syn-only='no' source-port='! 123:239' />
</protocol>
I'm no xml guru, so if my suggestion are flawed feel invited to
counter-argument =)
best regards
Senra
--
Rodrigo Senra
MSc Computer Engineer (GPr Sistemas Ltda) rod...@gp...
http://www.ic.unicamp.br/~921234 (LinUxer 217.243) (ICQ 114477550)
|
|
From: Adam S. <la...@sp...> - 2001-06-10 16:08:12
|
> CC to your address, since I don't know if the list is already active. looks like it is :) > In the attachments: > 1. daxfilib.py: a new version of daflib; I've found a little bug > writing dafishell. Sigh! > 2. dafishell: a small program that is an example of what you need, > at least partially. cool, i'll check it out. i just moved houses and dont' have dsl (ugg, dial up) or my home network setup yet (and i'm about to start a new job) so it's gonna take me a little while to get all setup for this. > I think you have to read the state from the running firewall any time > you need it, since you cannot trust your program (it can't know > anything about rules executed by the command line or other scripts). makes sense. > Oh, this is not implemented at the time, but I think this's not a > drama: it can be written in small time (last famous words...) ipchains had the ipchains-save command ... i assume that iptables hasa similar thing but i haven't looked into it. > daxfishell works in this manner: wow! right on! > I hope this behavior matches your needs. it looks like it, once i get my home network up i'll play with it and let you know for sure. > I think that it's quite easy, for someone that knows those tools (i.e. > not me :-) that's great. > I think that the 'limit' module of iptables isn't a good solution: > ipchains and other firewalls don't supports such option. ah, sorry i understand. use whatever took you think will work best, it doesn't matter to me so long as the end result works :) > Ok, if you know someone else enough crazy to be interested... :-) i'm working with anohter guy called terry. i'll send him mail and see if he wants to sign up. adam. |
|
From: Davide A. <alb...@bi...> - 2001-06-10 09:28:34
|
CC to your address, since I don't know if the list is already active. In the attachments: 1. daxfilib.py: a new version of daflib; I've found a little bug writing dafishell. Sigh! 2. dafishell: a small program that is an example of what you need, at least partially. On Jun 09, Adam Shand <la...@sp...> wrote: > > that'll work. what about saving state? I think you have to read the state from the running firewall any time you need it, since you cannot trust your program (it can't know anything about rules executed by the command line or other scripts). > is it possible to save the current state of firewall rules to a > file so it will survive reboots? Oh, this is not implemented at the time, but I think this's not a drama: it can be written in small time (last famous words...) > > The internal representation of a rule is a '*Rule' object, that > > contains an 'action' variable (e.g. 'append', 'delete', etc.), > > and a dictionary that describes the rule. > > gotcha ... I'm thinking about the future: in Python 2.0 there is DOM & SAX XML support; with this tools can be simple to store internal representation of rules in XML. > > E.g.: if you issue a 'blockhost' command, it's supposed that the > > script checks if this rule is already running. > > what happens if you issue a block command for a network that's > already blocked? i assume it's just silently dropped? daxfishell works in this manner: The first argument must be the 'command': actual choices are 'blocknet' and 'grantnet', the second argument is the IP number to block (can be an host name) with or without a netmask. When you issue a blocknet command daxfishell checks if 'similar' rules are already running: if an opposite rule (i.e. the same source-ip, but an 'accept' target) is found that rule is removed and then a 'drop' rule is run. If the opposite rule isn't found, if this rule is already running, a warning message is showed, otherwise the rule is executed. The same for grantnet. Example (with iptables): # -- first run. # daxfishell blocknet 1.2.3.4/8 iptables -I INPUT 1 -p 0 --source 1.0.0.0/255.0.0.0 -j DROP # -- try to run it again. # daxfishell blocknet 1.2.3.4/8 This rule is already running # -- now we want to give access to this IP. # daxfishell grantnet 1.2.3.4/8 iptables -D INPUT -p 0 --source 1.0.0.0/255.0.0.0 -j DROP iptables -I INPUT 1 -p 0 --source 1.0.0.0/255.0.0.0 -j ACCEPT I hope this behavior matches your needs. > i'd like to see the ability to support ipfilter and ipfw (or whatever > *bsd's firewall tool is these days). I think that it's quite easy, for someone that knows those tools (i.e. not me :-) > > * define the other tools: > > - iproute. - ... > > i'm not sure i understand this part? You also need to limit bandwidth for given subnets, right? What kind of tools are you using? I think that the 'limit' module of iptables isn't a good solution: ipchains and other firewalls don't supports such option. > > I've open a mailing list for the development of DAXFi: > > i've signed up. Ok, if you know someone else enough crazy to be interested... :-) -- (=--= alb...@bi... =-----------= PGP KeyID: 0x465BFD47 =--=) ) Davide Alberani ( (=--= http://digilander.iol.it/alberanid/ =-= ICQ UIN: 83641305 =--=) |