ipcop-devel Mailing List for IPCop Firewall

Franck Bourdonnec wrote:
> Le mercredi 30 janvier 2008 19:28, Olaf Westrik a écrit :
>   
>> Gilles Espinasse wrote:
>>     
>>> My suggestion would be to create CONFIG_GREEN, CONFIG_BLUE,
>>> CONFIG_ORANGE, CONFIG_RED by default and put inside the number of
>>> interfaces of corresponding color inside.
>>> This way, it is trivial to test if an interface type is configured and in
>>> the futur, we may have a loop to configure each interface of the same
>>> color.
>>>       
>> I forgot to write that down, I actually considered GREEN_COUNT,
>> BLUE_COUNT etc. But the actual name is not that important. Important is
>> that they will be (always) present and set to 0,1,2 etc.
>>
>> This makes (especially if we make multiple colours someday) testing and
>> loop iteration very easy.
>>
>>
>> Olaf
>>     
>
> Here we come, fixed configuration is bad, un-extandable, un-understandable.
> Better now than never.
>
> The actual mistake you are doing (from1.4) is saying that a logical interface 
> is a physical interface.
>
> Clearly separate the hardware interface with it's own and relevant parameters
> (eg an eth, an isdn, an usb, a wifi, whatever you want) from logical 
> interfaces used in the firewall (red, green(s), ...) then use a bind system
> to say RED is this hardware interfaces, GREEN is that one, ....
>
>
>
> Franck
>
>   
Just to extend that a bit, if VLAN support is every added to the mix 
then multiple GREEN_x logical interfaces could actually bind to the same 
hardware interface.


-- 
  Do not meddle in the affairs of wizards,
  for they are subtle and quick to anger.
                      -- Gildor Inglorion

Le mercredi 30 janvier 2008 19:28, Olaf Westrik a écrit :
> Gilles Espinasse wrote:
> > My suggestion would be to create CONFIG_GREEN, CONFIG_BLUE,
> > CONFIG_ORANGE, CONFIG_RED by default and put inside the number of
> > interfaces of corresponding color inside.
> > This way, it is trivial to test if an interface type is configured and in
> > the futur, we may have a loop to configure each interface of the same
> > color.
>
> I forgot to write that down, I actually considered GREEN_COUNT,
> BLUE_COUNT etc. But the actual name is not that important. Important is
> that they will be (always) present and set to 0,1,2 etc.
>
> This makes (especially if we make multiple colours someday) testing and
> loop iteration very easy.
>
>
> Olaf

Here we come, fixed configuration is bad, un-extandable, un-understandable.
Better now than never.

The actual mistake you are doing (from1.4) is saying that a logical interface 
is a physical interface.

Clearly separate the hardware interface with it's own and relevant parameters
(eg an eth, an isdn, an usb, a wifi, whatever you want) from logical 
interfaces used in the firewall (red, green(s), ...) then use a bind system
to say RED is this hardware interfaces, GREEN is that one, ....



Franck

Gilles Espinasse wrote:

> My suggestion would be to create CONFIG_GREEN, CONFIG_BLUE, CONFIG_ORANGE,
> CONFIG_RED by default and put inside the number of interfaces of corresponding
> color inside.
> This way, it is trivial to test if an interface type is configured and in the
> futur, we may have a loop to configure each interface of the same color.

I forgot to write that down, I actually considered GREEN_COUNT, 
BLUE_COUNT etc. But the actual name is not that important. Important is 
that they will be (always) present and set to 0,1,2 etc.

This makes (especially if we make multiple colours someday) testing and 
loop iteration very easy.


Olaf

-- 

A weizen a day helps keep the doctor away.

Gilles Espinasse wrote:

> Think to a nic actually supported by e1000, but that may be supported by e1000e
> only in the futur (the new e1000 with pci-x only cards), or the actual mess
> between 8139too and 8139cp that share the same PID/VID with two differents
> drivers.

Well yes, but unless the MAC changes udev more or less handles it.


