ipcop-devel Mailing List for IPCop Firewall

Selon John Edwards <jo...@co...>:

> Hi
>
> All versions of Openswan appear to be vulnerable to a remote
> denial of service, where a packet from a remote attacker can
> cause the pluto IKE daemon to crash and restart:
> 	http://seclists.org/bugtraq/2009/Mar/0263.html
>
I have upgraded svn tree.

For 1.4, that trivial to backport demux patch to 1.0.10.
I have made that patch.

Unsure if we should upgrade from 1.0.10 to 2.4.14?
I have tried some time ago to upgrade openswan on 1.4 branch but failed.


Gilles

Hi

All versions of Openswan appear to be vulnerable to a remote
denial of service, where a packet from a remote attacker can
cause the pluto IKE daemon to crash and restart:
	http://seclists.org/bugtraq/2009/Mar/0263.html

--------
This bug affects the following software releases:

Current branches:

Openswan-2.6.20 and earlier
Strongswan-4.2.13 and earlier

Maintenance mode branches:

Openswan-2.4.13 and earlier
Strongswan-2.8.8 and earlier

End of Life branches:

Superfreeswan-1.9x
Openswan-1.x
Openswan-2.0.x - 2.3.1
Openswan-2.5.x

Everyone is strongly encouraged to upgrade to these minimum versions:

openswan-2.6.21
strongswan-4.2.14

openswan-2.4.14
strongswan-2.8.9

If you cannot upgrade to a new version, please apply the appropriate
patch as listed at http://www.openswan.org/CVE-2009-0790/ 
--------

-- 
#---------------------------------------------------------#
|    John Edwards   Email: jo...@co...    |
#---------------------------------------------------------#

On Monday 30 March 2009 07:00:51 am Arion Blishen wrote:
> Can an option be added to the Dialup page for entering the APN for 3G
> HSPA / GPRS connections rather than having to add the line below to the
> speaker off box under Modem ?
>
> AT+CGDCONT=1,"IP","<APN>"
>
> eg
>
> AT+CGDCONT=1,"IP","VirginBroadband"
> AT+CGDCONT=1,"IP","internet"
> AT+CGDCONT=1,"IP","telstra.bigpond"
> AT+CGDCONT=1,"IP","telstra.internet"
> AT+CGDCONT=1,"IP","vfinternet.au"
>
>
>

Might be convenient to have such a feature but you never did have to have it 
in the speaker section or otherwise separate from the main init string, AT 
only has to be passed once. For at least the last ten years, cellular modems 
have been able to take a single concatenated init string including the apn in 
the same line. The internet is full of clunky and outdated information on 
dialing with 'nix systems. Even the manufacturers themselves offer up a 
chatscript full of line breaks with OK after each individual AT per line. I 
would find it acceptable in 1985 but not now to do this. My init string when I 
use a 3G HSDPA modem is one line:

AT&F&D2&C1E0V1S0=0+CGDCONT=1,"IP","isp.cingular"
 
No need to over complicate this. For verbose logging, turn on debug. The worst 
scenario I dealt with was a Sony/Ericsson Edge modem that defaulted with the 
radio off. I still used a single init string even then: 

AT+CFUN=1+CREG=1&F&D2&C1E0V1S0=0+IFC=2,2+CGDCONT=2,"IP","internet3.voicestream.com"

CFUN turned on the radio in the above example. It never hurts to have a 
reference book of Hayes AT commands either.

Dave Studeman
http://www.raqcop.com

Can an option be added to the Dialup page for entering the APN for 3G 
HSPA / GPRS connections rather than having to add the line below to the 
speaker off box under Modem ?

AT+CGDCONT=1,"IP","<APN>"

eg

AT+CGDCONT=1,"IP","VirginBroadband"
AT+CGDCONT=1,"IP","internet"
AT+CGDCONT=1,"IP","telstra.bigpond"
AT+CGDCONT=1,"IP","telstra.internet"
AT+CGDCONT=1,"IP","vfinternet.au"

Eric Oberlander wrote:

> Watch out though, I can see the /sgraph directory is also mkdir'd in
> lfs/squid-graph
> 
> I'm guessing that the order in which the LFS scripts ran was(is) critical.

yes, noticed that, thanks.

OTOH, squid-graph is currently broke or better put: "does not work as 
intended", so no real concern (yet) ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

2009/3/29 Olaf Westrik <wei...@ip...>

