ipcop-devel Mailing List for IPCop Firewall

Mark,

So when do we launch?  What still needs to be done before we actually
release this to the general public and launch the website?  How do I get
access to upload to ipcop.sourceforge.net?

How does one get listed as a distro and firewall on linux.org?




----- Original Message -----
From: "Mark Wormgoor" <ma...@wo...>
To: <ipc...@li...>
Sent: Monday, December 31, 2001 04:00
Subject: Re: [IPCop-devel] IP Cop Website


> Hanno,
>
> > I've got a framework for the website done, please check it out and let
me
> > know what changes ya'll think should be made.
> >
> > http://ipcop.boater.com
>
> I like the overall look.  I have shamelessly ripped your menu structure
> partly and have created this:
> http://ipcop.sourceforge.net/cgi-bin/twiki/view/IPCop/WebHome
>
>  > I changed the logo a bit and would like some feedback.  What's the font
> for
> > the lettering in the title bar?  I think the current title bar/logo bar
> > takes up to much space, especially at 800x600 monitor resolution.
> I agree on this.  We should change the title bar.  If we do it now, it can
> go into the v0.1 release.
>
> Kind regards,
>
>
>         Mark Wormgoor
>
>
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

Guys,

	grep -i dhcp /var/log/messages only returned very basic stuff
i.e the web address of the dhcpd authors and ACK's for my GREEN NIC.

I carried out the mod...

cd /etc/dhcpc
ln -s ../rc.d/rc.updatered dhcpcd-eth0.exe
ln -s ../rc.d/rc.updatered dhcpcd-eth1.exe
ln -s ../rc.d/rc.updatered dhcpcd-eth2.exe