> We really should have more care there (probably save MAC address and have a big
> warning when saved MAC does not match interface MAC).
> I should say even the MAC address of my alpha machine has changed when upgrading
> from debian 2.4.27 to debian 2.6.18 kernel (there was a bug with an extra 0 in
> front and last character was missing). As the IP given by dhcp depend of the
> MAC, the machine did not receive the same address, so I can't miss something has
> changed.

Well yes. I am not sure (yet) how to handle that.
Similar situation probably if one (defective) card is exchanged. Even if 
using the same driver, udev will assign new ethx. So the problem will 
have to be reported by setup.

Maybe report that some configured card is missing and then offer to 
delete the assignment so it can be assigned to the new card.

Will need to play with this, as well as setup handling networking in 
general.


Anyways, there is no point in really testing for ethx before loading a 
driver, since udev will decide.
Only possibility is to check whether the *_DEV is actually present after 
modprobe and generate log message.


cheers Olaf

-- 

A weizen a day helps keep the doctor away.

Selon ow...@us...:

> Revision: 1048
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=1048&view=rev
> Author:   owes
> Date:     2008-01-30 08:47:40 -0800 (Wed, 30 Jan 2008)
>
> Log Message:
> -----------
> No point in checking for eth0,1,2,3 order, udev takes care of that
>
I don't want to introduce FUD but I should say I am really unsure what will
happen with different kernel and udev versions.

Think to a nic actually supported by e1000, but that may be supported by e1000e
only in the futur (the new e1000 with pci-x only cards), or the actual mess
between 8139too and 8139cp that share the same PID/VID with two differents
drivers.

We really should have more care there (probably save MAC address and have a big
warning when saved MAC does not match interface MAC).
I should say even the MAC address of my alpha machine has changed when upgrading
from debian 2.4.27 to debian 2.6.18 kernel (there was a bug with an extra 0 in
front and last character was missing). As the IP given by dhcp depend of the
MAC, the machine did not receive the same address, so I can't miss something has
changed.

Gilles

Selon Olaf Westrik <wei...@ip...>:

>
> Any objections against removing CONFIG_TYPE ?
>
> Defining the network configuration with this 1 variable is too
> inflexible and difficult to remember what 2,3,4,5,6,7 exactly mean.
>
I fully agree this is not practical and painfull to use.
It is some works to replace everywhere but that should not be hard
and simplier to read after.

> For the next step I intend to drop CONFIG_TYPE from ethernet/settings
> and maybe rename GREEN_ BLUE_ etc. to GREEN_1_ BLUE_1_

I don't know for the best scheme to use for the replacement.

This depend if we create every GREEN_1, BLUE_1, ORANGE_1, RED_1 by default or
not. If they are not created by default, we need to check if they exist.

My suggestion would be to create CONFIG_GREEN, CONFIG_BLUE, CONFIG_ORANGE,
CONFIG_RED by default and put inside the number of interfaces of corresponding
color inside.
This way, it is trivial to test if an interface type is configured and in the
futur, we may have a loop to configure each interface of the same color.


Gilles

Any objections against removing CONFIG_TYPE ?

Defining the network configuration with this 1 variable is too 
inflexible and difficult to remember what 2,3,4,5,6,7 exactly mean.



Olaf

-- 

A weizen a day helps keep the doctor away.

Haute SubZero wrote:

> Forgive me if it should be obvious, but does this process allow 
> selection of Green to the NIC of choice or does it continue to be 
> forced?  The explanation sort of hints at choice, but I just wanted to 
> clarify.

choice.
During installation the cards can be assigned (and reshuffled) freely.
As long as you did not finalize the 'colourisation', you can change the 
assignments.

When using setup through SSH (later) we'd probably need to find a way to 
fix that NIC. I intend all others to be freely (re-)assignable.
Not fully sure of the implications yet, we might decide that's easier to 
simple reboot after reshuffling the cards.
But the goal is to have freedom ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