> Eric Oberlander wrote:
>
>  I can see this on line 70 in lfs/ipcop-gui:
>>>>>
>>>>> chmod 755 /home/httpd/html /home/httpd/html/{index.cgi,images,include}
>>>>>
>>>>> But which script creates /graphs ?
>>>>>
>>>>> Eric
>>>>>
>>>> /usr/local/bin/makegraphs. Fortunately it is in perl so you can read it.
>>>>
>>>>  Oh, wait, I don't think that's what you meant. The graphs directory
>>> itself?
>>>
>>
>>
>> I've just found it in lfs/rrdtool
>>
>
> OK. Problem is that we do (and always have done, but in lfs/apache) this in
> lfs/ipcop-gui
> chmod -R 644 /home/httpd/html
>
>
> So with anything but a full rebuild, you might end up with 644 instead of
> 755 for graphs and sgraphs.
>
> I'll change that to create the grahps (and sgraphs) directory in
> lfs/ipcop-gui and remove it from lfs/rrdtool


Thanks Olaf

Watch out though, I can see the /sgraph directory is also mkdir'd in
lfs/squid-graph

I'm guessing that the order in which the LFS scripts ran was(is) critical.

Eric

Eric Oberlander wrote:

>>>> I can see this on line 70 in lfs/ipcop-gui:
>>>>
>>>> chmod 755 /home/httpd/html /home/httpd/html/{index.cgi,images,include}
>>>>
>>>> But which script creates /graphs ?
>>>>
>>>> Eric
>>> /usr/local/bin/makegraphs. Fortunately it is in perl so you can read it.
>>>
>> Oh, wait, I don't think that's what you meant. The graphs directory itself?
> 
> 
> I've just found it in lfs/rrdtool

OK. Problem is that we do (and always have done, but in lfs/apache) this 
in lfs/ipcop-gui
chmod -R 644 /home/httpd/html


So with anything but a full rebuild, you might end up with 644 instead 
of 755 for graphs and sgraphs.

I'll change that to create the grahps (and sgraphs) directory in 
lfs/ipcop-gui and remove it from lfs/rrdtool



Olaf

-- 

A weizen a day helps keep the doctor away.

2009/3/29 David W Studeman <avi...@ai...>

> David W Studeman wrote:
>
> > Eric Oberlander wrote:
> >
> >> 2009/3/29 David W Studeman <avi...@ai...>
> >>
> >>> Olaf Westrik wrote:
> >>>
> >>> > Eric Oberlander wrote:
> >>> >
> >>> >> I think the privileges on /home/httpd/html/graphs and sgraphs may be
> >>> >> wrong.
> >>> >>
> >>> >> I've just found that they are not executable.
> >>> >
> >>> > I see 755 on both graphs and sgraphs (and on backup, images and
> >>> > include as well)
> >>> >
> >>> >
> >>> > Olaf
> >>> >
> >>> I'm using a flash install and I see 755 as the permissions on both
> >>> folders in /ram.
> >>> --
> >>> Dave
> >>> http://www.raqcop.com
> >>
> >>
> >> I can see this on line 70 in lfs/ipcop-gui:
> >>
> >> chmod 755 /home/httpd/html /home/httpd/html/{index.cgi,images,include}
> >>
> >> But which script creates /graphs ?
> >>
> >> Eric
> >
> > /usr/local/bin/makegraphs. Fortunately it is in perl so you can read it.
> >
>
> Oh, wait, I don't think that's what you meant. The graphs directory itself?


I've just found it in lfs/rrdtool

Eric

David W Studeman wrote:

> Eric Oberlander wrote:
> 
>> 2009/3/29 David W Studeman <avi...@ai...>
>> 
>>> Olaf Westrik wrote:
>>>
>>> > Eric Oberlander wrote:
>>> >
>>> >> I think the privileges on /home/httpd/html/graphs and sgraphs may be
>>> >> wrong.
>>> >>
>>> >> I've just found that they are not executable.
>>> >
>>> > I see 755 on both graphs and sgraphs (and on backup, images and
>>> > include as well)
>>> >
>>> >
>>> > Olaf
>>> >
>>> I'm using a flash install and I see 755 as the permissions on both
>>> folders in /ram.
>>> --
>>> Dave
>>> http://www.raqcop.com
>> 
>> 
>> I can see this on line 70 in lfs/ipcop-gui:
>> 
>> chmod 755 /home/httpd/html /home/httpd/html/{index.cgi,images,include}
>> 
>> But which script creates /graphs ?
>> 
>> Eric
> 
> /usr/local/bin/makegraphs. Fortunately it is in perl so you can read it.
> 

Oh, wait, I don't think that's what you meant. The graphs directory itself?
-- 
Dave
http://www.raqcop.com

