devil-linux-develop Mailing List for Devil-Linux (Page 314)

This email is to inform you of release '2.4.10' of 'Linux' through
freshmeat.net. All URLs and other useful information can be found at
http://freshmeat.net/projects/linux/

The changes in this release are as follows:


If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.

Sincerely,
freshmeat.net

http://www-106.ibm.com/developerworks/linux/library/l-fs3.html

-- 
MfG / Regards
Friedrich Lobenstock

This email is to inform you of release '1.2.3' of 'iptables' through
freshmeat.net. All URLs and other useful information can be found at
http://freshmeat.net/projects/iptables/

The changes in this release are as follows:
Fixes to ICMPv6 support for IPv6, fixes for problems with REJECT and
iptables-restore/iptables-save, a fix for a possible string overflow in
psd
match, fixes for string match compile problems, and incremental
checksumming when altering TTL in TTL target.

If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.

Sincerely,
freshmeat.net

This email is to inform you of release '2.4.9-ac14' of 'Linux' through
freshmeat.net. All URLs and other useful information can be found at
http://freshmeat.net/projects/linux/

The changes in this release are as follows:
Fixed atm alignment on IA64, soundblaster unload oops fix, and NFS over
tcp
fixes. Added usb zero packet flag support to OHCI, cleaned up reiserfs
flags usage, fixed reiserfs disk leak on crash case, fixed reiserfs mount
option handling, and made cosmetic reiserfs changes. Small fusion driver
update, added RAID1 support promise ide raid, removed duplicate DEC fb
config, and added AMD761 AGP. Fixed proc/pid/maps, fixed 8139too pio
problem, fixed SEM_UNDO wrap bug, and added xircom/entrega single port
USB.

If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.

Sincerely,
freshmeat.net

This email is to inform you of release '2.4.9-ac13' of 'Linux' through
freshmeat.net. All URLs and other useful information can be found at
http://freshmeat.net/projects/linux/

The changes in this release are as follows:
Fixes for mangled sun3fb bits and a make rpm version bug, a workaround for
an eepro100 bug with some chip versions on 10Mbit half duplex, sync'ing
UML
inlines with rest of kernel, UML memory protection code, cleanups to UML
rules, fixes for UML hang on xterm open fail, a UML signal handling bug,
and UML out of pty's on host error reporting, new tun/tap support in UML
and net code cleanups, a fix for UBD block driver to handle errors
properly, absolute backfile file paths in COW headers, and a fix for a
missing UML tlb flush.

If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.

Sincerely,
freshmeat.net

Bugs item #463188, was opened at 2001-09-20 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=410643&aid=463188&group_id=34096

Category: Package
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem with ipsec key generation

Initial Comment:
From Message Board:

I am using Devil Linux 0.44, and Freeswan is getting 
stuck when I try to generate an RSA key.  The command 
I am using is   ipsec rsasigkey --verbose 1024    
which gets stuck after saying     getting 64 random 
bytes from /dev/random.  I tried generating an RSA key 
on my main PC which also has ipsec on it, and it takes 
less than a minute to get a key back.  What can be 
done to fix this?  

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

Could be the /dev/random, because it is not 
initialized ?!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=410643&aid=463188&group_id=34096

Bugs item #461085, was opened at 2001-09-12 19:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=410643&aid=461085&group_id=34096

Category: Base System
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Heiko Zuerker (smiley73)
Summary: modutils in LFS 3.0RC2 is old

Initial Comment:
update modutils to v2.4.8

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=410643&aid=461085&group_id=34096

This email is to inform you of release '2.4.9-ac12' of 'Linux' through
freshmeat.net. All URLs and other useful information can be found at
http://freshmeat.net/projects/linux/

The changes in this release are as follows:
Yamaha audio wakeup race, 3c507 ring buffer handling, jffs_min compile
failure, USB serial startup, hid initialisation order, UML disk space
leak,
missing break in riva fbdev.c, oops in SCSI generic, hz_to_std macro
problem, radeon + AMD761 lockup/corruption problem fixed. UML hz_to_std(),
PWC driver update, Intermezzo update, and 4.4BSD alias syle ioctl bits
added. sysrq added to mconsole, dead 3c515 stuff removed, UML makefile and
hostfs cleaned, and spin_trylock_bh pushed into the headers. 

