ipcop-devel Mailing List for IPCop Firewall

>>  Will the rc.firewall.up and associated files handle having an
>>  #include directive or something like it in them?
>
>Someone pointed out that these are shell scripts. That means you could
>end one shell script with a call to the next shell script...

I think he's asking for IPCop developers to provide a "hook" in the 
pre-installed scripts to a script that that a re-install won't 
over-write so that customizations can survive upgrades.

As I (vaguely) understand it, one of the goals for that XML-RPC-TLA 
thingie might be to handle this with a radically different 
solution...  Or maybe I'm vaguely not understanding that XML-RPC-TLA 
thingie, and this "hook" is a Good Idea (tm) IMNSHO.

Upgrading an unofficially patched SW is such a PITA I haven't even 
found time to switch to IPCop yet.  It took me hours (would have 
taken Mark W. minutes) to fix it so my stupid ISP filling my logs up 
all the time was cron-ed and logrotated off to another box...

At this point, I don't have minutes to spare, much less hours.

[OT]  If you like pop music that could loosely be described as:
"Johnny Cash on estrogen backed by the Rolling Stones rhythm section 
with Ani DiFranco lyrics", you may wish to listen to the webcast 
*TOMORROW* night at 7 pm CENTRAL time at http://dcn.com of the CD 
Release party for Ellen Rosner's "Count to 3" album ^H^H^H^H^H CD at:
http://dcn.com

You now know why I (the record label of said CD) have no minutes to spare :-)

Preview or even (gasp!) buy the CD at:
http://cdbaby.com/rosner2/
-- 
Got Music? http://l-i-e.com/artists.htm

At 05:09 PM 2/28/2002 +0000, Chris Priest wrote:
>To get more familiar with Linux development, I am going to try compiling
>IPCop from sources on my newly installed RH 7.2 box. Three questions:
>
>1. Is there any reason that Fixes 2 is not in the CVS repository or
>snapshot?

probably mark has not gotten around to submitting them and tagging an update.


>2. Are the updated snort rules from fixes 1 in CVS?

no.  Again, Mark's been too busy with 0.2


>3. Is there an easy way (a simple command) to keep a local copy of the
>CVS repository up to date with the master on Sourceforge? That is,
>download changes rather than the snapshots everyday.

cd <where ever your copy is>; cvs update

>I don't at this moment want to be an official developer as I have other
>stuff to do. Maybe later.

tsk tsk tsk...

;-)
---eric

To get more familiar with Linux development, I am going to try compiling
IPCop from sources on my newly installed RH 7.2 box. Three questions:

1. Is there any reason that Fixes 2 is not in the CVS repository or
snapshot?

2. Are the updated snort rules from fixes 1 in CVS?

3. Is there an easy way (a simple command) to keep a local copy of the
CVS repository up to date with the master on Sourceforge? That is,
download changes rather than the snapshots everyday.

I don't at this moment want to be an official developer as I have other
stuff to do. Maybe later.

Cheers,
Chris.

Hi,

A lot of you have offered to help on the v0.2 XML/RPC stuff (either on the C
side or the Java side) in the past.  Well, this really is the time to get
things going.

What do we have?
- A base system ISO with webserver and basic XML/RPC server
  http://prdownloads.sourceforge.net/ipcop/ipcop-20020227.iso
- A basic Java applet with HTML for managing everything, written by Toby
  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ipcop/IPCopJ/
- A basic API
  http://www.ipcop.org/cgi-bin/twiki/view/IPCop/IPCopXMLRpcApiv02
- A basic DTD for the configuration
  http://www.ipcop.org/cgi-bin/twiki/view/IPCop/IPCopXMLDtdv02