Eric Oberlander wrote:

> 2009/3/29 David W Studeman <avi...@ai...>
> 
>> Olaf Westrik wrote:
>>
>> > Eric Oberlander wrote:
>> >
>> >> I think the privileges on /home/httpd/html/graphs and sgraphs may be
>> >> wrong.
>> >>
>> >> I've just found that they are not executable.
>> >
>> > I see 755 on both graphs and sgraphs (and on backup, images and include
>> > as well)
>> >
>> >
>> > Olaf
>> >
>> I'm using a flash install and I see 755 as the permissions on both
>> folders in /ram.
>> --
>> Dave
>> http://www.raqcop.com
> 
> 
> I can see this on line 70 in lfs/ipcop-gui:
> 
> chmod 755 /home/httpd/html /home/httpd/html/{index.cgi,images,include}
> 
> But which script creates /graphs ?
> 
> Eric

/usr/local/bin/makegraphs. Fortunately it is in perl so you can read it.

-- 
Dave
http://www.raqcop.com

2009/3/29 David W Studeman <avi...@ai...>

> Olaf Westrik wrote:
>
> > Eric Oberlander wrote:
> >
> >> I think the privileges on /home/httpd/html/graphs and sgraphs may be
> >> wrong.
> >>
> >> I've just found that they are not executable.
> >
> > I see 755 on both graphs and sgraphs (and on backup, images and include
> > as well)
> >
> >
> > Olaf
> >
> I'm using a flash install and I see 755 as the permissions on both folders
> in /ram.
> --
> Dave
> http://www.raqcop.com


I can see this on line 70 in lfs/ipcop-gui:

chmod 755 /home/httpd/html /home/httpd/html/{index.cgi,images,include}

But which script creates /graphs ?

Eric

Olaf Westrik wrote:

> Eric Oberlander wrote:
> 
>> I think the privileges on /home/httpd/html/graphs and sgraphs may be
>> wrong.
>> 
>> I've just found that they are not executable.
> 
> I see 755 on both graphs and sgraphs (and on backup, images and include
> as well)
> 
> 
> Olaf
> 
I'm using a flash install and I see 755 as the permissions on both folders 
in /ram. 
-- 
Dave
http://www.raqcop.com

Eric Oberlander wrote:

> I think the privileges on /home/httpd/html/graphs and sgraphs may be wrong.
> 
> I've just found that they are not executable.

I see 755 on both graphs and sgraphs (and on backup, images and include 
as well)


Olaf

-- 

A weizen a day helps keep the doctor away.

> Hi
> I just did a clean install of 1.9.4, to confirm that the system and traffic
> graphs are not being displayed by graphs.cgi
> 
> I think the problem lies with permissions, and probably some setting within
> httpd.conf, since the change to Port 8443.
> There are error messages in the error_log about (13)Permission denied:
> access to /graphs/GREEN_1-day.png denied, referer ...
> 
> Can anyone else confirm the problem?
> 
> Eric

Yes I can confirm but I think it is up to the old thing with fcron in 
relation to the privileges and here specifically for root.orig and 
new.root files under /var/log/spool/cron.

Chris

2009/3/29 albe <de...@al...>

> Hi
>> I just did a clean install of 1.9.4, to confirm that the system and
>> traffic
>> graphs are not being displayed by graphs.cgi
>>
>> I think the problem lies with permissions, and probably some setting
>> within
>> httpd.conf, since the change to Port 8443.
>> There are error messages in the error_log about (13)Permission denied:
>> access to /graphs/GREEN_1-day.png denied, referer ...
>>
>> Can anyone else confirm the problem?
>>
>> Eric
>>
>
> Yes I can confirm but I think it is up to the old thing with fcron in
> relation to the privileges and here specifically for root.orig and new.root
> files under /var/log/spool/cron.
>
> Chris


Thanks Chris

I think the privileges on /home/httpd/html/graphs and sgraphs may be wrong.

I've just found that they are not executable.

Eric

Hi
I just did a clean install of 1.9.4, to confirm that the system and traffic
graphs are not being displayed by graphs.cgi

I think the problem lies with permissions, and probably some setting within
httpd.conf, since the change to Port 8443.
There are error messages in the error_log about (13)Permission denied:
access to /graphs/GREEN_1-day.png denied, referer ...

Can anyone else confirm the problem?

Eric

Bugs item #2719948, was opened at 2009-03-29 00:39
Message generated for change (Tracker Item Submitted) made by richardmorrison
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2719948&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: rm2010 (richardmorrison)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible security hole from Blue Zone

