LINUX.IE, website of the Irish Linux Users' Group
Tux rules!

   
Home
New Users
Articles
Download
Projects
Community
Vendors

  Print Version
Email to...
 
Archives:


planetILUG

Recent News

News Archive


Join the
ILUG
on FaceBook


Join the
ILUG
on LinkedIn


Join the
ILUG SETI
Group



















 
 :: Mailing Lists

[CLUG] Web-based iptables administration

[CLUG] Web-based iptables administration

AJ McKee aj.mckee at druid-dns.com
Wed Feb 9 22:00:18 GMT 2005


Nice suggestion Peter,
I will setup a Wiki if we get enough people and a name for this thing so
people can add and remove docs, suggestions easily. I also will set up
version control. I would be reluctant for us to use Sourceforge as I
think its better if we actually have a project and some type of
deliverable done before going through that process as once its on
Sourceforge they never delete it. We all don't want to look like muppets
do we :) But thats just my opinion on that, I'll go with whatever
everyone else decides.

Okay I am sure there are people on this list who could kick my ass in
terms of coding up something in PHP and in software developement,
documentation etc, so please don't be shy and feel free to throw
something into this little discussion.

There are a couple of things for us to consider and/or have in our minds
while doing this as I see them anyhow.

1. Platform independance. - Its not really an issue. IPTables is largely
on Linux. boxes. PHP is too. That should not mean our code should be
messy either.
2. Database independance - I suggest using pearDB or Adodb for databse
connectionso we are not limiting ourselves to one type of database. Its
easoer as well as all the database stuff is then done dore us.
3. Documentation - All code should be well and properly coded, this is a
public project which other LUGS and people will see. Also it makes the
generation of documentation very easy. (Sorry I have gotten anal about
documentation about recently sorry if offends or is too autorative, its
not meant to be, just good docs eases up the way multiple developers can
work on something)
4. Set our base goals. For example how will IPtables know that a rule
has been changed? Are we going to run some type of Firewall Daemon and
message it with XML-RPC/SOAP when a change occurs? Or are we for version
X just going to rely on a perl/php script called from crond? See what I
am getting at? There is a lot we could do, so if we set out from the
start what we are doing, and where we are going, we won't get lost. E.G.
Version 0.1 provides X functionality, Version 0.2 x+y etc (sorry if
stating the obvious too  :)
5. As Adam and Peter have suggested, useability is a big driving factor!
Therefore its gota be simple. I suggest a PHP api that manages all the
rules and database stuff etc. By creating our own it also allows us to
modularise our code and add multiple frontends in the future perhaps, so
it don't just have to be web gui.

As you can see these are my opinions and therefore not applicable here
really. But they have helped me in the past and in the future. What I
would not like to see happen, is we spend ages talking about this and
never get it done. So I am with Adam in getting the thing started asap.
But I do thing we need base goals and some more thoughts like Peters.

Anyhow I have ranted long enough, 

Aj







On Wed, 2005-02-09 at 21:16 +0000, Peter Flynn wrote:
> On Wed, 2005-02-09 at 17:22, adam beecher wrote:
> > I'm pretty sure I've asked for this before, and I've searched Freshmeat
> > (eww) and SourceForge to no avail, so rather than asking - again - if the
> > Holy Grail exists, I'll wonder aloud: How come no-one's come up with a
> > web-based iptables configurator as simple as Plesk's? 
> 
> I've wanted this for ages because try as I may, I can't grok the
> fullness of iptables. What's needed is an interface that lets the
> admin say "I need to allow machine a.b.c.d receive NetMeeting calls"
> or "the machine a.b.c.d must be able to poll out to a timeserver",
> and not have to work out the port and the pathway by hand. Plus it
> should pop up a warning that "doing this will open you up to attack
> through port X, so I'll log all attempts to the console" or sumpn.
> It doesn't need to be cunning (that would be nice but inessential):
> it needs to be *sensible*. And it needs to know *all* the ports 
> that assorted weirdo software uses, so it needs to access a central
> repository of "program:port" data where authorised admins can add
> "hey I've found neato utility Foo which uses port 31415", so that
> dumb admins like me don't have to spend 42 days grepping weblogs
> for references to Foo to try and find what ports it uses. Or better,
> let the admin run a new program and the system will monitor the line
> for sudden new ports hits so you can see what's being requested.
> 
> Etc.
> 
> ///Peter
> 
> 
> _______________________________________________
> Cork mailing list
> Cork at linux.ie
> http://www.linux.ie/mailman/listinfo/cork




More information about the Cork mailing list
Read this without the formatting.
                                                                                                    

 

Hosted by HEAnet


Maintained by the ILUG website team. The aim of Linux.ie is to support and help commercial and private users of Linux in Ireland. You can display ILUG news in your own webpages, read backend information to find out how. Networking services kindly provided by HEAnet, server kindly donated by Dell. Linux is a trademark of Linus Torvalds, used with permission. No penguins were harmed in the production or maintenance of this highly praised website. Looking for the Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
RSS Version
Powered by Dell