If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.

Sincerely,
freshmeat.net

This email is to inform you of release '2.4.9-ac11' of 'Linux' through
freshmeat.net. All URLs and other useful information can be found at
http://freshmeat.net/projects/linux/

The changes in this release are as follows:
This is just a resync as various people work to get most of -ac into Linus
2.4.10. Fixed sign check error in death signal, and merged up to Linus
2.4.10pre9.

If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.

Sincerely,
freshmeat.net

Feature Requests item #462142, was opened at 2001-09-16 19:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=410646&aid=462142&group_id=34096

Category: Package
Group: None
Status: Open
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: cron package

Initial Comment:
add a cron package to the system

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=410646&aid=462142&group_id=34096

Hi!

After some discussion with Heiko over ICQ I see that first there's need for
an in-deeper description. Second I have to make some corrections because we 
can not check links into the CVS.

I'd use the following filesystem hierarchy (in the LFS-system):
/build
/build/scripts                  ..... directory for the various scripts
/build/scripts/build              ... the build script that controlls all operations
/build/scripts/create_cd_dirs     ... the scripts
/build/scripts/unpack-src
/build/scripts/update-lfs
/build/scripts/openssl-0.9.6b     ... eg. compile/install openssl
/build/scripts/...
/build/scripts/functions          ... common functions for all scripts
/build/scripts/settings           ... common settings for all scripts
/build/scripts/...
/build/scripts/.config            ... the result of configuring
/build/scripts/config             ... configuration files for scripts have their own config files
/build/scripts/config/config_kernel
/build/scripts/config/config_tinylogin-0.60.1
/build/scripts/config/...         ... each package that is optional has a file here 
/build/scripts/config/package_squid     that tells the build process if this packages
/build/scripts/config/...               should be added to the CD
/build/scripts/copy_base
/build/scripts/copy_libs
/build/scripts/build            ..... (simulated) symlinks for build/compile process
/build/scripts/build/001unpack-src .. file containing at least one char (symlink simulation!)
/build/scripts/build/...                format of filename: [0-9]{3}NAME-OF-SCRIPT
/build/scripts/build/100openssl-0.9.6b  the number assures that the a scripts are
/build/scripts/build/...                called in the correct order
/build/scripts/build/...
/build/scripts/install          ..... (simulated) symlinks for install process
/build/scripts/install/001create_cd_dirs
/build/scripts/install/...
/build/scripts/install/100openssl-0.9.6b
/build/scripts/install/
/build/scripts/install/
/build/src/                     ..... source for all packages (incl. optional)
/build/src/gmp-3.1.1.tar.gz
/build/src/modutils-2.4.8.tar.bz2
/build/src/beep-1.2.1.tar.gz
/build/src/iptables-1.2.3.tar.bz2
/build/src/libol-0.2.23.tar.gz
/build/src/zlib-1.1.3.tar.gz
/build/src/busybox-0.60.1.tar.gz
/build/src/linux-2.4.9.tar.bz2
/build/src/openssl-0.9.6b.tar.gz
/build/src/hdparm-4.1.tar.gz
/build/src/cdrecord-1.9.tar.gz
/build/src/tinylogin-0.80.tar.gz
/build/src/...
/build/dist/                    ..... the final output
/build/dist/boot-cd-0.5b1.iso
/build/dist/etc.tar.gz
/build/tmp/                     ..... where all the compiling and preparing is done
/build/tmp/ISO/                 ... the preparations for the boot cd are made here


Now that the layout of the tree should be clear I want to explain 
the function of the scripts under /build/scripts:

* select optional packages
    build config
* one starts the build process with
    build build
* afterwards the CD is created with 
    build install

* do some housework and clean up behind us: 
    build clean


build config:
*************
  1) read directory listing /build/scripts/config/package_*
  2) read file .config 
  3) move .config to .config.old and create empty .config
  4) cycle through all scripts 
  4.1) displaying the user the contents of DESCRIPTION for package_xyz
  4.2) user decideds yes or no (defaults to yes if variable PACKAGE_xyz == "y")
  4.3) append PACKAGE_xyz=y to .config if users decision was yes
  
