ipcop-devel Mailing List for IPCop Firewall

> >I'm guessing that either your tarfile (ipcop.tgz) was corrupted before or
> >during download and was not extracted completely.
> 
> I can also reproduce this problem.  SW will (just about) fit on a 100
> meg hard drive when doing a network install but there's just not enough
> room on a 100M drive to do this with IPCop, as its file system is quite
> a bit bigger.  An HTTP/FTP install of 0.1.1 needs at least a 125 meg
> hard drive, as enough room is needed on / to accommodate both the
> installed file system and the downloaded copy of ipcop.tgz.  For some
> reason the installer doesn't trap the error and falls over when it tries
> to run the next command - which didn't get installed because the disk
> filled up.
> 
> If the install needs to go on that 100 meg disk, it _may_ be possible to
> untar ipcop.tgz on a suitable machine, remove some of the dead wood and
> re-pack it.  That would run the risk of accidentally removing something
> vital though.  I hesitate to suggest it, as it's not a task to be
> undertaken lightly and I'm not sure if there's enough that can be safely
> removed...

I just retried this and I think this is correct.

The last file to be untarred is mindtermfull.jar, there are
more files that should be unpacked.

Disk partition table is:

124984 hda
  5176 hda1
 16456 hda2
 21624 hda3
 81736 hda4

unpacking ipcop.tgz to a local directory seems to require
70053888 bytes (du) and the tarball is 21908832 bytes.

Maybe the hda3 partition could be used for downloading the temporary
tarball?

Jamie

In article <362...@ww...>,
Mark Wormgoor <ma...@wo...> writes

>I can confirm succesfully installing 0.1.1 using http.  My IPCop box
>doesn't have a cdrom, so I always use the HTTP method.

So can I, but see below.

>> ----- Original Message -----
>> From: "Jamie Honan" <jh...@op...>
>> To: <ipc...@li...>
>> Sent: Wednesday, January 30, 2002 8:54 PM
>> Subject: [IPCop-devel] v0.1.1 HTTP install fails at depmod
>>>
>>> IPCOP v0.1.1
>>>
>>> old 486, 100M hard drive, 8 Meg memory, wd + ne ISA cards (runs
>>> smoothy OK)
>>>
>>> Install using diskette boot with http fetch of ipcop image.
...
>>> This fails because there is no depmod. I notice busybox doesn't
>>> have depmod built in so it is not just a matter of adding the symlink.
>>>

>I'm guessing that either your tarfile (ipcop.tgz) was corrupted before or
>during download and was not extracted completely.

I can also reproduce this problem.  SW will (just about) fit on a 100
meg hard drive when doing a network install but there's just not enough
room on a 100M drive to do this with IPCop, as its file system is quite
a bit bigger.  An HTTP/FTP install of 0.1.1 needs at least a 125 meg
hard drive, as enough room is needed on / to accommodate both the
installed file system and the downloaded copy of ipcop.tgz.  For some
reason the installer doesn't trap the error and falls over when it tries
to run the next command - which didn't get installed because the disk
filled up.

If the install needs to go on that 100 meg disk, it _may_ be possible to
untar ipcop.tgz on a suitable machine, remove some of the dead wood and
re-pack it.  That would run the risk of accidentally removing something
vital though.  I hesitate to suggest it, as it's not a task to be
undertaken lightly and I'm not sure if there's enough that can be safely
removed...


-- 
Kevin Richards

> For the depmod, the command should be something like:
> /cdrom/bin/chroot /harddisk /sbin/depmod -a
>
> This does a chroot() to /harddisk.  Your / is now the installed IPCop
> filesystem.  This does have a depmod command if the tarfile was unpacked.
> I'm guessing that either your tarfile (ipcop.tgz) was corrupted before or
> during download and was not extracted completely.
 
I did have a dodgy ethernet card which
made the download really slow, so maybe it aborted before the complete
image. I noticed the perl and squid stuff unpacking OK, and I see in
the ipcop.tgz file the /sbin stuff comes after this.
 
