sqlgrey-users

[Sqlgrey-users] [RELEASE] 1.3.6

[Lionel B. <lio...@bo...>]

Hi,

1.3.6 is available on sourceforge.

New features :
- 2 new greylisting algorithms, use "greymethod = <value>" in 
/etc/sqlgrey/sqlgrey.conf to select the algorithm (Hi Derek !).
- more verbosity control (quiet, verbose, debug), see 
/etc/sqlgrey/sqlgrey.conf.

Attention ;
switching the greylisting algorithms can be done as often as you want, 
but SQLgrey will lose at least parts of its auto-whitelist entries and 
generate new ones.

If you don't want to lose any auto-whitelisting entry you can specify 
"greymethod = full", this is the old greylisting algorithm.
The new ones are :
- "classc" : instead of detecting reconnects from one IP address it only 
considers the class C network (ie: it drops the last byte from the IP 
address).
- "smart" : same as classc but switch to "full" if the rdns is home-user 
alike (ie : the last 2 bytes of the IP address are in the rdns).

I'm currently wondering if I'll add indexes to improve performance 
before 1.4.0, let the users add them themselves or do it in 1.4.x when 
I'll have collected more performance data. I already know adding an 
index on connect.ip_addr will help David Rees, any other ?

Best regards,

Lionel.

Re: [Sqlgrey-users] [RELEASE] 1.3.6

[Derek B. <de...@ba...>]

On Tue, November 30, 2004 14:08, Lionel Bouton said:
> Hi,
>
> 1.3.6 is available on sourceforge.
>
> New features :
> - 2 new greylisting algorithms, use "greymethod =3D <value>" in
> /etc/sqlgrey/sqlgrey.conf to select the algorithm (Hi Derek !).
> - more verbosity control (quiet, verbose, debug), see
> /etc/sqlgrey/sqlgrey.conf.
>
> Attention ;
> switching the greylisting algorithms can be done as often as you want,
> but SQLgrey will lose at least parts of its auto-whitelist entries and
> generate new ones.
>
> If you don't want to lose any auto-whitelisting entry you can specify
> "greymethod =3D full", this is the old greylisting algorithm.
> The new ones are :
> - "classc" : instead of detecting reconnects from one IP address it onl=
y
> considers the class C network (ie: it drops the last byte from the IP
> address).
> - "smart" : same as classc but switch to "full" if the rdns is home-use=
r
> alike (ie : the last 2 bytes of the IP address are in the rdns).

Just upgraded to 1.3.6 and specified 'smart' for the algorithm.  New
connections to the server are adding just the first three bytes of the IP
address to the connect table, as expected, but the old entries in the
connect and *_awl tables still contain the full four bytes for the IP
address.  Do I need to delete/update those entries?  Since the four byte
entries weren't updated on the upgrade I assume this means that reconnect=
s
for the four byte entries will not match (unless I manually update the
tables)?

As an aside, if anyone uses Trustix Secure Linux 2.2 and wants an RPM or
SRPM for 1.3.6 on TSL 2.2 I built them and they're available at:

http://www.battams.ca/software/tsl22/

 - Derek

Re: [Sqlgrey-users] [RELEASE] 1.3.6

[Lionel B. <lio...@bo...>]

Derek Battams wrote the following on 01.12.2004 05:23 :

>
>Just upgraded to 1.3.6 and specified 'smart' for the algorithm.  New
>connections to the server are adding just the first three bytes of the IP
>address to the connect table, as expected, but the old entries in the
>connect and *_awl tables still contain the full four bytes for the IP
>address.  Do I need to delete/update those entries?
>

No, SQLgrey will clean them up automatically (in 24 hours for the 
connect table and 60 days for the others by default), in the meantime it 
will just create new ones.
If your goal is to inspect the table's content easily, you can clean 
them manually :
DELETE FROM <table> WHERE <tstamp_column> < NOW() - INTERVAL '1 DAY';


>  Since the four byte
>entries weren't updated on the upgrade I assume this means that reconnects
>for the four byte entries will not match (unless I manually update the
>tables)?
>  
>

They will not match the old entries (unless 'smart' decides that it 
can't trust the host and uses the whole IP) and create new ones, yes.

>As an aside, if anyone uses Trustix Secure Linux 2.2 and wants an RPM or
>SRPM for 1.3.6 on TSL 2.2 I built them and they're available at:
>
>http://www.battams.ca/software/tsl22/
>  
>

Did you need to change the spec file ?

Lionel.

Re: [Sqlgrey-users] [RELEASE] 1.3.6

[Derek B. <de...@ba...>]

On Wed, December 1, 2004 5:12, Lionel Bouton said:
> Derek Battams wrote the following on 01.12.2004 05:23 :
>
>>As an aside, if anyone uses Trustix Secure Linux 2.2 and wants an RPM o=
r
>>SRPM for 1.3.6 on TSL 2.2 I built them and they're available at:
>>
>>http://www.battams.ca/software/tsl22/
>>
>>
>
> Did you need to change the spec file ?

Yes, I had to change the spec file slightly.  Basically I had to assign a
specific UID to the sqlgrey user (since TSL 2.2 actually assigned a syste=
m
account for sqlgrey) and I also had to create the sqlgrey group if it did
not exist.

I also had to patch init/sqlgrey since the /etc/rc.d/init.d/functions fil=
e
does not exists in TSL 2.2 (it's actually just /etc/init.d/functions).=20
And finally I patched etc/sqlgrey.conf to make SQLite the default databas=
e
(which is how TSL set it up with their 1.2.0 RPM that is included with th=
e
distro).

Nothing serious, just some minor changes.

  - Derek

TSL specfile changes (was Re: [Sqlgrey-users] [RELEASE] 1.3.6)

[Lionel B. <lio...@bo...>]

Derek Battams wrote the following on 01.12.2004 17:52 :

>On Wed, December 1, 2004 5:12, Lionel Bouton said:
>  
>
>> [...]
>>
>>Did you need to change the spec file ?
>>    
>>
>
>Yes, I had to change the spec file slightly.
>

I'll try to put most of your changes in future releases to help minimize 
the amount of patch lines you'll need.

>  Basically I had to assign a
>specific UID to the sqlgrey user (since TSL 2.2 actually assigned a system
>account for sqlgrey) and I also had to create the sqlgrey group if it did
>not exist.
>
>  
>

I'll look into it and see if I can provide a specfile that creates the 
user and the group consistently on both Fedora and TSL.

>I also had to patch init/sqlgrey since the /etc/rc.d/init.d/functions file
>does not exists in TSL 2.2 (it's actually just /etc/init.d/functions).
>  
>

This is valid for Fedora and RedHat since ages too. I just switched to 
/etc/init.d/functions in my source tree.

>And finally I patched etc/sqlgrey.conf to make SQLite the default database
>(which is how TSL set it up with their 1.2.0 RPM that is included with the
>distro).
>
>  
>

I won't touch that : one config file can't fit every distribution, I'll 
rely on people like you for distribution-specific configuration.

Best regards,

Lionel.