Initial Comment:
A wireless device on blue zone has been assigned a green zone ip-address via IPCop's fixed lease facility (in DHCP config page). That device now has access to all machines and services available on the green zone. I have not created any port forwards or DMZ pinholes etc.

Both blue and green zones have differing ip-address ranges in this installation.

This is my first IPCop installation so it is quite possible I have mis-configured my machine (and this may also be part of normal function).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2719948&group_id=40604

Was: Re: [IPCop-devel] [Ipcop-svn] special port


> Basically I am thinking about some 'infrastructure' to make installation /
> deinstallation of addons a little easier.
>
Say helper routines to add menu entry, fcron entry, language files,
> rc.local, rc.firewall.local, etc.
>

> But lets get some other things finished first ;-)
>

So when we get round to it, here's my design suggestion, for consideration
:)

00-000_system
00-100_home
00-200_scheduler
00-300_updates
...
00-900_credits
01-000_status
01-100_system_status
01-200_system_info
01-300_network_status
...
01-800_connections
02-000_network
02-100_dialup
02-200_upload
02-300_modem
02-400_aliases
03-000_services
03-100_proxy
03-200_dhcp_server
...

Where first 2 digits represents Mainmenu position, reserved by IPCop.
And second 3 digits represents position in Submenu.
000 indicates it's a Main Menu.
Text after first underscore would be a 'translation string'

Embed the string within each cgi, for example, within dhcp.cgi have:
# MENUCODE 03-300_dhcp_server

Or, for wireless.cgi, include a flag to indicate 'only display if a Blue NIC
is installed'
# MENUCODE 04-200_blue_access ifBlue

So by grepping the cgis you could generate the menus, from a script that
could run at startup, update, or on request.

Regards

Eric

>>> Granted, we currently also have difficulty replacing header.pl because
>>> of the addons that add themselves into the menu. However I have some
>>> ideas for this.
>>
>> What about giving the Addons Developers their own Menu, on the righthand
>> side after Logs?
>>
>> Somehow make it self-populating, so that Addons drop a file into a folder
>> that describes the Addon Name, and addon.cgi script, and on startup, or 
>> with
>> the aid of a helper suid program, the menus/submenus are added to 
>> header.pl,
>> or a seperate file that is 'included' within header.pl.
> 
> The SmoothWall developers have solved this a really smart way. SW3 has no 
> hardcoded menue at all. They have numbered folders instead for each menu and 
> in these folders you'll find numbered files containing a description and the 
> corresponding cgi file name.
> 
> Could be like this: /var/ipcop/menu/2000_Services/3000_dhcp
> 
> This file might have the content "DHCP Server:dhcp.cgi"
> 
> The range from 0000 to 9999 allows you to have 10000 menues with each 10000 
> menu items. So each developer may claim e.g. a "1337_foobar" for his addon.
> 
> No matter whether you want to add a new menu item or even a new menu 
> section. This way makes it much easier to maintain a menu item for addon 
> developers. And you don't have to touch header.pl at all. And future 
> header.pl replacements don't affect the existing menu structure in any way.
> 
> Simple, stable, flexible and easy to implement. As an addon programmer for 
> SmoothWall I like this transparent structure very much. No more broken 
> addons...

Something like that. And more, since there are several things that can 
break addons.

Basically I am thinking about some 'infrastructure' to make installation 
/ deinstallation of addons a little easier.
Say helper routines to add menu entry, fcron entry, language files, 
rc.local, rc.firewall.local, etc.

But lets get some other things finished first ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

I will commit a few enhancement to the installer on network install:
- with pxe boot (so x86 only), local IP, network interface and server IP
(supposed to be same as tftp server) are automaticly retrieved
- with dhcp discovery, I add a progress bar
- with manual selection, I am going to add a network interface selection and a
configure box.

I add too a simple ping test to check the local IP set is not already in use
somewhere in the network. It will currently only log the error. I should add an
error box later.

That should be commited this week end.

I should be able to commit the partitionning change (not yet fully tested).
I have made a simple script that may be reused on installed system to partition
a new disk.

What would need fixing next is manual selection of an undetected nic.
Then adding detection of isapnp card should not be hard (a simple grep isapnp
dmesg on boot >/tmp/isapnp is a good start to find wich nic are know by the
kernel)

Gilles

>> Granted, we currently also have difficulty replacing header.pl because
>> of the addons that add themselves into the menu. However I have some
>> ideas for this.
>
>
> What about giving the Addons Developers their own Menu, on the righthand
> side after Logs?
>
> Somehow make it self-populating, so that Addons drop a file into a folder
> that describes the Addon Name, and addon.cgi script, and on startup, or 
> with
> the aid of a helper suid program, the menus/submenus are added to 
> header.pl,
> or a seperate file that is 'included' within header.pl.