I tried to use df to see if my filesystems were full, (I only have
100 Meg drive - the partitioning works fine). Is there another
busybox utility or /proc method of seeing the state of filesystems
at this point of install?
 
I'll try again later today with good ethernet card and report back.
 
Many thanks for reply, and of course, all the work put into
Ipcop.
 
While I'm here can I put in a request?
 
The ifconfig that busybox has built in has no display mode
of the eth interfaces. This is quite handy to make sure
the eth interface is configured OK and is error free.
 
In my case I had framing errors, but could only see them through
the /proc/net/dev interface.

(Actually, the card could well have been dodgy for some time. An
automatic warning system on certain hardware degradations would
be just the ticket).
 
Jamie
~

On Thu, 31 Jan 2002, Mark Wormgoor wrote:

> First, who is willing to help with the actual development:
> - C programming
> - Perl programming

I can help with the perl bits however I cannot offer to do too much as I 
am rather busy on other projects too. I have however made a start at 
producing a user authentication system for use by proxies such as Squid 
(both an authentication module and a module to manage the user base). 

It's being developed as a general purpose package to stand on its own 
however it should be very easy to integrate into IPCop - unless, of 
course, you already have such a tool as part of the armamentarium.

I'm thinking about extending it a bit to add on a management module for 
Squid blocklists - either blacklisting or whitelisting. 

Jason Clifford

Guys,

Now that we have most of the base system finished, we should get work
started again on the v0.2 stuff.

First, who is willing to help with the actual development:
- C programming
- Perl programming

I hope to have a basic system with an installer finished before the
weekend.  You can then install it (perhaps using Bochs or Vmware) and see
what the system looks like.

Today, I have made yet another start with the XML/RPC API.
Check out:
http://www.ipcop.org/cgi-bin/twiki/view/IPCop/IPCopDevelopmentv02
(general development page)
	and
http://www.ipcop.org/cgi-bin/twiki/view/IPCop/IPCopXMLRpcApiv02
(my new version of the xml/rpc API)

Kind regards,


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

Hi,

> I've also been unable to install from http on a box  that runs SW OK.
> Got a kernel oops but using ksymoops as suggested to diagnose the
> problem further has I'm afraid proved beyond my limited expertise. I
> couldn't even get console 2. Perhaps someone could confirm please that
> they have succesfully installed 0.1.1 using http?
>
I can confirm succesfully installing 0.1.1 using http.  My IPCop box
doesn't have a cdrom, so I always use the HTTP method.
I have no idea what's causing the ksymoops, but we're only using the 2.2.20
kernel with minor patches (ext3, freeswan and usb adsl).  My guess would be
that the kernel oops is caused by hardware.

> ----- Original Message -----
> From: "Jamie Honan" <jh...@op...>
> To: <ipc...@li...>
> Sent: Wednesday, January 30, 2002 8:54 PM
> Subject: [IPCop-devel] v0.1.1 HTTP install fails at depmod
>>
>> IPCOP v0.1.1
>>
>> old 486, 100M hard drive, 8 Meg memory, wd + ne ISA cards (runs
>> smoothy OK)
>>
>> Install using diskette boot with http fetch of ipcop image.
>> All goes well fetching image, unpacks image (can see using virtual
>> console 2), then something like (this line from memory)
>>
>> /cdrom/bin/chroot /cdrom/bin/depmod -a
>>
>> This fails because there is no depmod. I notice busybox doesn't
>> have depmod built in so it is not just a matter of adding the symlink.
>>
>> I'm surprised no-one else has this problem. Is everyone else doing
>> CDROM installs?

For the depmod, the command should be something like:
/cdrom/bin/chroot /harddisk /sbin/depmod -a

This does a chroot() to /harddisk.  Your / is now the installed IPCop
filesystem.  This does have a depmod command if the tarfile was unpacked.
I'm guessing that either your tarfile (ipcop.tgz) was corrupted before or
during download and was not extracted completely.

Kind regards,

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