Olaf Westrik wrote:
> Over the last days I finally managed to allocate some time to do 
> something about the installation of the network cards.
>
> I've always wanted the network config to work different from 1.4 and 
> this is (roughly) how it works:
>
> Scan for network cards (using discover) and show list of found cards 
> along with assigned colour. Later the option will be added to manually 
> add (ISA) cards from a list or modprobe a specific module.
>
> After selecting a card from the available list a window will popup 
> showing description, MAC and devicename (and start blinking the NIC LED 
> should that be supported). A list of remaining available colours is 
> shown and selectable.
>
> After some or all cards have been allocated a function, continue with 
> assigning IP addresses etc.
>
>
> I want to drop the necessity for selecting first the config type (G, 
> G+R, G+B, G+O+B etc. etc.) and simply let the assigned cards handle that.
>
>
>
> Olaf
>   
Forgive me if it should be obvious, but does this process allow 
selection of Green to the NIC of choice or does it continue to be 
forced?  The explanation sort of hints at choice, but I just wanted to 
clarify.


-- 
  Do not meddle in the affairs of wizards,
  for they are subtle and quick to anger.
                      -- Gildor Inglorion

On Monday 28 January 2008 16:20, Olaf Westrik wrote:
> Over the last days I finally managed to allocate some time to do
> something about the installation of the network cards.
>
> I've always wanted the network config to work different from 1.4 and
> this is (roughly) how it works:
>
> Scan for network cards (using discover) and show list of found cards
> along with assigned colour. Later the option will be added to manually
> add (ISA) cards from a list or modprobe a specific module.
>
> After selecting a card from the available list a window will popup
> showing description, MAC and devicename (and start blinking the NIC LED
> should that be supported). A list of remaining available colours is
> shown and selectable.


Olaf,

very cool stuff!  Can't wait to try it later today.

IvanK.


>
> After some or all cards have been allocated a function, continue with
> assigning IP addresses etc.
>
>
> I want to drop the necessity for selecting first the config type (G,
> G+R, G+B, G+O+B etc. etc.) and simply let the assigned cards handle that.
>
>
>
> Olaf

Over the last days I finally managed to allocate some time to do 
something about the installation of the network cards.

I've always wanted the network config to work different from 1.4 and 
this is (roughly) how it works:

Scan for network cards (using discover) and show list of found cards 
along with assigned colour. Later the option will be added to manually 
add (ISA) cards from a list or modprobe a specific module.

After selecting a card from the available list a window will popup 
showing description, MAC and devicename (and start blinking the NIC LED 
should that be supported). A list of remaining available colours is 
shown and selectable.

After some or all cards have been allocated a function, continue with 
assigning IP addresses etc.


I want to drop the necessity for selecting first the config type (G, 
G+R, G+B, G+O+B etc. etc.) and simply let the assigned cards handle that.



Olaf

-- 

A weizen a day helps keep the doctor away.

I have fixed 2 problems with glibc on alpha toolchain compilation but we are
still far from something compiling.
Now it fail on toolchain the second binutil compilation due to a problem with
sanitized kernel header.

As Ivan has announced to work on a toolchain upgrade, I will wait for this
upgrade before working again on alpha port.
Those glibc-2.5 patches for alpha are no more needed on glibc-2.7

There is far more important tasks for the users than working on the port for
alpha.

Gilles

Feature Requests item #1880409, was opened at 2008-01-26 19:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1880409&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kevross (kevross_33)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reporting

Initial Comment:
The generation of reports based on security events would be useful such as the snortalog addon does. For instance snortalog, fwlog (the firewall graphing) and so on are useful for analysing attacks.

But an ability to generate executive reports can make identifying issues more efficient (i gave up looking through snort logs initially and manually blocking sources with banish so ended up using a combination of guardian for IPS and snortalog for improved analysis).

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

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

Feature Requests item #1880408, was opened at 2008-01-26 19:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1880408&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kevross (kevross_33)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw packet analysis