(see below for file formats)

build build:
************
  1) read directory listing from /build/scripts/build/
  2) execute all scripts in /build/scripts that have a corresponding
     file in /build/scripts/build/ following the order in /build/scripts/build/
     with the command line option $1="build" 
     ALSO a check for a corresponding file in /build/scripts/config/ is done.
     If this file exists and OPTIONAL == "yes" then check if PACKAGE_xyz == y

build install:
**************
  same as the option "build", only this time the directory /build/scripts/install/
  is checked instead of /build/scripts/build/

The build script understands the command -f to specify another configfile instead
of the default .config

--- FILE-FORMATS --

format of files /build/scripts/config/package_*:
***********************************************
OPTIONAL="yes"
DESCRIPTION="Squid the standard in web-proxying. This implies that your \
firewall has a harddisk installed, where squid can put its cache."

format of file /build/scripts/.config (same format as /usr/src/linux/.config):
*******************************************************************************
PACKAGE_squid=y
PACKAGE_ftp-proxy=y
# PACKAGE_icq-proxy is not set
PACKAGE_amavis="yes"

-- 
MfG / Regards
Friedrich Lobenstockkk

Martin Mueller wrote:

>to keep me happy. It's much more work to maintain a system, that has
>multiple ways to run, than just a single one. And as I said before I
>
It's only a bit more work, because when it's running on the CD, there is 
no problem to do the same in a Ramdisk. You just need enough RAM, that's 
all.

>neither have interest in adding proxies and stuff to it, since it just
>creates new holes. 
>
Build-System with config file where you can select which Add-On's you 
what to have included

>So the question is maybe not if I'm happy but where does each of us
>want the development of devil-linux to go.
>
>Maybe everyone should just start to make list of things one considers
>important and what would be a no-no. That way we get a more complete
>idea of what everybody wants and who willing to work on what.
>
Ok do it.
I currently have no time for it.
But I would be happy to review yours.

>Then we could think of a concept, that would incorporate all/most of
>the ideas and make them maintainable for the inidividual developers.
>
But who writes it?

>That way we could maybe create some flexibility on how the system is
>build an run.
>
That's exactly where I wanna go.

-- 

cu
  Heiko

http://www.devil-linux.org

Martin Mueller wrote:

>>No no. We should be able to bring this all down to a common denominator.
>>We could provide two different ISOs, on that runs from RAM and another one,
>>for those like me that like to increase the level of security,  that runs
>>mostly from CD-ROM. See Heikos posting.
>>
>
>Yes we surely could, but the question is is it worth it? 
>
yes

>You see I have a system that works perfectly for me, and I'm not much
>interested in anything else. 
>
>It would only be a obstacle to compromise the development of
>devil-linux just because one guy who hasn't contributed a single line
>up to now raises issues which are contrary to the wishes of other
>developers. That's my attitude. So I'd be happy with any compromise we
>find, but just don't feel in need to find one just to keep me happy.
>Especially if I'm the only one want's a feature.
>
The things you want, can be solved by technics which I want to have in 
DL. So there would be no problem.
I spend so many hours at the moment to create the build system and I do 
it to have the needed flexibility.

-- 

cu
  Heiko

http://www.devil-linux.org

On Sat, Sep 15, 2001 at 10:26:22AM -0400, Heiko Zuerker wrote:
> 
> I think with this way, we can may nearly everybody happy.
> What do you think?

Well, of course I'd be happy, but it's stupid to do it that way just
to keep me happy. It's much more work to maintain a system, that has
multiple ways to run, than just a single one. And as I said before I
neither have interest in adding proxies and stuff to it, since it just
creates new holes. 

So the question is maybe not if I'm happy but where does each of us
want the development of devil-linux to go.

Maybe everyone should just start to make list of things one considers
important and what would be a no-no. That way we get a more complete
idea of what everybody wants and who willing to work on what.

Then we could think of a concept, that would incorporate all/most of
the ideas and make them maintainable for the inidividual developers.

That way we could maybe create some flexibility on how the system is
build an run.

bye
   MM

Martin Mueller      Phone: +49 39298 4125      e-mail:  mm...@si...
		    ICQ:         99023536              mm...@lu...