I've also been unable to install from http on a box  that runs SW OK. Got a
kernel oops but using ksymoops as suggested to diagnose the problem further
has I'm afraid proved beyond my limited expertise. I couldn't even get
console 2. Perhaps someone could confirm please that they have succesfully
installed 0.1.1 using http?

Cheers

Peter
----- Original Message -----
From: "Jamie Honan" <jh...@op...>
To: <ipc...@li...>
Sent: Wednesday, January 30, 2002 8:54 PM
Subject: [IPCop-devel] v0.1.1 HTTP install fails at depmod
>
> IPCOP v0.1.1
>
> old 486, 100M hard drive, 8 Meg memory, wd + ne ISA cards (runs
> smoothy OK)
>
> Install using diskette boot with http fetch of ipcop image.
> All goes well fetching image, unpacks image (can see using virtual
> console 2), then something like (this line from memory)
>
> /cdrom/bin/chroot /cdrom/bin/depmod -a
>
> This fails because there is no depmod. I notice busybox doesn't
> have depmod built in so it is not just a matter of adding the symlink.
>
> I'm surprised no-one else has this problem. Is everyone else doing CDROM
> installs?
>
> Regards
> Jamie
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

IPCOP v0.1.1

old 486, 100M hard drive, 8 Meg memory, wd + ne ISA cards (runs
smoothy OK)

Install using diskette boot with http fetch of ipcop image.
All goes well fetching image, unpacks image (can see using virtual
console 2), then something like (this line from memory)

/cdrom/bin/chroot /cdrom/bin/depmod -a

This fails because there is no depmod. I notice busybox doesn't
have depmod built in so it is not just a matter of adding the symlink.

I'm surprised no-one else has this problem. Is everyone else doing CDROM
installs?

Regards
Jamie

Well depending on what you are seeing you might be experiencing the problem
I posted a solution a couple of weeks ago.

To run down the problem can you confirm some of the following requirements:

1) Open up port 21,20 in the rules
2) Forward port 21,20 to your internal FTP server
3) FTP server has the IPCop as the default gateway

Ok given all of the above is in place

1) When you ftp to your IPCop machine do you get any response? If yes goto 2
2) Can you login? If yes goto 3
3) When you do a ls or dir what do you see? If results you are good! (If
fails try again in PASSIVE mode)

Failure at:
1 - implies there is a routing/firewalling problem. Check the above
requirements
2 - You have the wrong password :-)
3 - The firewall is not correctly formatting the responses. Personally I
have had this problem
when going through another firewall which forced me to go passive. If you
change in to passive mode you should see a PORT command come back. If this
port command contains your internal IP address then this is the problem!!!

My passive FTP problem on both SW and IPCop where solved by changing/adding
the following section to the FTP masq module:

vi /etc/rc.d/rc.network and change
"modprobe ip_masq_ftp ports=21,2121"
            to
"modprobe ip_masq_ftp in_ports=21"

Mark has pointed out to me that 'ports' and 'in_ports' are different beasts,
but changing this for me worked. I presume if not defined 'ports' defaults
to the 21, and 'in_ports' is not defined. Personally I know this works, but
wanted someone else to validate this for me before making a change to the
FAQ. Hopefully this can be rolled into a patch (or just be obsoleted by
0.2)!

Hope this helps,

Gareth

----- Original Message -----
From: "Richard Lynch" <ce...@l-...>
To: <ipc...@li...>
Sent: Wednesday, January 30, 2002 1:13 AM
Subject: [IPCop-devel] Re: [IPCop-user] FTP-server on DMZ