With no effect. However I have still not managed to locate the error
messages in the log files so, (don't laugh!), I resorted to a digital
camera screen shot! Lol

So currently the error messages are:
____________________________________________
Bringing netrwork up
Eth0: Initial media type Autonegotiate
Eth0: MII #24 status 782d, link partner capability 0021, setting half
duplex.
/etc/rc.d/rc.sysinit: /usar/local/sbin/fhcpcd: No such file or directory
Setting up firewall
Settign DMZ pinholes
Updating RED...
Unable to read file /etc/dhcpc/dhcpcd-eth2.info at /var/ipcop/header.pl
line 437
.
Unable to read file /etc/dhcpc/dhcpcd-eth2.info at /var/ipcop/header.pl
line 437
.
/etc/rc/d/rc.updatered: /etc/dhcpc/dhcpcd-eth2.info: No such file or
directory
____________________________________________

Also can someone tell me how to locate these types of messages on my box
cause I really don't want to keep typing them :(

Lastly, Mark you refer to "(Noted as bug #7)". Are these online
somewhere? Am I just being stupid and missing them?


Thanks again for all your help,

	Mark (fat)









-----Original Message-----
From: ipc...@li...
[mailto:ipc...@li...] On Behalf Of Mark
Wormgoor
Sent: 30 December 2001 19:11
To: ipc...@li...
Subject: Re: [IPCop-devel] Cannot obtain DHCP lease on RED NIC


Mark,


> Initial installation report of IPCop V0.0.9
> 
> Entire installation went flawlessly with one, albeit crucial, caveat.
> 
> I cannot make my RED NIC, (eth2), obtain a lease from my ISP, (cable),

> DHCP server.
> 
> The normal procedure when changing the NIC is to power of the modem. 
> Leave it for 2 minutes and then power up.
> 
> The modem then re-registers the MAC address of the NIC, (in this case 
> my IPCop RED interface), and the DHCP server re-issues a lease.
> 
> However this should not be necessary as I am using EXACTLY the same 
> configuration and hardware as my existing SW box (i.e. a 
> reinstallation).
> 
> Reinstalling SW 0.9.9. SE obtains an IP address instantaneously with 
> no power down.
> 
> The login messages report a number of missing files in /etc/dhcpcd/. 
> [Unfortunately I cannot locate these messages in any of the log files 
> - suggestions?]
> 
> Can anyone shed some light on a next step to try.

cd /etc/dhcpc
ln -s ../rc.d/rc.updatered dhcpcd-eth0.exe
ln -s ../rc.d/rc.updatered dhcpcd-eth1.exe
ln -s ../rc.d/rc.updatered dhcpcd-eth2.exe

(Noted as bug #7)

Kind regards,


        Mark Wormgoor



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

Hanno,

> I've got a framework for the website done, please check it out and let me
> know what changes ya'll think should be made.
>
> http://ipcop.boater.com

I like the overall look.  I have shamelessly ripped your menu structure
partly and have created this:
http://ipcop.sourceforge.net/cgi-bin/twiki/view/IPCop/WebHome

 > I changed the logo a bit and would like some feedback.  What's the font
for
> the lettering in the title bar?  I think the current title bar/logo bar
> takes up to much space, especially at 800x600 monitor resolution.
I agree on this.  We should change the title bar.  If we do it now, it can
go into the v0.1 release.

Kind regards,


        Mark Wormgoor

Ah IDS - my favourite topic :-)

> First off, to properly monitor your firewall, you must stay up on
> different types of attacks. Keeping the Intrusion Detection System up
> to date is one way of doing this. If you monitor the IDS logs, they
> will be identifying the type of attack and classifying it for you.
>
> This is already part of IP Cop.
The one thing that really got to me about SW was the fact that the IDS
reporting
looked good, but really didnt allow you to do much more than list a
historical
view of history.

IDS is still a human intensive act. And to run IDS properly and maintain
proper
security it is very costly. Firstly you should keep a rolling log of all
your packets
going past your sensor, extract all of the packets that match the rulesets.
Once
you have an intrusion attempt you have your security team work back through
the logs to determine the attempt. As a result this is generally only used
in
military (only some!) and large corporations that like to keep secrets.

Runing Snort on a low end firewall device with lowend user knowledge will
only get half the job done. But in defensive half a job is better that none,
in particular if it detects you are being used as an attack platform
(Nimba/CR/Lion etc)
then you are at least ware of the issue!


> > If there's Snort log analysis tools, let's get them in there as well,
> > and automate them.
> >
> > Example:
> > If a bunch of ports are being sniffed in a short time-frame, *OR* in
> > too "regular" (timing-wise) a pattern, IPCop should do a reverse DNS
> > lookup on the IP address and email the admin about it with
> > suggestions on how to contact a person in authority over that
> > machine.  They admin can, perhaps, "allow" some IPs to be doing
> > things regularly.  IE, if they are port-forwarding to an ORANGE
> > web-server, and somebody has a cron job to check their web-site
> > daily, that should not, after the admin says so, notify them every
> > time it happens.
>
> Well, much of the time, those IP addresses are spoofed and don't belong
> to the machine that the attack is coming from.

Actually its not trivial to spoof IP connections, so more likely than not
I would expect a TCP connection to be accurate. Not to say that the
attack originated from there, but the device was probably used as a
springboard (anon-proxy, compromized host)

Now there is a number of systems out there that can be used to collect
results sets and get results for:

http://www.dshield.org/howto.html
https://predictor.securityfocus.com/
MyNetwatch man is another

Personally I like the SANS one. To me this would be a nice to have.

> There are infinite ways to attack your machine. We know about a finite
> number of them. Thinking we can know about all of them is naive. That
> is why you must monitor your logs. To look for patterns. Humans are
> good at that, machines are lousy at it. Machines are only good at
> detecting patterns once they have been taught to do so by a human that
> noticed that pattern. Machines don't catch new patterns well at all.
Very true - at least the honey hots volunteers help update the rules :-)

Gareth

> > > > > To my mind the recent IIS exploits prove that people generally
dont
> > > > > update their servers to the appropriate patch level, which
> > > > > generally leaves the machines open to abuse. They spend time
> > > > > ensuring it is safe, and once it
>
> Remember that the exploit never checked the HTTP headers but just attacked
> any host.  Same goes for most other HTTP exploits.  It's mostly useless to
> change the headers.  Besides, we're probably going with a non-standard
> webserver on the next release.
> http://www.acme.com/software/mini_httpd/
> Source is only 35KB :-)
>

Very true, but that is related to the fact that the worms were not
particularly clever in their attack scenarios, and they plain blasted
verything. My point was more to the fact that people didnt update their
servers. Now if you take "Whisker" for example and use it against an IIS
server that exposes the M$ Servername it runs through a ton of checks, if
the Servername is missing it doesnt actually check anything at all. This is
a blatantly a bug with Whisker (that I reported to RainForest) but it shows
that the 'information' we give out can be used against us :-)

