Re: Not blocking

[Ryan Nix]

I took out all squid.conf acls thinking that squidguard.conf would 
handle them.

This is all I have in my squid.conf:

coredump_dir /var/spool/squid
cache_mem 100 MB
redirect_program /usr/sbin/squidGuard -c /etc/squidGuard.conf

I was hoping that squidguard.conf would all unfettered access to all 
sites except those found in the s.g. database.

Do I absolutely have to have an IP range as an acl?

Rick Matthews wrote:

Ryan Nix wrote:
 

Can anyone give me a good example of what is in their squid.conf 
file? 
   

What problems are you having with Squid?  You should have squid 
working properly before you add the redirect_program statement; you 
do not want to debug two unfamiliar, interconnected programs 
simultaneously.

What are your concerns?
-----------------------
Q. Is squid starting OK?  Is squid starting squidGuard?
A. After running 'squid -k reconfigure', check squid's cache.log. You
should not see any errors. You should see squid starting squidGuard
processes, and squid ready to serve requests.
Q. Is squidGuard running?
A. Run 'ps ax | grep squidGuard'.  The number of squidGuard processes
shown should equal the value of redirect_children in squid.conf.
Q. Is squid sending transactions to squidGuard?
A. Edit squid.conf. Find the "debug_options" statement. It probably
reads "debug_options ALL,1".  Modify that line to read
"debug_options ALL,1 29,1", and run 'squid -k reconfigure'.  Fire up
a browser and visit a few sites, then check squid's cache.log. If 
squid is calling squidGuard you will see statements like these:

redirectStart: 'http://my.yahoo.com/?myHome'
helperDispatch: Request sent to redirector #1, 52 bytes
helperHandleRead: 1 bytes from redirector #1.
helperHandleRead: end of reply found
redirectHandleRead: {}
redirectStart: 'http://some-other-url'
helperDispatch: Request sent to redirector #1, some# bytes
helperHandleRead: 44 bytes from redirector #1.
helperHandleRead: end of reply found
redirectHandleRead: {http://your-redirect-url}
The first 5 lines pertain to a url that was approved by squidGuard.
The second 5 lines show a url that was redirected by squidGuard.
NOTE: After running your test transactions, be sure to edit squid.conf
and return the debug_options statement to its original value (probably
"debug_options ALL,1"), then run 'squid -k reconfigure'.  The 
cache.log file will quickly become very large if you don't.

Let me know if you have other concerns that I did not address.

Rick

 

Again, I want to allow unfettered access to all sites except those found 
in the squid guard database.

By the way, I ran squidguard -d and the syntax checks out so I should be 
mostly ready to go! 

Thanks again to everyone for their help!  :)

Rick Matthews wrote:

   

Matthew Trey wrote:

     

Pardon me, you are correct.  I never noticed that in the absence of a
redirect in one ACL, squidguard uses the redirect in the default URL.
  

       

And in the absence of ANY redirects, squidGuard passes everything.



     

squidGuard cannot "block".  squidGuard can only "redirect".
squidGuard cannot "block".  squidGuard can only "redirect".
squidGuard cannot "block".  squidGuard can only "redirect".
    

         

no reason to be a jerk, once was enough =)
  

       

Sorry, sticking keyboard. :)



     

In light of this corrrection a redirect rule is needed or your ACL 
in fact will not work. thanks for pointing that out Rick =)
  

       

Just trying to help. :)

That's also why I included a sample squidGuard.conf file a few
posts back.  There are several things in there that will help you 
with your squidGuard configuration, testing and debugging.  Even
if you ignore everything else in there, I highly recommend that
you add a log statement to each of your destination groups, i.e.:

dest porn {
  domainlist      blacklists/porn/domains
  urllist         blacklists/porn/urls
  redirect        http://yourserver.com/whatever...
  log             blocked.log
}
Rick



     

-----Original Message-----
From: Rick Matthews [mailto:[EMAIL PROTECTED]
Sent: Monday, March 01, 2004 10:23 PM
To: Matthew Trey; [EMAIL PROTECTED]
Subject: RE: Not blocking
Matthew Trey wrote:
  

       

that is true, once squidguard is up and running with this config it
will simply pass nothing, with no notice that anything was blocked.
    

         

That statement is incorrect.  Without a redirect statement,
squidGuard will PASS EVERYTHING, NOTHING WILL BE BLOCKED.
squidGuard cannot "block".  squidGuard can only "redirect".
squidGuard cannot "block".  squidGuard can only "redirect".
squidGuard cannot "block".  squidGuard can only "redirect".
The interface between squid and squidGuard is very limited.  Squid
passes the information to squidGuard and waits for an answer from
squidGuard.  squidGuard's response to squid is one of two things:
a blank line (approved), or a new url.  Those are the only two
choices.  Without a redirect statement squidGuard ALWAYS returns
a blank line.
  

       

Provided we figure out the lack of rule matching,
    

         

Everything will be approved in the absence of redirect statements.

Rick

P.S. squidGuard cannot "block".  squidGuard can only "redirect".



  

       

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Matthew Trey
Sent: Monday, March 01, 2004 6:05 PM
To: [EMAIL PROTECTED]
Subject: RE: Not blocking


Rick Matthews wrote:

    

         

squidGuard won't redirect without a redirect statement.
      

           

Yup.

that is true, once squidguard is up and running with this config it will
simply
pass nothing, with no notice that anything was blocked.  Provided we
    

         

figure
  

       

out the
lack of rule matching, I do suggest adding a redirect rule, directly below
the pass
rule pointing to either a simple html file or cgi script, or really
    

         

anything
  

       

you want.

this will let the user know the content was blocked rather than getting no
info at all.