> There is this little matter of gettting the FTP-server to be
> accessible from the RED net when it's on the ORANGE. I wee that there
> is a section in the FAQ that is to be done and I'm starting to
> understand the need of that section :-(
>
> So I now I'm resolving to asking you out there. Is there anybody that
> a) can tell me what has to be done or b) can point me to someplace
> where I can find that information.
> What I've done so far is to forward tcp port 21 to the ORAGNE net
> (the ftp-server) ,I also have tried to forward tcp 20 and udp
> 20,21 just for good sake but no difference. I can connect but the
> server can't build a return connection and passive doesn't work
> either.
>
> Like, the FTP server (ftpd or inetd or whatever) *IS* running on the
> ORANGE box, right?...
>
> It almost sounds like you forgot to verify that the FTP server is
> alive and well... Can the ORANGE box FTP to itself?
> --
> WARNING ri...@ze... email address is an endangered species
> Use ce...@l-... instead
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

There is this little matter of gettting the FTP-server to be 
accessible from the RED net when it's on the ORANGE. I wee that there 
is a section in the FAQ that is to be done and I'm starting to 
understand the need of that section :-(

So I now I'm resolving to asking you out there. Is there anybody that 
a) can tell me what has to be done or b) can point me to someplace 
where I can find that information.
What I've done so far is to forward tcp port 21 to the ORAGNE net 
(the ftp-server) ,I also have tried to forward tcp 20 and udp 
20,21 just for good sake but no difference. I can connect but the 
server can't build a return connection and passive doesn't work 
either.

Like, the FTP server (ftpd or inetd or whatever) *IS* running on the 
ORANGE box, right?...

It almost sounds like you forgot to verify that the FTP server is 
alive and well... Can the ORANGE box FTP to itself?
-- 
WARNING ri...@ze... email address is an endangered species
Use ce...@l-... instead

Hey all,

A while back I was to send a modem to someone.  Unfortunately I forgot who
and can no longer find the email.  If you get this then please contact me.
I apologize but have been a bit busy (IPCop, job search, etc..) and forgot
all about it.

chuck

Mike,

> I tried to install the stable distribution on an Asus k6-2 300 machine with
> 64 Mb of RAM. This system works perfectly with RedHat7.1. However, I just
> get a CRC error before anything happens in the install. I tried the same
> hardware, but with a Celeron II slot 1 motherboard in place, with no
> problems and it all installed fine. However, I am unsure why the k6-2
> system would not work. I think it might be the way the loader of the
> default distribution is compiled for the Pentium 2 and not the AMD - it is
> a pity as low end machines like this are more than adequate for the
> firewall task. Is there an easy way to fix this?

All software including the kernel is optimized for i386 only.  It works
just fine on my 486 at home and the k6-2 is definitely compatible with the
486 instruction set.

So, I'm guessing there is a problemen with your AMD, but am not sure what
it could be.

Kind regards,

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

I tried to install the stable distribution on an Asus k6-2 300 machine with 
64 Mb of RAM. This system works perfectly with RedHat7.1. However, I just 
get a CRC error before anything happens in the install. I tried the same 
hardware, but with a Celeron II slot 1 motherboard in place, with no 
problems and it all installed fine. However, I am unsure why the k6-2 
system would not work. I think it might be the way the loader of the 
default distribution is compiled for the Pentium 2 and not the AMD - it is 
a pity as low end machines like this are more than adequate for the 
firewall task. Is there an easy way to fix this?

Mike

Dear IPCop Team,

I ran into a problem today loading IPCop v0.1.1, after downloading your ISO
image.

It looks like the contents of the IPCop Drivers diskette image is same as
the Boot diskette image.

My IPCop machine is a 486DX/100 with no CD-ROM, and I was unable to load the
NE2000 PCI driver. I know the machine is working OK because it's running
another - er - similar firewall.

Hope this helps. I'm looking forward to trying IPCop.

Best regards,

John Ingleby

Dear IPCop,

I'm sorry - my resolution of the problem may be incorrect...

The "Unable to load driver" error could also perhaps be caused by 2 similar
(but not identical) NE2000 PCI clone cards on my machine.

Thanks,

John
****

-----Original Message-----
From: John Ingleby [mailto:jo...@co...]
Sent: 27 January 2002 19:06
To: ipc...@li...
Subject: Install problem - drivers diskette


Dear IPCop Team,

I ran into a problem today loading IPCop v0.1.1, after downloading your ISO
image.

