----- "Tom Eastep" <teas...@shorewall.net> wrote: On 9/1/10 12:08 PM, Shawn Wright wrote: > In changing our campus squid proxy to transparent mode (which only > handles plain http traffic, not SSL), we are faced with having to NAT > our SSL traffic, while still wishing to maintain tight control over > access and logging. >
I don't understand -- what does transparent proxying of plain http have to do with NATing SSL? Do you simply mean that https connections will be Masqueraded/SNATed in the same way as any other non-proxied outgoing connection? --- Yes, https (and other non-http SSL requests) will be SNATed along with other traffic which cannot be handled with a transparent proxy. This is a huge departure from our previous policy, which did not allow ANY http/https traffic except through a proxy with quite strict access controls and detailed logs. We are acutely aware that nearly anything can be done using an external SSL CONNECT proxy, so need to prevent our users from accomplishing this, while still allowing legitimate traffic through. > I'm interested in recommendations for logging such traffic a in way that > can be used for monitoring or tracing activity when necessary. Although > we've run shorewall for several years, we have not relied on the logs > much, as until now, most of our traffic has gone through squid. We have > 650 active users on a 1Gb gateway, with about 4-6Tb of traffic monthly, > so logs could be quite large (squid logs are >2Gb daily). What are your requirements? - Log each connection (simple with Shorewall -- use a LOG rule or a log level on an ACCEPT rule) - Log every page request -- not possible with a packet filter. --- Each connection should be sufficient, as the DST IP is the most significant detail. Is there an equivalent to Calamaris for analyzing Shorewall logs? > > In addition to logging, we require time-based rules for NAT access per > VLAN. Please don't use NAT as an access control mechanism with Shorewall. NAT should be constant and you use filter table rules to control access. --- Understood, I meant filter rules... :-) > We can use our Cisco 6500 for this, or our Aruba wireless > controller, but I'm interested in hearing about methods employed with > shorewall (cron, etc.). Why not use the TIME column in /etc/shorewall/rules? --- Hmmm... guess I haven't read up on the latest docs enough. I'll look into this, thanks. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