Initial Comment:
Hi.

The ability to view more information about a potential attack would be useful. For instance the ability to click on the attack and see all source,destination, attack details as well as the tcpdump output to see if it is a real attack. Such as a buffer overflow with tons of AAAAAAAAAs or ............... then cmd.exe would be a giveaway (though this is overly simplified.

But this ability will aid in security analysis as well as  identifying false positives and actual attacks. But further attack analsis would be useful for snort.

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

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

Bugs item #1876346, was opened at 2008-01-21 11:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1876346&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: 1.4.15
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Markus Kaefer (mkaefer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic DNS update problem

Initial Comment:
If the Option 
"Minimize updates: before an update, compares the dns IP for hostname "[host.]domain" against RED IP." on the Dynamic DNS page is activated and only the last number of the IP-Adress changes IPCOP will not update the IP Address on the Dynamic DNS server.

Example:
81.182.4.123 --> changes to --> 81.182.4.12



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

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

Feature Requests item #1875812, was opened at 2008-01-20 15:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1875812&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kevross (kevross_33)
Assigned to: Nobody/Anonymous (nobody)
Summary: Snort Performance Monitor (perfmon preprocessor)

Initial Comment:
Hi.
   The snort preprocessor perfmon provides information regarding the load on snort as well as dropped packets and so on. I have been looking for a way to use this for ipcop to guage snort performance in order to maximise snort's effectiveness. 

I noticed that smoothwall has an addon (http://community.smoothwall.org/forum/viewtopic.php?t=14049)
to achieve this (though their addon is actually pasting code into files). I was just thinking because smoothwall and ipcop are similar it should be possible on ipcop.

Unfortunately I am no developer as I am in the networking  and security fields so I have no idea where to start. Thanks.

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

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

Gilles Espinasse wrote:

> Selon David W Studeman <avi...@ai...>:
> 
>> On Wednesday 02 January 2008 11:07:01 pm Gilles Espinasse wrote:
>> > ----- Original Message -----
>> > From: avi...@ai...
>> > To: g....@fr...
>> > Sent: Thursday, January 03, 2008 1:48 AM
>> > Subject: Re: [IPCop-devel] Raqcop IPCop On Raq3i, 4i, Symantec
>> > velociraptors etc.
>> >
>> > > I used eepro100 initially but the patched e100 driver seems to
>> > > work as good or better since we get real feedback in dmesg as
>> > > far as autonegotiating the speed and duplex etc. With the
>> > > eepro100, it worked but I had no clue as to what it was really
>> > > doing. As far as you know, will the eepro100 be with the 2.4
>> > > kernel for it's life and only be phased out of 2.6?
>> > > It's been talked about for years. BTW, the new e100 driver
>> > > that I had patched also did not run very well on the 82559er
>> > > chips in these, it would lock up requiring a network reset.
>> > > You mentioned that this driver had mixed results with the 2.4
>> > > kernel so I removed the patch for the e100new driver since I
>> > > don't want anyone to be able to load it on a raq.
>> > > The patched e100 kernel driver works fine.
>> >
> We should report the failure with 3.5.17 as it may replace previous
> in-kernel 2.4 e100 driver a day.
> We would need more details to be able to report on
> www.sourceforge.net/projects/e1000
> 
> In-kernel e100 does not support the last e100 cards (should not be a
> problem in your case) and had some trouble with vlans.
> 
> 
>> > > Might as well keep the eepro100 driver as a backup.
>> >
> We already have two different e100 drivers, should be enought to manage
> that. eepro100 is still in 2.6 for the last days. It should be removed in
> 2.6.25.
> 
>
http://groups.google.co.id/group/linux.kernel/browse_thread/thread/b7a6511bdd959a1d/b0a9c46721ce6594?lnk=raot
> 
> Gilles
> 

Probably a stupid question but how can I get the driver to spit out info as
it is failing? I found that I'm not alone with the lockup problem. I also
know that if I use the eepro100 driver, my logs show that it is reporting
that a lockup bug exists and that it is enabling a workaround. With the
i82559er chips, not much surprises me.


Dave

Feature Requests item #1875373, was opened at 2008-01-19 17:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1875373&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kevross (kevross_33)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of barnyard to imrprove snort performance

Initial Comment:
When snort writes to a database like mysql it has to make the request and so on which slows down snort performance and more important ties it up as it cannot listen on the network while doing this. This could mean dropped packets that are not analysed by snort perhaps resulting in missed information.

Barnyard improves this by allowing snort to write unified logs which is considerably faster while barnyard deals with writing this information to the database meaning snort is not hanging around while writing to the database.

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

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

Eric Oberlander wrote:

> Do we have to modify ntp.conf to remove any restrictions on access, or
> open any ports, to allow clients on the Internet to query the ntpd
> server on an IPCop?

as is now ntpd is available to red (of course only after configuring 
udp/123 in external access).
We'd still need to add some restrictions, so red is similarly restricted 
as green/blue.

I will look into this.


Olaf

-- 

A weizen a day helps keep the doctor away.

On Friday 18 January 2008 16:36, Ivan Kabaivanov wrote:
> On Friday 18 January 2008 15:43, Olaf Westrik wrote:
> > Ivan Kabaivanov wrote:
> > >>> Thinking of architectures, the floppy images do not seem to have
> > >>> $MACHINE in their names...
> >
> > On second thought, we do not distribute these disks, so it is not that
> > important to have $MACHINE in there.
> >
> > > I'll see what I can remove from the ppc root-1 image to bring it back
> > > to the needed size.  I'm including parted (the stand alone program)
> > > which we don't need anymore so I'll remove it, even though I use it
> > > currently for debugging.
> >
> > Probably easiest to drop locale-archive and forget about the languages.
> > One other thing I tried the other day is to strip discover pci-device.xml
> > After removing everything but NICs about 130 KB is left from the initial
> > ~ 2 MB (all uncompressed).
> >
> >
> > Olaf
>
> My first choice would be to reduce libparted the way we reduced libc.  I
> want to keep the languages stuff if possible.
>
> IvanK.
>

Olaf,

as you've seen from my last commit, it's all good now.  I was creating a 20MB 
ext2 image for the ppc root-1.img because that's roughly how much is needed 
if all five floppies are loaded.  Even though the actual stuff in root-1.img 
was taking about 3.5MB the zeros could not be compressed enough.  So now I'm 
creating just a 4MB image and putting the root-1.img stuff in it and I'll 
modify the floppy init to mount /lib/modules/KVER/kernel/drivers as tmpfs so 
we have enough space for the extra modules if needed.  This is the best 
approach and I should have done it from the beginning.  Now the ppc floppy 
can keep all the x86 features.

All this affects the ppc floppy.

I still want to reduce the installer footprint.  My goal as I've stated a few 
times is for the installer to work on 32MB systems.

IvanK.

On Friday 18 January 2008 15:43, Olaf Westrik wrote:
> Ivan Kabaivanov wrote:
> >>> Thinking of architectures, the floppy images do not seem to have
> >>> $MACHINE in their names...
>
> On second thought, we do not distribute these disks, so it is not that
> important to have $MACHINE in there.
>
> > I'll see what I can remove from the ppc root-1 image to bring it back to
> > the needed size.  I'm including parted (the stand alone program) which we
> > don't need anymore so I'll remove it, even though I use it currently for
> > debugging.
>
> Probably easiest to drop locale-archive and forget about the languages.
> One other thing I tried the other day is to strip discover pci-device.xml
> After removing everything but NICs about 130 KB is left from the initial
> ~ 2 MB (all uncompressed).
>
>
> Olaf


My first choice would be to reduce libparted the way we reduced libc.  I want 
to keep the languages stuff if possible.

IvanK.

Ivan Kabaivanov wrote:

>>> Thinking of architectures, the floppy images do not seem to have
>>> $MACHINE in their names...

On second thought, we do not distribute these disks, so it is not that 
important to have $MACHINE in there.


> I'll see what I can remove from the ppc root-1 image to bring it back to the 
> needed size.  I'm including parted (the stand alone program) which we don't 
> need anymore so I'll remove it, even though I use it currently for debugging.

Probably easiest to drop locale-archive and forget about the languages.
One other thing I tried the other day is to strip discover pci-device.xml
After removing everything but NICs about 130 KB is left from the initial 
~ 2 MB (all uncompressed).


Olaf

-- 

A weizen a day helps keep the doctor away.

On Wednesday 16 January 2008 15:37, Ivan Kabaivanov wrote:
> On Wednesday 16 January 2008 15:29, Olaf Westrik wrote:
> > Ivan Kabaivanov wrote:
> > > go ahead and make the changes.  You can rename the root floppies if you
> > > want to.  I'll test on ppc to make sure the ppc images fit on floppies.
> >
> > Currently root-1 is 1218 KByte, root-2 is 1350 KByte
> > Should there not be enough space for ppc, we can always drop language
> > support for floppy boot. Or drop it for ppc only.
> >
> > Thinking of architectures, the floppy images do not seem to have
> > $MACHINE in their names...
>
> Olaf,
>
> good point.  I wanted to include it, but thought the filenames might get
> too long.  But I guess it's better to include MACHINE.
>
> I'll test the ppc floppies later today.
>
> IvanK.
>
> > cheers Olaf


Olaf,

I was afraid this might happen.  These are the freshly built ppc floppies.  
Actually this is in my experimental tree where I'm doing gcc-4.2.2, glibc-2.7 
and all kinds of other crazy stuff, but I suspect even in the current SVN the 
ppc floppies are over 1.4MB.

-rw-r--r-- 1 root root 7301433 2008-01-18 06:02 cdinitramfs-1.9.img
-rw-r--r-- 1 root root 1474560 2008-01-18 06:02 ipcop-1.9-boot.img
-rw-r--r-- 1 root root 1440209 2008-01-18 06:02 ipcop-1.9-network-drivers.img
-rw-r--r-- 1 root root 1511688 2008-01-18 06:02 ipcop-1.9-root-1.img
-rw-r--r-- 1 root root 1464340 2008-01-18 06:02 ipcop-1.9-root-2.img
-rw-r--r-- 1 root root 1459790 2008-01-18 06:02 ipcop-1.9-scsi-drivers.img

Like I wrote initially, the balance between x86 and ppc floppies was very 
fragile.

I'll see what I can remove from the ppc root-1 image to bring it back to the 
needed size.  I'm including parted (the stand alone program) which we don't 
need anymore so I'll remove it, even though I use it currently for debugging.

IvanK.

Feature Requests item #1873341, was opened at 2008-01-16 19:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1873341&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Next major version
Status: Open
Priority: 5
Private: No
Submitted By: Ed Sanford (ed34222)
Assigned to: Nobody/Anonymous (nobody)
Summary: Integration of Hogwash IPS

Initial Comment:
Integration of something like the Hogwash IPS would be handy.  Unlike guardian, it modifies bad packets to prevent successful intrusion instead of blocking the offending site outright.

Also, it would be cool if there was a way to have specific rules active for logging and/or Hogwash; but, inactive for specific add-ons (Guardian for example).

Some rules clearly indicate a bad site, others are just bad packets that could still be coming from a good site.
In the case of the former, we want to be able to block the bad sites; but, in the latter, we want to just block or alter the bad packets so they can't do any harm.

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

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

Bugs item #1873336, was opened at 2008-01-16 19:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1873336&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Security (Patches etc)
Group: 1.4.18
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ed Sanford (ed34222)
Assigned to: Nobody/Anonymous (nobody)
Summary: Snort Problems

Initial Comment:
Getting the "Invalid loaded file" message after clicking "Download new ruleset"

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

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