It looks like the contents of the IPCop Drivers diskette image is same as
the Boot diskette image.

My IPCop machine is a 486DX/100 with no CD-ROM, and I was unable to load the
NE2000 PCI driver. I know the machine is working OK because it's running
another - er - similar firewall.

Hope this helps. I'm looking forward to trying IPCop.

Best regards,

John Ingleby

Guys,

On the Sourceforge page you will find (within 30 minutes) an initial build
of the basesystem for v0.2.  It contains ONLY the programs that are going
into v0.2.  It does NOT contain:
- boot scripts (so, you can't boot it, use chroot)
- the rpc/xml server
- CGI scripts
etc, etc, etc...

It is meant for those people who want to hack away at v0.2 and need
something to work with.  Please check it.  See if programs are missing
that should be there, etc.

Kind regards,


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

Hi there, 
 
I know its not on the list of supported hardware, but can it be used, I
have a weak RH7.2 box currently running as my router/firewall and it's a
pain in the ass - cant get port forwarding to work, like the look of
IPCop and what it offers, I just need to have the red interface use a
netgear FA311 NIC
 
Cheers in advance
 
Jamers

All this doesn't solve my problem .... The real problem is that a 8 GB disk
with more than 1024 Cylinder is unusable by IPCop


 -----Original Message-----
From: 	ipc...@li...
[mailto:ipc...@li...]  On Behalf Of Alex Hudson
Sent:	mardi 22 janvier 2002 11:43
To:	IPCop Users List
Cc:	IPCop Development List
Subject:	RE: [IPCop-user] IPCop v0.1.1 release

On Tue, 2002-01-22 at 10:16, Jason Clifford wrote:
> > Hang on, this is weird. The code _says_ it should partition /boot, swap,
> > /log and / in that order - hence, /boot _should_ be /dev/hda1. In fact,
> > I don't see how it works otherwise.
>
> Is it explicit about specifying /boot to be from the first cylinder?

Okay, hang on, I think I see it :) We're not talking about the /boot
partition - we're talking about the bootable partition. Which is /, aka
/dev/hda4. I presume the lilo second-stage boot loader is getting shoved
in there, which is conceivably over the 1024 cylinder limit.

I've just been through the installer code, and it's riddled with bugs.
It doesn't calculate the partition sizes correctly at all (current_free
is written over numerous times). Given a disk of 100Mb, it fails to take
into account other partitions taking up disk space and writes out the
following partition table:
	,5,83,
	,16,82,
	,20,83,
	,,83,*
In this case the partition allocation bugs don't show up, because / is
never specified explicitly (although the internal variable which holds
it's size is wrong) and /var/log defaults to the 20Meg minimum. Comments
in the code indicate that the Smoothwall developers attempted to
explicitly set the size of the / partition, and it wouldn't work - their
bugs would appear to make the disk bigger than it actually is.

However, the main point is that /dev/hda4 is set as the bootable device.
Surely this isn't correct? Those who know lilo better than me will have
to check, but I would suspect that is the problem, and the fact that
/boot is at the start of the disk (we don't specify the cylinder, but
sfdisk will write them out in the order given and we fill the disk, so
implicitly it should be correct) may not matter :/

Food for thought :)

Alex.


_______________________________________________
IPCop-user mailing list
IPC...@li...
https://lists.sourceforge.net/lists/listinfo/ipcop-user

At 10:27 AM +0100 1/23/02, Mark Wormgoor wrote:
>  > >Changes are forthcoming.
>>
>>  To enable an efficient update of translated docs, I'd recommend to
>>  mark/identify the changes in the English docs either by special
>>  colors (foreground and/or background), special fonts, etc. Could we
>>  establish a quasi-standard for this procedure for this project? Any
>>  suggestions?
>>
>>  Refers only to offline docs and/or src docs, and should be
>>  applicable to .RTF files as a general interchange format, and not
>>  restricted to a special word processor.
>
>And again, docbook and cvs prove their purposes.  Wouldn't you love it if
>the CVS version and the date were listed in the $Id$ variable in the doc?
>And wouldn't you love it if you could just do a diff between the two?

