<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I would recommend comparing capabilities based on your access control requirements. For instance with squid, you can easily limit a POST to something like
<a href="https://s3.amazonaws.com">https://s3.amazonaws.com</a> but deny a POST to
<a href="https://s3.amazonaws.com/*">https://s3.amazonaws.com/*</a> ; some firewalls cannot get that granular without complexity of the rules. Why this particular example is important, is because it allows one to create an S-3 bucket but not put anything in
it; this way you can limit to which S-3 buckets one is authorized to access and how (i.e. GET vs POST). While this may not be relevant to your company's requirements, think of what are your company's requirements and make sure the solution meets all those
requirements. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Joe<o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">squid-users <squid-users-bounces@lists.squid-cache.org> on behalf of Antony Stone <Antony.Stone@squid.open.source.it><br>
<b>Date: </b>Monday, July 25, 2022 at 7:29 AM<br>
<b>To: </b>squid-users@lists.squid-cache.org <squid-users@lists.squid-cache.org><br>
<b>Subject: </b>Re: [squid-users] pros/cons squid vs next generation firewall<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
<br>
<br>
<br>
<br>
On Monday 25 July 2022 at 13:22:23, Dieter Bloms wrote:<br>
<br>
> Hello,<br>
><br>
> I run some Squid proxy servers in conjunction with ICAP virus scanners<br>
> and I'm very happy with them. Our company now wants to replace them with<br>
> a checkpoint next generation firewall. Do you have some arguments that<br>
> speak for the further operation of the Squid proxies?<br>
<br>
I would always start by asking what the justification for changing is, and see<br>
whether you can show that it's not valid (or has drawbacks the people<br>
advocating the change haven't thought of).<br>
<br>
<br>
Antony.<br>
<br>
--<br>
BASIC is to computer languages what Roman numerals are to arithmetic.<br>
<br>
Please reply to the list;<br>
please *don't* CC me.<br>
_______________________________________________<br>
squid-users mailing list<br>
squid-users@lists.squid-cache.org<br>
<a href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><o:p></o:p></p>
</div>
</div>
</body>
</html>