PGP/GPG mail welcome, keys as well other stuff at:  http://themm.net

On Sat, Sep 15, 2001 at 04:54:08PM +0200, Friedrich Lobenstock wrote:
> 
> I think you should tell those people that they might have to adapt there
> point of view regarding security. Internet-Security is one chapter
> that is going to be of high importance now and in the future. 

Well, that is out of question ... using one system solely for internet
acces is an allowance these people already make. I just can't go there
and tell them you have to invest this or that for being able to access
the internet. I set out to help them improve the _current_ state of
their security and there is having a firewall at all already an
important step. Maybe you just have too little experience with groups
like these, which mostly fund private donations and a sum like 200,--
DM is an issue with these kind of organisations. 

These groups have _no_ valuable information an their systems, that
need protaction, and they rather type in their documents again than
buying a backup solution that will cost them 500,-- or more. Hacking
there systems is useless, you could only use them as client for a DDOS
attack or something. Well, that wouldn't be nice, but it's not a big
problem either.

> No no. We should be able to bring this all down to a common denominator.
> We could provide two different ISOs, on that runs from RAM and another one,
> for those like me that like to increase the level of security,  that runs
> mostly from CD-ROM. See Heikos posting.

Yes we surely could, but the question is is it worth it? 

You see I have a system that works perfectly for me, and I'm not much
interested in anything else. 

It would only be a obstacle to compromise the development of
devil-linux just because one guy who hasn't contributed a single line
up to now raises issues which are contrary to the wishes of other
developers. That's my attitude. So I'd be happy with any compromise we
find, but just don't feel in need to find one just to keep me happy.
Especially if I'm the only one want's a feature.

I have neiher the time nor the motivation to invest vast amounts of
time in the development of devil-linux. My idea was just, that I
implement the stuff I need for my friends in devil-linux, so others
gain some functionality and I save time since I don't have to
maintain the whole base system. That was the reason I suggested to
take part in devil-linux as a developer. I'm not set out to develop a
"one size fits all" firewall solution.

> Please don't get me wrong, but sometimes also those organisations have to
> invest in a decent infrastructure. Not meaning that simple is bad - the
> motto in Firewalldesign is KISS (keep it straight and simple). But
> security consideration sometimes bite.

Nope, they don't have to and they won't. So either they use an easy to
maintain and cheap firewall, or they'll just use some Windows
connection sharing tool. The point is _I_ know what security is and
what is needed to get it. But I also found out that it's better to
have insufficient security than to have none. Most of the attackers
today on private systems are script-kiddies. When their attack doesn't
work on a system they try another one. It's these I wanna keep out. I
don't wanna develop a firewall against a guy with decent knowldge
since I perfectly know I won't be able to do this anyway.


bye
   MM

Martin Mueller      Phone: +49 39298 4125      e-mail:  mm...@si...
		    ICQ:         99023536              mm...@lu...
PGP/GPG mail welcome, keys as well other stuff at:  http://themm.net

Friedrich Lobenstock wrote:

>Martin Mueller wrote:
>
>>Hehe, well, that's what's too bothersome to me ... I don't earn any
>>money with it so I don't wanna have a constant "support job" :)
>>
>>If replacing the hardware every year is the price for security, then
>>the folks I made the firewall for don't need security :)
>>
>
>I think you should tell those people that they might have to adapt there
>point of view regarding security. Internet-Security is one chapter
>that is going to be of high importance now and in the future. 
>
>It's the same as with backups. You can tell people to do it, but they
>will mostly not follow your advice. BUT when it happens they will come
>crying to you.
>
Those people don't understand this problems.
The wake only up, when they had big trouble one time. Normally you can 
tell them what you want, but they don't understand it, or better don't want.

-- 

cu
  Heiko

http://www.devil-linux.org

Martin Mueller wrote:
> 
> Well if the system runs  from CD I had a crash on any of them maybe
> every 6 weeks (that means every 6 weeks crashed another one). Since
> running from ramdisk, I didn't have to replace any part in the last 2
> years.

Hmmm...