So, what do we need to do:
- API and DTD will be a work in progress during development and should be
open for discussion continuously (yes, in a perfect world, we'dd be making a
functional and technical design first, but hey, this is opensource ;-)
- Installer: make it write out the basic xml file (I'll take this)
- System side (in C): implement functions
- Java side: add Apache xml/rpc software, add Ant build script/packager,
design screen layouts, implement login screen on top of current stuff, etc.

So, who's willing ?  Please, checkout the sources from CVS, see what you can
do, where you can improve, tell us, and do it.

Gr,

        Mark

***************************************************************
* |\    /|      |  /|  /       Mark Wormgoor                  *
* | \  / |      | / | /        mailto:ma...@wo...       *
* |  \/  |ark   |/  |/ormgoor  http://www.wormgoor.com/mark/  *
***************************************************************

Dave,

>> In my setup at home, I include this line at the end of
>> /etc/rc.d/rc.firewall.up /etc/rc.d/rc.eth2
>>
>> This brings up my eth2, which is a private connection to my
>> neighbour.  When I upgrade, I just copy over my rc.eth2 and
>> add it to rc.firewall.up again.
>>

> Just wondering if you have any traffic shaping running on eth2?

Nope, no shaping.  But I only allow access to my local network, not the
internet.  He has his own ADSL line.  This is just for copying stuff we
really don't want to copy over 512/64.  He has an IPCop machine with the
same config.  Here's what it looks like (the driver used to be a separate
ne2000, but it's now a 3c509, which is already loaded by IPCop):
#!/bin/sh

# modprobe ne irq=5 io=0x320
ifconfig eth2 192.168.50.2 netmask 255.255.255.0 broadcast 192.168.50.255 up
route add -net 192.168.106.0 netmask 255.255.255.0 gateway 192.168.50.5

ipchains -D input -l
ipchains -A input -i eth2 -j ACCEPT
ipchains -A input -l

ipchains -D forward -l
ipchains -A forward -b -s 192.168.0.0/24 -d 192.168.50.0/24 -j ACCEPT
ipchains -A forward -b -s 192.168.0.0/24 -d 192.168.106.0/24 -j ACCEPT
ipchains -A forward -l

As you can see, my local net is 192.168.0.0/24, the middle net is
192.168.50.0/24 and his net is 192.168.106.0/24.  I delete the log targets
and add it back in, which saves me the trouble of counting lines.

Kind regards,

        Mark Wormgoor

Hi,

This is just one last notice that you really should subscribe to the ipcop-
announce mailinglist.  I am not sending announcements to ipcop-user or
ipcop-devel anymore.  Last Saturday, we released another fix (which fixes
an important vulnerability in Squid).  Only 919 people have downloaded the
fix today, which is 50% of the number of people who downloaded fix1
(1870).  So, what was the fix:

Size:    268039 (261,8KB)
MD5:     3b72c0a3bd7e26ed02c4028a4fddcbe0
Fixes: - Squid FTP vulnerability fixed
         (http://online.securityfocus.com/bid/4148)
       - Squid SNMP vulnerability fixed
         (http://online.securityfocus.com/bid/4146)
       - Squid HTCP vulnerability fixed
         (http://online.securityfocus.com/bid/4150)
       - Bug fixed where logrotate did not compress rotated logs

Kind regards,


       Mark Wormgoor
-- 
***************************************************************
* |\    /|      |  /|  /       Mark Wormgoor                  *
* | \  / |      | / | /        mailto:ma...@wo...       *
* |  \/  |ark   |/  |/ormgoor  http://www.wormgoor.com/mark/  *
***************************************************************

On Wednesday 27 February 2002 07:46 am, you wrote:

> I think Phil was thinking about something like that although I would
> personally do something little more general not unlike
>
> for i in /etc/rc.d/customrules/*fwr
> do
>          if [ -x $i ]; then
>                  source $i
>          fi
> done

I'm not at all interested in the specific details of how it gets 
integrated (I have no pet method to defend), but more interested in a 
clearly defined method of adding userland hacks that will get included 
in an upgrade automatically without being overwritten or lost, even in 
the event of reformatting/repartitioning the disk.

How that is accomplished can be any of dozens of methods, several of 
which have already been exposed. Having to dig modifications out of the 
middle of core code is difficult if not nearly impossible, so some 
other method needs to be adopted in the future. Our FAQ is suggesting 
that people modify files in ways that we have no way of honoring during 
upgrades.

A byproduct of this, if the naming convention is clearly defined, is 
that it makes it easy to locate and migrate any user mods to a new 
version even if the disk is going to be reformatted or repartitioned.

User makes mods following the rules, we follow the rules during upgrade 
and everyone is happy.

The next level would be to find out what those common hacks are and 
start integrating the most obviously useful ones into the UI, thus 
making the userland hacks unnecessary in the first place.

It seems that all are in agreement for some time of include mechanism would
be beneficial to ease any upgrade issues with user custom modifications.

Personally I like the 'for each file' approach as it would allow multiple
exit points within a module. This lends itself to supporting multiple
customization application features that could be added to the firewall,
which is a good thing. Ironically I deal with this approach with some legacy
software, and this is the best feature it has! It allows customers to
migrate to the latest versions transparently if they have followed the
'user-exit' rules - if they did not follow them source code re-integration
is required.

To use 'user-exits' (as they are called in my world) you have to follow the
rules, and also follow a naming scheme. All exits are clearly documented,
and have certain priviledges. So I could see a similar naming scheme in
IPCop:

FirewallUpB_bla  // User script 'bla' called at the beginning of the
firewall up script
FirewallUpE_bla2 // User script 'bla2' called at the End of the firewall up
script
FirewallDownS_bla3 //etc

Where bla is upto the user-exit writer to define, so to modify Eric's code:

for i in /etc/rc.d/customrules/FirewallUpB_*
do
         if [ -x $i ]; then
                 source $i
         fi
done

Each UE is defined by a name, and if you only add UE's you can be pretty
assured of a clean upgrade.

Gareth

----- Original Message -----
From: "Eric S. Johansson" <es...@ha...>
To: "Peter Walker" <pet...@st...>;
<ipc...@li...>
Sent: Wednesday, February 27, 2002 7:46 AM
Subject: Re: [IPCop-devel] #includes


> At 08:37 AM 2/27/2002 +0000, Peter Walker wrote:
> >Phil,
> >
> >I don't think you an do quite what you suggest but you can acheive the
> >same result
> >by checking if a file exists and is executable before running it.
> >
> >Eg.
> >if [ -x /etc/rc.custom ];then
> >     /etc/rc.custom
> >fi
> >
> >This is already used in a lot of init scripts. Similar stuff can be added
> >to the PERL
> >based legacy scripts if required.
>
> I think Phil was thinking about something like that although I would
> personally do something little more general not unlike
>
> for i in /etc/rc.d/customrules/*fwr
> do
>          if [ -x $i ]; then
>                  source $i
>          fi
> done
>
> --- eric
>
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

> -----Original Message-----
> From: Mark Wormgoor [mailto:ma...@wo...]=20
> Sent: 27 February 2002 12:47
> To: ipc...@li...
> Subject: Re: [IPCop-devel] #includes
[snip]

> In my setup at home, I include this line at the end of=20
> /etc/rc.d/rc.firewall.up /etc/rc.d/rc.eth2
>=20
> This brings up my eth2, which is a private connection to my=20
> neighbour.  When I upgrade, I just copy over my rc.eth2 and=20
> add it to rc.firewall.up again.
>=20

Just wondering if you have any traffic shaping running on eth2?

Regards,

Dave

Hi,

> > Will the rc.firewall.up and associated files handle having an
> > #include directive or something like it in them?
> >
> > If they could, it could lead to a customizable file that is never
> > overwritten with a patch, yet automatically included.
> >
> > That way, we would never modify the rc.firewall.up (etc), but the
> > rc.firewall.up.include file instead.
> >
> > Fresh installs would put out an empty copy of the include file,
> > upgrades would never touch it, and the original file would always
> > include a reference to the include file.
> >
> > I think this would lend itself well to further enhancements and
> > modifications by users and could make copying enhancements to a
> > floppy prior to a major upgrade simple. Go to /etc/rc.d and copy
> > *.include to the floppy. Copy it back after the upgrade.
> >
> > Thoughts?
>
> Someone pointed out that these are shell scripts. That means you could
> end one shell script with a call to the next shell script...

In my setup at home, I include this line at the end of
/etc/rc.d/rc.firewall.up
/etc/rc.d/rc.eth2

This brings up my eth2, which is a private connection to my neighbour.  When
I upgrade, I just copy over my rc.eth2 and add it to rc.firewall.up again.

Kind regards,

    Mark Wormgoor

At 08:37 AM 2/27/2002 +0000, Peter Walker wrote:
>Phil,
>
>I don't think you an do quite what you suggest but you can acheive the 
>same result
>by checking if a file exists and is executable before running it.
>
>Eg.
>if [ -x /etc/rc.custom ];then
>     /etc/rc.custom
>fi
>
>This is already used in a lot of init scripts. Similar stuff can be added 
>to the PERL
>based legacy scripts if required.

I think Phil was thinking about something like that although I would 
personally do something little more general not unlike

for i in /etc/rc.d/customrules/*fwr
do
         if [ -x $i ]; then
                 source $i
         fi
done

--- eric

On Wednesday 27 February 2002 01:22 am, you wrote:

> Will the rc.firewall.up and associated files handle having an
> #include directive or something like it in them?
>
> If they could, it could lead to a customizable file that is never
> overwritten with a patch, yet automatically included.
>
> That way, we would never modify the rc.firewall.up (etc), but the
> rc.firewall.up.include file instead.
>
> Fresh installs would put out an empty copy of the include file,
> upgrades would never touch it, and the original file would always
> include a reference to the include file.
>
> I think this would lend itself well to further enhancements and
> modifications by users and could make copying enhancements to a
> floppy prior to a major upgrade simple. Go to /etc/rc.d and copy
> *.include to the floppy. Copy it back after the upgrade.
>
> Thoughts?

Someone pointed out that these are shell scripts. That means you could 
end one shell script with a call to the next shell script...

Phil,

I don't think you an do quite what you suggest but you can acheive the same result
by checking if a file exists and is executable before running it.

Eg.
if [ -x /etc/rc.custom ];then
    /etc/rc.custom
fi

This is already used in a lot of init scripts. Similar stuff can be added to the PERL
based legacy scripts if required.

Cheers,

Pete.

Phil Barnett said:
>
> Will the rc.firewall.up and associated files handle having an #include  directive or
> something like it in them?
>
> If they could, it could lead to a customizable file that is never  overwritten with a
> patch, yet automatically included.
>
> That way, we would never modify the rc.firewall.up (etc), but the
> rc.firewall.up.include file instead.
>
> Fresh installs would put out an empty copy of the include file,
> upgrades would never touch it, and the original file would always  include a
> reference to the include file.
>
> I think this would lend itself well to further enhancements and
> modifications by users and could make copying enhancements to a floppy  prior
to a
> major upgrade simple. Go to /etc/rc.d and copy *.include to  the floppy. Copy it
back
> after the upgrade.
>
> Thoughts?
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

Will the rc.firewall.up and associated files handle having an #include 
directive or something like it in them?

If they could, it could lead to a customizable file that is never 
overwritten with a patch, yet automatically included.

That way, we would never modify the rc.firewall.up (etc), but the 
rc.firewall.up.include file instead.

Fresh installs would put out an empty copy of the include file, 
upgrades would never touch it, and the original file would always 
include a reference to the include file.

I think this would lend itself well to further enhancements and 
modifications by users and could make copying enhancements to a floppy 
prior to a major upgrade simple. Go to /etc/rc.d and copy *.include to 
the floppy. Copy it back after the upgrade.

Thoughts?

On Wed, 27 Feb 2002, BullBar wrote:

> Hi I am a current user of Smoothwall GPL, but I want to move to IPCop. But
> to do so IPCop needs to support ISDN DOV (Data Over Voice). Smoothwall DOV
> support is via a patch, is there a similar patch for IPCop, or better yet,
> is it supported without a patch?

Seeing as how Smoothwall and IPcop are still pretty close, there is at
least some chance the patches for Smoothwall will work on IPcop.

> I have am currently using an internal ISDN modem (Traverse Technologies
> NetJet card) in a Celeron-300 with 64MB ram.
>
> I look forward to hearing from someone that can answer my query, I have
> searched through the IPCop website but have been unable to find any
> indication of whether DOV is supported.

Judging from the Traverse Tech web site, they are mostly interested in
selling the ISDN hardware. They have a Linux page and point people to the
Smoothwall GPL pages.  Have you talked to them about supporting IPcop?
(Perhaps replacing the Smoothwall GPL references with IPcop?).


Joe Matuscak
Rohrer Corporation
717 Seville Road
Wadsworth, Ohio 44281
(330)335-1541
mat...@ro...

Hi I am a current user of Smoothwall GPL, but I want to move to IPCop. But
to do so IPCop needs to support ISDN DOV (Data Over Voice). Smoothwall DOV
support is via a patch, is there a similar patch for IPCop, or better yet,
is it supported without a patch?

I have am currently using an internal ISDN modem (Traverse Technologies
NetJet card) in a Celeron-300 with 64MB ram.

I look forward to hearing from someone that can answer my query, I have
searched through the IPCop website but have been unable to find any
indication of whether DOV is supported.

Regards,

BullBar

Sounds easy enough...


So, why not do it in a Java applet?  It's a lot easier to secure the
client,
it's a lot easier to secure IPCop (saves a lot of packages on the
firewall)
and it's platform independent.  Toby Coleridge is already writing a
basic
framework which we can expand on.  I'm hoping to check it into CVS in
the
next couple of days.  We'll be using Apache XML-RPC on the Java side:
http://xml.apache.org/xmlrpc/

Kind regards,

    Mark Wormgoor

Hi,

> I noticed a request for Java programmers on the MARC archive.  I have
> just subscribed to this list, as I have a fair bit of experience with
> java, and would like to help out.  What exactly are you looking for?

Ok, let me explain some more about the plans for v0.2.  The plan is to make
v0.2 manageable through xml/rpc (http://www.xmlrpc.com/).  This separates
the interface from the actual firewall management.  Since xml/rpc can be
accessed from everywhere (well, limited by authentication, firewall rules,
etc) over SSL, there is no reason for the interface to be on the box.  I'm
hoping people will write interfaces for KDE, GTK, PHP, Windows, etc. in the
future.  I was initially planning to do the first interface in perl/cgi and
run it from the IPCop box.  However, since the referer security problem, I
have been investigating how to create a highly secured webinterface.  It
turns out it's very difficult, requires a lot of Perl modules to be
installed and basically adds a lot of stuff to the box that I don't want
there.

So, why not do it in a Java applet?  It's a lot easier to secure the client,
it's a lot easier to secure IPCop (saves a lot of packages on the firewall)
and it's platform independent.  Toby Coleridge is already writing a basic
framework which we can expand on.  I'm hoping to check it into CVS in the
next couple of days.  We'll be using Apache XML-RPC on the Java side:
http://xml.apache.org/xmlrpc/

Kind regards,

    Mark Wormgoor

"parcel" <cp...@ad...> wrote

I noticed a request for Java programmers on the MARC archive.  I have 
just subscribed to this list, as I have a fair bit of experience with 
java, and would like to help out.  What exactly are you looking for?



Ditto for me...


 

Hi,
i managed, as a newcomer, to set up a VPN in the follow=EDng testbed:

host 10.20.30.1=3D=3D=3DLAN=3D=3D=3D10.20.30.2 ipcop 141.73.138.10 =
----LAN----
141.73.138.20 ipcop 20.30.40.2 =3D=3D=3DLAN=3D=3D=3D 20.30.40.1 host

I can establish a ftp-session between 10.20.30.1 and 20.30.40.1. and
transfer data.
The traffic between 141.73.138.10 and 141.73.138.20 is encrypted.

Here are my questions:=20
Why is the status of the connection CLOSED, when I'm looking for it, at =
the
Admin Web browser?
Is this correct?
Where is the source for the status-information?

tanks for help..
Eberhard

I noticed a request for Java programmers on the MARC archive.  I have 
just subscribed to this list, as I have a fair bit of experience with 
java, and would like to help out.  What exactly are you looking for?

-chris parson

Quick question for consideration -- 

It would seem a trivial task to also integrate a stronger reporting script 
for Snort alerts (i.e. SnortSnarf) into the web admin interface to make Snort 
more visible, and consequently more functional, on an IPCop gateway. As it 
stands, the logs from Snort via the existing web interface are a bit hard to 
manage, and very difficult to correlate. 

Another nicety would be a web interface to the logging configuration for 
Snort (for ex: allow configuration of an external mysql/pgsql db). Has any of 
this been considered for a future release?

./dr.kaos

On Wednesday 20 February 2002 02:43 am, Mark Wormgoor wrote:
> Hi,
>
> > Why not to merge Shoreline Firewall IPTables scripts with IPCop v0.2?
>
> Had already looked at it and am definitely considering it.  It seems to
> fill a lot of the gaps ;)
>
> Kind regards,
>
>      Mark Wormgoor

hey,

for those that tried to use the rules on my site
(http://fbsd.slydder.homelinux.com/stories/op/storiesView/sid/64/) to
"ALLOW" MSN traffic, I apologize.  There was a slight error in the
instructions that said to change "DENY" to "ALLOW" if you wanted to allow
access with IPChains.  It should have been "ACCEPT".  oops ;)

Also, the -b can be removed from the IPTables rules.  That was a cut-n-paste
error.

Thanks go out to Peter for bringing the "ALLOW" problem to my attention.

chuck

Hi,

> Why not to merge Shoreline Firewall IPTables scripts with IPCop v0.2?

Had already looked at it and am definitely considering it.  It seems to
fill a lot of the gaps ;)

Kind regards,

     Mark Wormgoor
-- 
***************************************************************
* |\    /|      |  /|  /       Mark Wormgoor                  *
* | \  / |      | / | /        mailto:ma...@wo...       *
* |  \/  |ark   |/  |/ormgoor  http://www.wormgoor.com/mark/  *
***************************************************************

Why not to merge Shoreline Firewall IPTables scripts with IPCop v0.2?