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''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). In addition to logging, we require time-based rules for NAT access per VLAN. 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.) . Thanks Shawn Wright I.T. Manager, Shawnigan Lake School http://www.shawnigan.ca ------------------------------------------------------------------------------ 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
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?> 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.> > 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.> 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? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
----- "Tom Eastep" <teastep@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
On 9/1/10 12:56 PM, Shawn Wright wrote:> ----- "Tom Eastep" <teastep@shorewall.net> wrote: > > 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?I''m unfamiliar with Calamaris. But please note that there is really no such thing as a ''Shorewall log''; I suggest that you look for tools that can analyze a ''Netfilter log'' the way you want it analyzed. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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