Also most of the Apache logs were not touched as most are configured to be
virtual hosting features that most have turned on, and as such using the IP
address as the  web address to connect the machine wont work. So anything
will an HTTP accelerator (ISA/Apache/Squid)/or virtual hosting solution were
not touched by the recent worms as the worm couldnt connect to the server.

As far as mini_httpd goes how much exposure has this had compared to Apache?
Presumably since the source is so small we could audit it, and report any
issues with it.

On an related note does mini_httpd support upload? I quickly scanned the
source and didnt notice that in there (not it say its not), I presume you
already have a working version at home :-)

> > That is why the update is not automated.  The user should ALWAYS decide
> for
> > themselves what they want to do.  Normally, however, I would see us
> > informing all registered users of updates.  The registration is optional
> of
> > course and only so that they can better assist us and themselves in the
> > future.
>
> Subscribe to IPCop-announce.  I will only send announcements there from
now
> on.  We should state this clearly on the webpage though.
Definitely!

At 9:40 PM -0800 12/30/01, Hanno Ginn wrote:
>I've got a framework for the website done, please check it out and let me
>know what changes ya'll think should be made.
>
>http://ipcop.boater.com
>
>I changed the logo a bit and would like some feedback.  What's the font for
>the lettering in the title bar?  I think the current title bar/logo bar
>takes up to much space, especially at 800x600 monitor resolution.
>
>I'm going to work on the forums some more tonight and I'm pretty sure I can
>get them done by the end of the evening or tomorrow morning.  It's going a
>bit slower than I expected as this is the first time I've written anything
>in PHP.

The first page is looking great, Hanno. I tried to get to the 
documentation page, since that's my bailiwick and wound up with a 
link pointing into your private 192.168 network.  Don't know if 
there's anything there to look at anyhow, since I'm still figuring 
out how to get stuff uploaded to sourceforge.

Hi All,

I've got a framework for the website done, please check it out and let me
know what changes ya'll think should be made.

http://ipcop.boater.com

I changed the logo a bit and would like some feedback.  What's the font for
the lettering in the title bar?  I think the current title bar/logo bar
takes up to much space, especially at 800x600 monitor resolution.

I'm going to work on the forums some more tonight and I'm pretty sure I can
get them done by the end of the evening or tomorrow morning.  It's going a
bit slower than I expected as this is the first time I've written anything
in PHP.

Please send content.

Hanno Ginn

Hi!

Thanks, thanks, thanks!  

After having a (ridiculous) e-mail conversation with Richard Morrell
fairly recently, and having been excited about Smoothwall 0.9.9, I'm
VERY happy to see IPcop in action.

Please _do_not_ view the following as unconstructive criticism!  ...and
I will help in any way I can!

As if you haven't enough commentary from the peanut gallery, ;>) ,
here's more...

I have been evaluating various firewalls of late...due to frustrations
with RM.

I downloaded the .iso today (12/30/01) and used that.

I have built three test boxes; all of similar configuration.  I used a
pair of D-Link (RTL8139) NICs in the first and a pair of Intel Pro 100s
in the second (82557) while testing IPcop.  Both were Intel 233MMX
Pentium, 48MB and 80MB of RAM.  

Network Config:

Internet <---> ISDN_Router <--DMZ--> IPcop <---> Internal_LAN

DMZ = Static IPs 198.182.115.32/29
Int_LAN = 192.168.1.0/24
ISDN_Router = DOD = 198.182.115.33
Production Firewall = Smoothwall 0.9.9 = 198.182.115.38

I swapped out my production firewall and noted these problems:

Main Page:
	No link to IPcop web site ;-)

Information Panel:
	dhcpd running/working but panel shows stopped

Services Panel:
	Enabling Transparent Web Proxy caused Internet connection to
fail!

Updates Panel:
	"Could not download the available updates list."

IDS Panel:
	Enabling Snort doesn't seem to work.  No daemon, no log.


Can I help with further testing?  Need any more info from me?

THANKS AGAIN!

G

______________________________________________________________
Gene Cooper
Sonora Communications, Inc.
5531 N. Oracle Road
Tucson, AZ 85704
(520) 293-8461
gc...@so...