> Hehe, well, that's what's too bothersome to me ... I don't earn any
> money with it so I don't wanna have a constant "support job" :)
> 
> If replacing the hardware every year is the price for security, then
> the folks I made the firewall for don't need security :)

I think you should tell those people that they might have to adapt there
point of view regarding security. Internet-Security is one chapter
that is going to be of high importance now and in the future. 

It's the same as with backups. You can tell people to do it, but they
will mostly not follow your advice. BUT when it happens they will come
crying to you.

 
> To cut this issue short ... I decided to work on devil-linux because
> of the concept it has _now_ ... if this is going to be a "high
> security, multi feature project", it's just not the right stuff for
> me. I just prefer a _small_ easily comprehensible system, with low
> maintenance and relatively good security. This what devil-linux 0.44
> is. If that design is scrapped. I'm just in the wrong project.

No no. We should be able to bring this all down to a common denominator.
We could provide two different ISOs, on that runs from RAM and another one,
for those like me that like to increase the level of security,  that runs
mostly from CD-ROM. See Heikos posting.

 
> I do my stuff for art-projects, human-rights
> groups and environmental groups like the BUND in germany for free,
> since these groups better spend their money on their work instead of
> their equipment. They don't need a particullary high security system.
> They just need a system that simply works without anyone looking after
> it.

Please don't get me wrong, but sometimes also those organisations have to
invest in a decent infrastructure. Not meaning that simple is bad - the
motto in Firewalldesign is KISS (keep it straight and simple). But
security consideration sometimes bite.

-- 
MfG / Regards
Friedrich Lobenstock

Hi,

you're not in the wrong project, because:
0.5 will have the option to run the entire system also in a Ramdisk, you 
can select this via a configuration file. We just create the first 1 or 
2 Beta's for CD only, because when it is able to run entirely from CD, 
there is no problem when we just copy all the stuff to a Ramdisk and run 
it from there.

Devil-Linux will give you in the future many more option, such as 
Proxies and MTAs.
BUT you will never be forced to use them, neither to have them on the ISO.
We should create the Build Scripts this way, that everybody is able to 
select exactly what he wants to have on his Firewall/Gateway.
I'm not a friend of "I have everything on my Firewall". I want only to 
have this installed, which I really need.

I think with this way, we can may nearly everybody happy.
What do you think?

cu
  Heiko

On Sat, Sep 15, 2001 at 02:14:09PM +0200, Friedrich Lobenstock wrote:
> Hi!
> 
> OK, then tell me from your experience how often did you have to change a 
> CD-ROM drive in those 15 systems? 

Well if the system runs  from CD I had a crash on any of them maybe
every 6 weeks (that means every 6 weeks crashed another one). Since
running from ramdisk, I didn't have to replace any part in the last 2
years.

> True, but if that happens in once in every 1-2 years(estimated) that a
> CD-ROM drive has to be replaced they should understand that it an 
> implication of security. In the mean time you keep sending them updated 
> CD's. They just reset the machine change the CD and the computer is 
> starting up the new system.

Hehe, well, that's what's too bothersome to me ... I don't earn any
money with it so I don't wanna have a constant "support job" :)

If replacing the hardware every year is the price for security, then
the folks I made the firewall for don't need security :)


To cut this issue short ... I decided to work on devil-linux because
of the concept it has _now_ ... if this is going to be a "high
security, multi feature project", it's just not the right stuff for
me. I just prefer a _small_ easily comprehensible system, with low
maintenance and relatively good security. This what devil-linux 0.44
is. If that design is scrapped. I'm just in the wrong project.

Please don't get me wrong. Maybe what I saw as devil-linux when I
looked at it, was just not what devil-linux want's to be. It was just
very similar to the system I have now, and I wanted to put my effort
in devil-linux instead of my own system, for it to beneficial to more
people than just me. But in case devil-linux has different goals,
they're not mine. :) I do my stuff for art-projects, human-rights
groups and environmental groups like the BUND in germany for free,
since these groups better spend their money on their work instead of
their equipment. They don't need a particullary high security system.
They just need a system that simply works without anyone looking after
it.

bye
   MM

Martin Mueller      Phone: +49 39298 4125      e-mail:  mm...@si...
		    ICQ:         99023536              mm...@lu...