I've been doing a lot of studying on docbook.  I have found an 
(almost) GPL'ed WYSIWYM, "What You See Is What You Mean", editor, Lyx 
<http://www.lyx.org>.  It's GPL'ed, except for an additional package, 
xfront, that requires different attribution.  It's available on both 
*nix and Win32.

I've been reading, but unless I want to make a career of it, we'll 
need to find help or examples setting up catalog and DSSSL files. 
XML preferably, although the Lyx site seems to indicate the XML 
version of docbook is not ready for prime time, yet.  Does anyone 
have any experience or good samples?

Harry

On Tue, 22 Jan 2002, Richard Lynch wrote:

> Same here.  Frequently, the background knowledge assumed by an FAQ is 
> about 10 rungs higher on the ladder than it should be.

It's actually very very hard to write good help documentation such as a 
FAQ as once you have gained the necessary knowledge and experience to be 
able to do so you tend to have been at it for so long that you forget what 
it was like having to start out.

I also think that those who are naturally talented in geek persuits tend 
to have a hard time understanding that the things we find so easy and 
obvious are actually rather arcane, and frightening, to others.

I always try to get others to read through any document I have written and 
I listen to their comments on how hard it is to read and their suggestions 
on how to better explain things - once I have explained them to the person 
sufficiently for them to understand.

Jason

Hi,

> >Changes are forthcoming.
>
> To enable an efficient update of translated docs, I'd recommend to
> mark/identify the changes in the English docs either by special
> colors (foreground and/or background), special fonts, etc. Could we
> establish a quasi-standard for this procedure for this project? Any
> suggestions?
>
> Refers only to offline docs and/or src docs, and should be
> applicable to .RTF files as a general interchange format, and not
> restricted to a special word processor.

And again, docbook and cvs prove their purposes.  Wouldn't you love it if
the CVS version and the date were listed in the $Id$ variable in the doc?
And wouldn't you love it if you could just do a diff between the two?

Kind regards,

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

> Ludwig,
> 
> Here is the initial release.  It's rather large as it was done before the images were
> resampled.  

>Changes are forthcoming.

To enable an efficient update of translated docs, I'd recommend to 
mark/identify the changes in the English docs either by special 
colors (foreground and/or background), special fonts, etc. Could we 
establish a quasi-standard for this procedure for this project? Any 
suggestions?

Refers only to offline docs and/or src docs, and should be 
applicable to .RTF files as a general interchange format, and not 
restricted to a special word processor.

Ludwig 

> 
> chuck
> 
> 

Hi,

> > The bootable device is never used when using lilo.  You can remove the
> > active flag and it will still boot (I think).  It works like
> > this.  Lilo is
> > read from the mbr.  This then loads the kernel from /boot.
> > The kernel will
> > then boot and mount the root filesystem (/dev/hda4).  Since
> > the kernel has
> > taken over from the bios here, the 1024 limit is not an issue.  If the
> > kernel was on /, it would have to read the kernel from that
> > partition and
> > there is a possibility that it is located beyone 1024.
> >
>
> this is not quite the case
>
> from the lilo mini-howto ( http://www.linuxdoc.org/HOWTO/mini/LILO-2.html )
>
> "The boot= directive in /etc/lilo.conf tells Lilo where it should place its
> primary boot loader. In general, you can either specify the master boot
> record (/dev/hda) or the root partition of your Linux installation (is
> usually is /dev/hda1 or /dev/hda2)."
>
> from this description, it's is possible that lilo is being installed on
> /dev/hda4 rather than /dev/hda

Ofcourse I also checked the lilo.conf to make sure that the bootloader
readlly is installed in the mbr.  It is ;)

Kind regards,

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

