Re: [squid-users] Record all traffic option?

1 2 and 3 looks a lot like snort functionality to me......

Regards
Mike Cudmore
GSI & Intranet Connectivity Team

>>> "la. w" <squid-user@tlinx.org> 02/04/03 11:41pm >>>
Last time I asked about this I got the impression that I was 'on my
own' and this functionality wasn't included in a standard squid
distribution:

In rough order of complexity:

1) Be able to log squid traffic to a file: not just headers or status,
but content of requests, posts, cookies, and responses to such.
        ex.
                log "all_traffic" (require quotes, " or
')

2) Allow more than files:
        examples:
                log "|my_logger_prog
                log "|user@host:remoteprog args"
        
3) separate for 'from clients' / 'from servers'
        ex:
                log from [all] clients "äll_client_traff"
                log from [all] servers "all_server_traff"

        (3a) This could be evolved orthogonally with filter specs using
etherfind or ethereal type grammars (presumably, one more appropriate
for squid, but this is a tangent).

4) redirection (filtering), io-capture, _with_ _session_ _support_.
        Conceptually, the simplest would be 1 process that handles 1
        request at a time using 2 or 4 pipes (1 or 2 channels).

        First) to pre-process a client request before being sent out to
server.
        Second) to post-process output from server before it is returned
to the client.
        Either stage being 'optional', of course if no <recording |
logging | processing> is desired.

        A more detailed description _might_ be:

        open 2, 4 or 6 "pipes" to 2nd process(es) used as follows:
        ---first squid receives request from client---
        In any communication to a 'helper' process, a "SESSID" tag would
be
        pre-pended but removed before squid send text to server or
client)
                not in cache:
                        pipe 1: (squid)-> (proc) # (<SESSID>+raw client
request)
                        pipe 2: (proc) -> (squid) # (<SESSID>+client
request)
                        ---squid sends request to server---
                        ---squid gets reply from server---
                        pipe 3: (squid) -> (proc) # (<SESSID>+raw
server text)
                        pipe 4: (proc) -> (squid) # (<SESSID>+server
text to be cached)
                        ---squid caches data if needed---
                in cache:
                --squid retrieves data--
        --then--
        pipe 5: (squid) -> (proc) # (<SESSID>+server's reply (not
cached mods))
        pipe 6: (proc) -> (squid) # (<SESSID>+post cache processing)
        ---squid sends text to client as response---

        Notes: SESSID tag could allow 1 "proc" to service multiple
requests as responses may be asynchronous.
        Or...1 proc/session and no SESSID, but each invocation of 'proc'
can only handle 1 session at a time

        I suppose this also could be looked at as a 'feature'(s)
proposal -- I keep rehashing it every several weeks but haven't gotten a
chance to even look at doing it myself (too much work for too few
allowed keyboard hours-(RSI)). It's a pain when you have more ideas
than hand & coding power to implement.

        Feel free to shred the design ideas with alternates -- I can
either
justify, ask why, or just go "yeah, what 'they' said" and roll it into
any future plans/discussions...I'm a firm believer in going for quality
of design -- though sometimes, I, like others, just settle for what
barely scrapes by (yeah, I'm part of the global software QA problem in
that sense -- my expectations have been lowered (*sigh*) ).

-Linda

PLEASE NOTE: THE ABOVE MESSAGE WAS RECEIVED FROM THE INTERNET.

On entering the GSI, this email was scanned for viruses by the
Government Secure Intranet (GSI) virus scanning service supplied
exclusively by Cable & Wireless in partnership with MessageLabs.

GSI users see http://www.gsi.gov.uk/main/new2002notices.htm for further
details. In case of problems, please call your organisational IT
helpdesk.

*********************************************************************
This E-mail and any files transmitted with it are private and
intended solely for the use of the individual or entity to whom
they are addressed. If you are not the intended recipient,
the E-mail and any files have been transmitted to you in error
and any copying, distribution or other use of the information
contained in them is strictly prohibited.

Nothing in this E-mail message amounts to a contractual
or other legal commitment on the part of the Government
unless confirmed by a communication signed on behalf of
the Secretary of State.

The Department's computer systems may be monitored
and communications carried on them recorded, to secure
the effective operation of the system and for other lawful
purposes.
*********************************************************************
Received on Thu Feb 06 2003 - 05:58:11 MST