PGP/GPG mail welcome, keys as well other stuff at:  http://themm.net

Hi!

Martin Mueller wrote:
> 
> Security is always a compromise between convenience, usability and
> security. My focus is on systems, which are "secure enough" but still
> reliable and convenient. When you're used to remote administration
> like I am, you'll begin to detest any kind of moving parts in
> computers, since they constantly fail ... so my most favoured setup
> atm is a firewall that runs from EEPROM/Ramdisk combination which has
> a readonly-switch on the flash card. So when I have to make changes to
> the system, I just call my friend and tell him to enable writing to
> the flash, then I put the updates on, and afterwards he switches it
> back to readonly. The system runs from ramdisk though, to be able to
> pull the flash card during operation and flip the switch.

I agree, but my point is that CD-ROMs are a commodity nowadays. You can
get them in every computer store around the corner. When your flash card 
goes into Nirvana you are lost because you have to order that part and 
maybe wait for a week or more for it to arrive. 

So my view is, use only commodity hardware and flash disks are still not 
a commodity nowadays - they might be some day.

-- 
MfG / Regards
Friedrich Lobenstock

Martin Mueller wrote:
> 
> What I'd propose is, let us include the possibility of burning the
> configuration of the firewall onto the cdrom, and you can reboot the
> system every couple of days (maybe every sunday) so a hacker doesn't
> have much fun on the system anyways.

See my posting on this list:
-------- Original Message --------
Subject: Re: [Devil-linux-develop] suggestions for 0.5 Beta CD layout
Date: Sat, 15 Sep 2001 03:29:36 +0200
From: Friedrich Lobenstock <fl...@fl...>
Reply-To: dev...@li...
To: dev...@li...
References: <3BA...@fl...>

Hi again!

To tighten up security even more we could create a script that configures
the firewall (includes your custom rc.firewall, etc.) and creates the final 
iso. ONLY var would be mounted as a shared memory files system. 

Would be real hard for a hacker, wouldn't it?

-- 
MfG / Regards
Friedrich Lobenstock

Hi!

Martin Mueller wrote:
> 
> Well, most of them have a quite minimal setup, they are just NAT
> boxes, that only allow ssh from the internal network ... so there
> aren't any deamons to be out of date, and I know of no kernel-bug,
> that allows a remote exploit except a DOS attack. Well in case that
> happens, just hit the reset button and you're set.

Yes, but that will not always be the same with devil-linux, because 
for more advanced systems Heiko planned to add some proxies, MTA, ...
I will definitly be one to apply such systems. 

For example if one has got a mail server behind to firewall, the firewall
has to accept SMTP connections and proxy/spool them to the internal server.
So I think that we have to keep that in mind and designed Devil-Linux
as secure as possible.

> > I would suggest updating the CD _at least_ every 6 month.
> > How about the CD-ROM drives themself, how long do the work flawlessly?
> > If they only work for 1-2 year what's the cost of a new drive? Only about
> > $47 / 100 DM / 700 ATS. That's _nothing_ compared to the costs when you're
> > cracked.
> 
> It's not the cost of a cdrom drive, or the CDROM, it's the maintenance
> cost, to have someone change the drive for you and have a downtime.

OK, then tell me from your experience how often did you have to change a 
CD-ROM drive in those 15 systems? 


> Most of the people I made the CDs for, have _no_ clue about hardware
> or computers except using a webbrowser, and they're often a couple of
> hundreds of kilometers away. So the onyl thing I can do for them is
> send them a CD via mail, but they have to get the hardware serviced
> themselves, which involves paying quite a lot for changing a CDROM.

True, but if that happens in once in every 1-2 years(estimated) that a
CD-ROM drive has to be replaced they should understand that it an 
implication of security. In the mean time you keep sending them updated 
CD's. They just reset the machine change the CD and the computer is 
starting up the new system.

> > How? A descent firewall should be the point of attack not the systems
> > behind it. Do you use ip-port-forwarding?
> 
> Well, just NAT behind a single ip-address, no daemons, no other stuff.

What kind of attacks did you get? The ones where one from the inside (eg.
via link in a mail) could trick the Linux masquerading into opening ports
for one machine to the outside? I you just use NAT then I can't think of 
anything else besides troyans and viruses, but that's another chapter.
Maybe once, when we do virus scanning on the firewall we could take care 
of it.