>understandable FMs. (Dammit Jim, I'm a programmer, not a sysadmin!) 
>- er.. yes.

Same here.  Frequently, the background knowledge assumed by an FAQ is 
about 10 rungs higher on the ladder than it should be.

>Okay, I have IPCop installed and running, and doing the basic 
>functionality I wanted it for perfectly: Allowing my 2 PCs to use my 
>ADSL connection, whatever OS I deem to be on it for this week.

Sounds good so far.

>I think everything is going OK, but here lies the crux, I don't 
>really know if:
>
>a) the firewalling functionality has been properly configured, and,

Seems to have...

>b) how I can check this. I have seen a few log-entries which I do 
>understand for 80%, but I don't really know if the firewall has just 
>detected them or also repelled the attempt.

If it was able to detect them well enough to log them, then, by 
definition, it was able to repel them.  End of story.

That said -- there's no promise that it didn't miss an attack, nor 
that you did something, well, stupid, like opening up a binary 
attachment to your email and executing it.  IE running a hacker's 
program for them.

IPCop doesn't stop stupidity from within your own organization, just 
the barbarians outside the gates.

>I have the suspicion that it's all wide open, because all 
>applications I'm using (mail, news, ICQ, AIM, MSN, YHM, IRC) all 
>worked from the get-go, and I can almost feel the draft from the 
>wide-open door.

mail and news should "just work" so that's okay.

And also ICQ/IRC for some servers, I think, depending on how they 
operate -- Whether they stick to the single, usual, port that 
everybody uses, or try to multi-task ports or some such...  So 
ICQ/IRC should not worry you, I think.

MSN, YHM (?), and AIM...  does seem a bit odd.  I would expect AIM 
and assuming the M in YHM is 'Messenger' to have needed another 
pinhole opened up...

MSN, well, I'm pretty sure the 'M' is for Microsoft, so I refuse to 
even play with that one.  Dunno what it is, don't care.

>So, pointers and some pushes would be appreciated.

Well, at the brute force level, if you can un-plug IPCop's connection 
to the Internet by literally pulling out the cable from the wall to 
IPCop on the IPCop end, and things don't immediately stop working, 
then you definitely have a problem.  Well, two problems, actually, 
now that you have that wire un-hooked :-)
In other words, if you think your computers are not routing through 
IPCop, un-pluggin IPCop is a pretty quick way to find out if you've 
done something really silly to bypass IPCop.

After you plug that cable back in, you *COULD* use one of those 
stupid web-sites that tests your firewall, but that's a BAD IDEA (see 
the IPCop FAQ for why).  Instead, if you have SSH access to an 
external computer of some kind, you can try this from your IPCop box:

ssh -l remote-login-name-goes-here remote.computer.name.com
[you may be asked if you want to accept the certificate (once only)]
[you will be prompted for a password]

Now that you are essentially sitting on an "outside" computer, see if 
you can reach any of the computers you think are at risk.

telnet ip-or-domain-name-here 80

Either you get a response which indicates an open port, or it times 
out and you are okay.  You can just hit control-C once you find out 
there's an open port, or if it's taking forever and a day to time out.

Substitute various port numbers for the 80 above and try again:
25 mail servers
22 telnet
23 SSH
80 HTTP

There are lots more.  From 1 to over 65000, actually...
But you'll probably only need to try a handful to be sure.
You can look in a Un*x box' /etc/services file to see which ports are 
for what, usually.

Hope that helps.
-- 
WARNING ri...@ze... email address is an endangered species
Use ce...@l-... instead

>Darren,
>
>>  Hi After to seperate installs now, if I try to access the shell from the
>web
>>  interface I get connection refused. Can anyone shed any light on this?
>Does
>>  it need to be enabled somewhere?
>
>On the webinterface, under Remote Access, there is a checkbox for SSH.  If
>it's checked, you can connect to the IPCop machine using SSH (and the Shell
>from the web interface).

I would add this and the "How come my logs are empty?" to the FAQ...

Only the SourceForge interface has placed a limit on the text box, 
and it's full. :-(

Suggested Remedies?
-- 
WARNING ri...@ze... email address is an endangered species
Use ce...@l-... instead