On Sunday 30 December 2001 17:03, you wrote:

> >1. That will be very bandwidth intensive, since you'd have to
> > actually retrieve the file to checksum it each time. If you did
> > this on a cron job, they could make sure the correct file is in
> > place at the correct time...

> Okay, let's make it a random-timed job, not cron.  Or, rather, cron a
> job every minute that has a 1 in 60*60*24 chance of firing off the
> script that actually downloads and check-sums.

The .ISO is curently 25 meg.

> I dunno how big IPCop is going to get, but Harry's docs say it's
> currently at 5 Mb.  Not trivial, but not a *huge* drain on resources.
>
> >2. What about unofficial copies being distributed by various means?
>
> Perhaps some sort of logo for official mirrors could be designed, and
> only mirrors that have checked in can legally display it.  Obviously,
> a malicious user is not going to be "stopped" by the logo, but as a
> public education measure to make them aware of the importance of
> using an official release, it might be worth considering.

I suggest that for now we let all official releases come from 
SourceForge. They don't seem to have any kind of bandwidth or 
connectivity problems and that's the typical scenario for needing 
mirroring.

Plus, the more downloads and web site traffic you have on FS, the 
higher your activity percentage goes.

>I think that if we do something of this nature we had better be sure that
>the offered patch does not adversly effect IPCops security.  True, these
>patches are not from us, however, we would be offering them from our site.
>Thus we would need a solid disclaimer and need to verify to the best of our
>ability that they are safe for the user before offering them.

Perhaps patches could be segmented into "vetted", "rejected", and 
"un-vetted" rather than having un-vetted patches not available at all.

Otherwise, you'll just have people setting up umpteen different 
servers to get the un-vetted patches, with no co-ordination or rhyme 
nor reason.

Download popularity could also be tracked to make a guesstimate about 
which patches should be given priority for the review process.

Spending hours of precious security-developer time on a patch only 5 
people use is not wise.  Which is not to say that the most popular 
ones *HAVE* to get reviewed -- Just a metric to help the reviewers 
decide what they want to do.

"Rejected" patches should probably have a comments field available 
about why they failed the review process.  Anything from "too long 
and complicated to vet properly" to "buffer overflow in line 42"

One huge problem with SW was that half the crap you needed to make it 
useful (Official Unofficial FAQ) was off somewhere else where you 
couldn't find it.  I don't think there's any chance of IPCop getting 
anywhere *NEAR* that low, of course.  But this is not rocket science 
to provide end-users with the information they need to make an 
informed decision while still maintaining acceptable security levels.
-- 
WARNING ri...@ze... email address is an endangered species
Use ce...@l-... instead

>1. That will be very bandwidth intensive, since you'd have to actually
>retrieve the file to checksum it each time. If you did this on a cron
>job, they could make sure the correct file is in place at the correct
>time...

Okay, let's make it a random-timed job, not cron.  Or, rather, cron a 
job every minute that has a 1 in 60*60*24 chance of firing off the 
script that actually downloads and check-sums.

I dunno how big IPCop is going to get, but Harry's docs say it's 
currently at 5 Mb.  Not trivial, but not a *huge* drain on resources.

>2. What about unofficial copies being distributed by various means?

Perhaps some sort of logo for official mirrors could be designed, and 
only mirrors that have checked in can legally display it.  Obviously, 
a malicious user is not going to be "stopped" by the logo, but as a 
public education measure to make them aware of the importance of 
using an official release, it might be worth considering.
-- 
WARNING ri...@ze... email address is an endangered species
Use ce...@l-... instead

Mark,


> Initial installation report of IPCop V0.0.9
> 
> Entire installation went flawlessly with one, albeit crucial, caveat.
> 
> I cannot make my RED NIC, (eth2), obtain a lease from my ISP, (cable),
> DHCP server.
> 
> The normal procedure when changing the NIC is to power of the modem.
> Leave it for 2 minutes and then power up.
> 
> The modem then re-registers the MAC address of the NIC, (in this case my
> IPCop RED interface), and the DHCP server re-issues a lease.
> 
> However this should not be necessary as I am using EXACTLY the same
> configuration and hardware as my existing SW box (i.e. a
> reinstallation).
> 
> Reinstalling SW 0.9.9. SE obtains an IP address instantaneously with no
> power down.
> 
> The login messages report a number of missing files in /etc/dhcpcd/.
> [Unfortunately I cannot locate these messages in any of the log files -
> suggestions?]
> 
> Can anyone shed some light on a next step to try.