-- 
MfG / Regards
Friedrich Lobenstock

What I'd propose is, let us include the possibility of burning the
configuration of the firewall onto the cdrom, and you can reboot the
system every couple of days (maybe every sunday) so a hacker doesn't
have much fun on the system anyways.

Security is always a compromise between convenience, usability and
security. My focus is on systems, which are "secure enough" but still
reliable and convenient. When you're used to remote administration
like I am, you'll begin to detest any kind of moving parts in
computers, since they constantly fail ... so my most favoured setup
atm is a firewall that runs from EEPROM/Ramdisk combination which has
a readonly-switch on the flash card. So when I have to make changes to
the system, I just call my friend and tell him to enable writing to
the flash, then I put the updates on, and afterwards he switches it
back to readonly. The system runs from ramdisk though, to be able to
pull the flash card during operation and flip the switch.

bye
   MM

Martin Mueller      Phone: +49 39298 4125      e-mail:  mm...@si...
		    ICQ:         99023536              mm...@lu...
PGP/GPG mail welcome, keys as well other stuff at:  http://themm.net

On Sat, Sep 15, 2001 at 01:20:45PM +0200, Friedrich Lobenstock wrote:
> If you run the same CD for 1-2 years you are out of luck anyway, because
> you're hopefully out of date - what, if one of the daemons or the kernel
> has a bug? 

Well, most of them have a quite minimal setup, they are just NAT
boxes, that only allow ssh from the internal network ... so there
aren't any deamons to be out of date, and I know of no kernel-bug,
that allows a remote exploit except a DOS attack. Well in case that
happens, just hit the reset button and you're set.

> I would suggest updating the CD _at least_ every 6 month. 
> How about the CD-ROM drives themself, how long do the work flawlessly?
> If they only work for 1-2 year what's the cost of a new drive? Only about 
> $47 / 100 DM / 700 ATS. That's _nothing_ compared to the costs when you're
> cracked.

It's not the cost of a cdrom drive, or the CDROM, it's the maintenance
cost, to have someone change the drive for you and have a downtime.

Most of the people I made the CDs for, have _no_ clue about hardware
or computers except using a webbrowser, and they're often a couple of
hundreds of kilometers away. So the onyl thing I can do for them is
send them a CD via mail, but they have to get the hardware serviced
themselves, which involves paying quite a lot for changing a CDROM.

> How? A descent firewall should be the point of attack not the systems
> behind it. Do you use ip-port-forwarding?

Well, just NAT behind a single ip-address, no daemons, no other stuff.

bye
   MM

Martin Mueller      Phone: +49 39298 4125      e-mail:  mm...@si...
		    ICQ:         99023536              mm...@lu...
PGP/GPG mail welcome, keys as well other stuff at:  http://themm.net

Hi!

Martin Mueller wrote:
> 
> Well, I'd oppose a mounted CD, since I have quite bad experiences with
> long running systems and CD-Rs / CD-RWs. I run about 15 firewalls from
> CD, which I created myself and they usually fail to work after 1-2
> years, since the CD gets unreadable sectors, because of the constant
> heat in the cdrom drive. So think it quite advisable to be able to
> take the CD out while the system is running to replace it with working
> one.

That might be true, but from my point of view I would rather change the 
cdrom drive. If the system run's from RAM we are more susceptible to the 
matter that a hacker that cracked into our firewall can change everything.
If you run the same CD for 1-2 years you are out of luck anyway, because
you're hopefully out of date - what, if one of the daemons or the kernel
has a bug? I would suggest updating the CD _at least_ every 6 month. 
How about the CD-ROM drives themself, how long do the work flawlessly?
If they only work for 1-2 year what's the cost of a new drive? Only about 
$47 / 100 DM / 700 ATS. That's _nothing_ compared to the costs when you're
cracked.


> The other point is, in the whole time I run these firewalls, I never
> got an attack on the firewall itself, just on the systems behind it.

How? A descent firewall should be the point of attack not the systems
behind it. Do you use ip-port-forwarding?

-- 
MfG / Regards
Friedrich Lobenstock