The SmoothWall developers have solved this a really smart way. SW3 has no 
hardcoded menue at all. They have numbered folders instead for each menu and 
in these folders you'll find numbered files containing a description and the 
corresponding cgi file name.

Could be like this: /var/ipcop/menu/2000_Services/3000_dhcp

This file might have the content "DHCP Server:dhcp.cgi"

The range from 0000 to 9999 allows you to have 10000 menues with each 10000 
menu items. So each developer may claim e.g. a "1337_foobar" for his addon.

No matter whether you want to add a new menu item or even a new menu 
section. This way makes it much easier to maintain a menu item for addon 
developers. And you don't have to touch header.pl at all. And future 
header.pl replacements don't affect the existing menu structure in any way.

Simple, stable, flexible and easy to implement. As an addon programmer for 
SmoothWall I like this transparent structure very much. No more broken 
addons...

Cheers, Marco 

2009/3/22 Olaf Westrik <wei...@ip...>

> Achim Weber wrote:
> > Olaf Westrik wrote:
> >
> >> To me there is no big difference between 222/8443 set directly in
> >> general-functions.pl or 222/8433 read from a configuration file.
> >
> > I think there is no need to have it in general-functions.pl or in a
> config file.
> > DataAcsess.pl reads the "IPCop Services" (parse httpd.conf, look for
> proxy port,
> > parse sshd_config etc.) so we can simple use this function on those
> places we
> > need to know the "reserved ports". Easy as is :-)
> >
> > Or I'm missing something?
>
> Yes. A config file is still a good thing to have, as Gilles pointed out.
>
> The GUI port is now more or less hardcoded in header.pl, which makes it
> somewhat difficult to update header.pl.
> Granted, we currently also have difficulty replacing header.pl because
> of the addons that add themselves into the menu. However I have some
> ideas for this.


What about giving the Addons Developers their own Menu, on the righthand
side after Logs?

Somehow make it self-populating, so that Addons drop a file into a folder
that describes the Addon Name, and addon.cgi script, and on startup, or with
the aid of a helper suid program, the menus/submenus are added to header.pl,
or a seperate file that is 'included' within header.pl.

--
Eric

Gilles Espinasse wrote:

> It's convenient to have the package recompiled each time one of the cgi is
> updated.
> This ensure we install lastest version each time.
> But apache compilation take some time.
> 
> Did you agree to move cgi installation from lfs/apache to misc-progs?
> This cut the compilation time by 6.
> 
> Or we could have a new lfs script just for cgi installation.
> That would be even more faster.

I agree to move CGI files the rebuilt of Apache can be annoying if you 
have to wait for it ...

My preference is to have a separate file for example ipcop-gui.


Olaf

-- 

A weizen a day helps keep the doctor away.

It's convenient to have the package recompiled each time one of the cgi is
updated.
This ensure we install lastest version each time.
But apache compilation take some time.

Did you agree to move cgi installation from lfs/apache to misc-progs?
This cut the compilation time by 6.

Or we could have a new lfs script just for cgi installation.
That would be even more faster.

Gilles

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Sunday, March 22, 2009 9:31 PM
Subject: Re: [IPCop-devel] [2.0] binutils/gcc/glibc


> Gilles Espinasse wrote:
>
> > We should first change how tests are run.
> > Instead of writing a log file name build from
> > $(DIR_TEST)/$(THISAPP)-$(STAGE_ORDER).log,
> > with DIR_TEST    = $(LFS_BASEDIR)/test_$(MACHINE)
> > we should add a DATE_TEST inside DIR_TEST path.
> > That DATE_TEST has to be calculated once on make.sh to not vary during
the
> > build and be passed to toolchain_make and chroot_make.
> >
> > That way, we could change one part in the toolchain build and diff the
> > effect on the full test log between two build|dates.
> > With our actual way to run tests, we can't keep previous log if the
package
> > version does not change. So we are only able to track a version change.
>
> Set a DATETIME at the beginning of make.sh? Something like
> BUILDDATE=`date +"%Y%m%d-%H%M%S"`
>
> Then we can just do DIR_TEST=$(LFS_BASEDIR)/test_$(MACHINE)/$(BUILDDATE)
> And can easily diff between builds.
>
> At the same time also store BUILDSTART=`date +"%s"`, so at the end of
> the build we can have some indication of time past.
>
>
> Olaf
>
ok for me.

Gilles