cd /etc/dhcpc
ln -s ../rc.d/rc.updatered dhcpcd-eth0.exe
ln -s ../rc.d/rc.updatered dhcpcd-eth1.exe
ln -s ../rc.d/rc.updatered dhcpcd-eth2.exe

(Noted as bug #7)

Kind regards,


        Mark Wormgoor

At 04:41 PM 12/30/2001 +0000, Fatboy wrote:
>The login messages report a number of missing files in /etc/dhcpcd/.
>[Unfortunately I cannot locate these messages in any of the log files -
>suggestions?]

I would suggest running:

grep -i dhcp /var/log/messages

and sending the result to the list or at least myself and Mark W.

--- eric

Initial installation report of IPCop V0.0.9

Entire installation went flawlessly with one, albeit crucial, caveat.

I cannot make my RED NIC, (eth2), obtain a lease from my ISP, (cable),
DHCP server.

The normal procedure when changing the NIC is to power of the modem.
Leave it for 2 minutes and then power up.

The modem then re-registers the MAC address of the NIC, (in this case my
IPCop RED interface), and the DHCP server re-issues a lease.

However this should not be necessary as I am using EXACTLY the same
configuration and hardware as my existing SW box (i.e. a
reinstallation).

Reinstalling SW 0.9.9. SE obtains an IP address instantaneously with no
power down.

The login messages report a number of missing files in /etc/dhcpcd/.
[Unfortunately I cannot locate these messages in any of the log files -
suggestions?]

Can anyone shed some light on a next step to try.

Thanks in advance,

	Mark (fat) 

Mark,
the alternative to a keyboard could be only the electronics of an old
keyboard.
(means you use only the pcb, should fit in an 5,25" slot of the pc)

I've done it here, and can put a picture on my webpage.

Onother idea would be an led connected to the serial port

helmet

Helmut Schleyer
metatalk
Communication At Work
www.metatalk.de
Tel 09761-398880

> -----Ursprüngliche Nachricht-----
> Von: ipc...@li...
> [mailto:ipc...@li...]Im Auftrag von Mark
> Wormgoor
> Gesendet: Sonntag, 30. Dezember 2001 15:38
> An: ipc...@li...
> Betreff: Re: [IPCop-devel] An idea for IPCOP: tleds and sleds for
> on-offline - status
>
>
> Helmut,
>
> > inspired by the router-project www.fli4l.de , I've made a
> little thing for
> > IPCop.
> >
> > Using sleds and tleds the keyboard could show the status of the
> > red-connection.
> >
> > The modifications and the two files could be found at
> www.metatalk.de/ipcop/
> >
> > Maybe this could be usefull for IPCOP.
> >
> > Please tell me what you think about it.
>
> Well, I like the idea.  However, I don't think we should include
> it in IPCop
> (perhaps other people have other ideas?).  Most people (I think)
> don't have
> a keyboard attached to their machine, or look at it regularly.
>
> We can setup a contributions/links/patches page though and link to your
> page.
>
> Kind regards,
>
>
>         Mark Wormgoor
>
>
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

Mark,

----- Original Message -----
From: "Mark Wormgoor" <ma...@wo...>
To: <ipc...@li...>
Sent: Sunday, December 30, 2001 3:38 PM
Subject: Re: [IPCop-devel] An idea for IPCOP: tleds and sleds for
on-offline - status


> Helmut,
>
> > inspired by the router-project www.fli4l.de , I've made a little thing
for
> > IPCop.
> >
> > Using sleds and tleds the keyboard could show the status of the
> > red-connection.
> >
> > The modifications and the two files could be found at
> www.metatalk.de/ipcop/
> >
> > Maybe this could be usefull for IPCOP.
> >
> > Please tell me what you think about it.
>
> Well, I like the idea.  However, I don't think we should include it in
IPCop
> (perhaps other people have other ideas?).  Most people (I think) don't
have
> a keyboard attached to their machine, or look at it regularly.
>
> We can setup a contributions/links/patches page though and link to your
> page.
>

I think that if we do something of this nature we had better be sure that
the offered patch does not adversly effect IPCops security.  True, these
patches are not from us, however, we would be offering them from our site.
Thus we would need a solid disclaimer and need to verify to the best of our
ability that they are safe for the user before offering them.

chuck

Helmut,

> inspired by the router-project www.fli4l.de , I've made a little thing for
> IPCop.
>
> Using sleds and tleds the keyboard could show the status of the
> red-connection.
>
> The modifications and the two files could be found at
www.metatalk.de/ipcop/
>
> Maybe this could be usefull for IPCOP.
>
> Please tell me what you think about it.

Well, I like the idea.  However, I don't think we should include it in IPCop
(perhaps other people have other ideas?).  Most people (I think) don't have
a keyboard attached to their machine, or look at it regularly.

We can setup a contributions/links/patches page though and link to your
page.

Kind regards,


        Mark Wormgoor

Hi
inspired by the router-project www.fli4l.de , I've made a little thing for
IPCop.

Using sleds and tleds the keyboard could show the status of the
red-connection.

The modifications and the two files could be found at www.metatalk.de/ipcop/

Maybe this could be usefull for IPCOP.

Please tell me what you think about it.

helmet



Helmut Schleyer
metatalk
Communication At Work
sch...@me...
www.metatalk.de
Tel 09761-398880

Helmut Schleyer
metatalk
Communication At Work
www.metatalk.de
Tel 09761-398880

Hi
inspired by the router-project www.fli4l.de , I've made a little thing for
IPCop.

Using sleds and tleds the keyboard could show the status of the
red-connection.

The modifications and the two files could be found at www.metatalk.de/ipcop/

Maybe this could be usefull for IPCOP.

Please tell me what you think about it.

helmet



Helmut Schleyer
metatalk
Communication At Work
sch...@me...
www.metatalk.de
Tel 09761-398880

Mark,

----- Original Message -----
From: "Mark Wormgoor" <ma...@wo...>
To: <ipc...@li...>
Sent: Sunday, December 30, 2001 10:46 AM
Subject: Re: [IPCop-devel] IPCop v0.0.9 release


> Hi,
>
> > > With scanning tools commonly available that tell you exactly what
> > > version you are running without it telling you, it's nearly a moot
> > > point. Combine that with the typicaly script kiddie simply blasting
> > > every machine around looking for a specific entry point means that in
> > > general, finesse is neither part of the game of most crackers, and if
> > > it is part of their game, it's a simple hump to get over.
> > >
> > > I'll agree that it's not optimal, but it's not really much of a
problem.
> >
> > Could you point me to one such tool?  It would be of great help.
However,
> I
> > have yet to find one.
>
> nmap
> It allows for setting port ranges and IP ranges.

I was speaking of a package that could tell you what service was running on
a non-standard port if you were to change/remove the tag.

>
> > > > > To my mind the recent IIS exploits prove that people generally
dont
> > > > > update their servers to the appropriate patch level, which
> > > > > generally leaves the machines open to abuse. They spend time
> > > > > ensuring it is safe, and once it
>
> Remember that the exploit never checked the HTTP headers but just attacked
> any host.  Same goes for most other HTTP exploits.  It's mostly useless to
> change the headers.  Besides, we're probably going with a non-standard
> webserver on the next release.
> http://www.acme.com/software/mini_httpd/
> Source is only 35KB :-)

Sounds good.  Apache is a bit more than what is needed for IPCop.

chuck

Hi,

> > With scanning tools commonly available that tell you exactly what
> > version you are running without it telling you, it's nearly a moot
> > point. Combine that with the typicaly script kiddie simply blasting
> > every machine around looking for a specific entry point means that in
> > general, finesse is neither part of the game of most crackers, and if
> > it is part of their game, it's a simple hump to get over.
> >
> > I'll agree that it's not optimal, but it's not really much of a problem.
>
> Could you point me to one such tool?  It would be of great help.  However,
I
> have yet to find one.

nmap
It allows for setting port ranges and IP ranges.

> > > > To my mind the recent IIS exploits prove that people generally dont
> > > > update their servers to the appropriate patch level, which
> > > > generally leaves the machines open to abuse. They spend time
> > > > ensuring it is safe, and once it

Remember that the exploit never checked the HTTP headers but just attacked
any host.  Same goes for most other HTTP exploits.  It's mostly useless to
change the headers.  Besides, we're probably going with a non-standard
webserver on the next release.
http://www.acme.com/software/mini_httpd/
Source is only 35KB :-)

> That is why the update is not automated.  The user should ALWAYS decide
for
> themselves what they want to do.  Normally, however, I would see us
> informing all registered users of updates.  The registration is optional
of
> course and only so that they can better assist us and themselves in the
> future.

Subscribe to IPCop-announce.  I will only send announcements there from now
on.  We should state this clearly on the webpage though.

Kind regards,


        Mark Wormgoor

On Saturday 29 December 2001 22:23, you wrote:

> Even better would be any tools to automate the process as much as
> possible.  Most people installing IPCop (A) are cheap/broke and (B)
> can't handle a more complicated firewall. 

Take a look here.

http://acidlab.sourceforge.net/

> As much as possible IPCop
> should self-monitor and tell them when a break-in is being attempted
> and what to do about it.

See all those things in your firewall logs? Those are pretty much ALL 
breaking attempts. ;-)

>>  How long could ipcop.org remain hijacked and none of you security
>>  gurus notice it?
>
>If it's hijacked for a small region and not the entire planet, it could
>go on for months and effect thousands of users. IMO, that is unlikely.

Perhaps mirror sites should be audited by a cron job to ensure that 
their .iso file is the same as the master[s].

That certainly seems better than the "single point of failure 
(intrusion)" model to me.

Of course, now that audit itself is subject to attack, but if there 
are a handful of machines doing independent audits, or even if the 
mirror itself is doing the auditing as part of its process, it would 
only take one pair of eyeballs to detect something wrong in that cron 
job, and we'd know it.
-- 
WARNING ri...@ze... email address is an endangered species
Use ce...@l-... instead

>>  If current IDS tools (whatever those are) aren't detecting "slow"
>>  port-scans, can we fix them?
>
>The people that make Snort are some of the best security people in the
>world. If you have ideas about how to make it better, go join their
>team and help them. It's not trivial and they've been at it for a
>while, so they've covered all of the easy bases, most of the hard
>basess and some of the nearly impossible ones.

I did not intend to come off the smart-ass -- I was merely trying to 
stimulate conversation from others who know way more than I do.

>>  How tricky could it be to detect
>>  connections that occur at specific intervals?
>
>It's not tricky, the problem is that when you lower the thresholds to
>the point where they are being detected, then the IDS thinks everything
>is a slow scan and reports on it.

I guess I was suggesting that a slow scan should be detectable by 
noting the time interval as robot-like, rather than just raw 
frequency of connection attempts over a given period (which I thought 
was how Snort worked ATM...)
[Disclaimer: Haven't had time to really dig into Snort.]

Or are the script-kiddies already *all* randomizing their timing of 
connections as well as port sequence order?  Or does network latency 
make a hash of any interval detection?

Is something like this what a human could spot instead?

>There are infinite ways to attack your machine. We know about a finite
>number of them. Thinking we can know about all of them is naive. That
>is why you must monitor your logs. To look for patterns. Humans are
>good at that, machines are lousy at it. Machines are only good at
>detecting patterns once they have been taught to do so by a human that
>noticed that pattern. Machines don't catch new patterns well at all.

So, what can an IPCop user ignore, and what should they look for? 
Are there any guide-lines of what Snort doesn't detect, but that a 
human would spot right off?

I realize they can't be too trivial, or Snort would already be doing 
it:  But if that's the case, the average IPCop user probably will be 
wasting their time looking at their logs, simply because they don't 
have the experience to know what to look for.  If we can't tell them 
what to look for, the logs aren't communication, they're just noise. 
:-)

Should they simply assume that what they see in the beginning is 
probably "normal" and they should watch for "unusual" things after a 
week or so?

Can we tell them which Snort messages are expected, and normal?

Bottom Line: "Monitor your log files" needs some explanation in the 
docs, but I haven't the foggiest idea what to write there.

Disclaimer: Maybe I'm just gun-shy since my SW 0.9.8 logs are about 
5M per hour, and there's simply no way I can monitor that in any sane 
way.  Stupid Ameritech cable-modem.
-- 
WARNING ri...@ze... email address is an endangered species
Use ce...@l-... instead

http://www.scaramanga.co.uk/fwmon/