<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: whitelist AWS S3 buckets using complex URI / URL patterns? in General Topics</title>
    <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27628#M5632</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Looks like this was all the result of confusion. With some help from &lt;A href="https://community.checkpoint.com/migrated-users/61970" target="_blank"&gt;Brian Butts&lt;/A&gt;‌, what we discovered is that if you request something like bucketname.s3.us-west-2.amazonaws.com from AWS, they will respond from s3.us-west-2.amazonaws.com, and their certificate shows *.s3-us-west-2.amazonaws.com. These translations that cut off the bucket name likely account for the thought that the rules woudl not work with longer address, since these longer addresses were not involved with the responses and therefore a bypass on them would never work. SO it's a different issue all together.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I've opened a new thread to discuss this: &lt;A href="https://community.checkpoint.com/message/28606-base-a-bypass-rule-on-the-request-address-not-the-response-address" target="_blank"&gt;https://community.checkpoint.com/message/28606-base-a-bypass-rule-on-the-request-address-not-the-response-address&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 21 Jun 2019 09:15:00 GMT</pubDate>
    <dc:creator>Jonathan_Sander</dc:creator>
    <dc:date>2019-06-21T09:15:00Z</dc:date>
    <item>
      <title>whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27621#M5625</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;We're working with a customer who wishes to make a whitelist entry for a range of AWS S3 bucket addresses in their firewall. The names would be in the form: &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;abc-*-xyz.s3-us-east-2.&lt;SPAN class=""&gt;amazonaws&lt;/SPAN&gt;.&lt;SPAN class=""&gt;com &lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;OR&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;abc-*-xyz.s3.us-west-1.amazonaws.com&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;Where the "*" would be a randomly generated string that maps to an ephemeral name for a particular S3 bucket. &lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;They are claiming this is not possible because the host in the URI has more than 3 parts. So they say that if it were "abc-*-xyz.&lt;SPAN class=""&gt;amazonaws&lt;/SPAN&gt;.&lt;SPAN class=""&gt;com" it could work. But the other pieces in that host make it an invalid authority to use in a whitelist entry. &lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;Is that true? Might it be a limitation of some very old version? I would welcome any pointers to appropriate documentation about this as well as answers. &lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;Thanks!&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 18 Sep 2018 15:39:10 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27621#M5625</guid>
      <dc:creator>Jonathan_Sander</dc:creator>
      <dc:date>2018-09-18T15:39:10Z</dc:date>
    </item>
    <item>
      <title>Re: whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27622#M5626</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;That doesn't sound right.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What steps are they following to try and do this on which version?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 18 Sep 2018 21:50:41 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27622#M5626</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2018-09-18T21:50:41Z</dc:date>
    </item>
    <item>
      <title>Re: whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27623#M5627</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;These were, of course, my first questions as well. I am awaiting replies on both. The other detail that I do know is that this is related to deep packet inspection with SSL. The reason for the whitelisting is to have the data streams inbound from S3 on those address patterns exempt from the inspection. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In general, do you believe that a host in a URI can only have 3 parts? Or can it be arbitrarily long so long as it is a valid host name?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 18 Sep 2018 22:10:20 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27623#M5627</guid>
      <dc:creator>Jonathan_Sander</dc:creator>
      <dc:date>2018-09-18T22:10:20Z</dc:date>
    </item>
    <item>
      <title>Re: whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27624#M5628</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I've never heard of such a limitation myself (related to number of hosts/domain in a URI).&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 18 Sep 2018 22:22:35 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27624#M5628</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2018-09-18T22:22:35Z</dc:date>
    </item>
    <item>
      <title>Re: whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27625#M5629</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Spoke to an engineer today who pointed out that if you create the URL as a regex instead of a plain URL, you can essentially use any form you need to. So that may be a solution for us in this case, and certainly may help others facing similar challenges. This would then be connected to the https inspection policy as an exception to avoid the deep packet inspection. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;IMG alt="Shows the application site creation dialog in the policy creation tool entering a regular expression that contains a complicated URL URI" class="image-1 jive-image j-img-original" src="/legacyfs/online/checkpoint/70754_redacted Check Point SSL rule with regex.png" /&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 19 Sep 2018 23:14:07 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27625#M5629</guid>
      <dc:creator>Jonathan_Sander</dc:creator>
      <dc:date>2018-09-19T23:14:07Z</dc:date>
    </item>
    <item>
      <title>Re: whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27626#M5630</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Regex is definitely the way to go with this.&lt;/P&gt;&lt;P&gt;As I recall, you can't use a custom application in the HTTPS Inspection rulebase, but you should be able to use the "category".&lt;/P&gt;&lt;P&gt;Is that working for you?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 20 Sep 2018 03:38:17 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27626#M5630</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2018-09-20T03:38:17Z</dc:date>
    </item>
    <item>
      <title>Re: whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27627#M5631</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I'm doing all of this through proxies (people), but the way this engineer configured it was to add an entry to the policy for HTTPS inspection to bypass anything that matched those regexs for the URLs. That did seem to do the trick according to what we could tell. This was done on 80.10, but still not clear the exact version the client has.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;IMG alt="HTTPS inspection Policy screen showing rules and one with a bypass action for these regex URL / URI types" class="image-1 jive-image j-img-original" src="/legacyfs/online/checkpoint/70759_Screen Shot 2018-09-19 at 2.01.51 PM.png" /&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 20 Sep 2018 10:58:26 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27627#M5631</guid>
      <dc:creator>Jonathan_Sander</dc:creator>
      <dc:date>2018-09-20T10:58:26Z</dc:date>
    </item>
    <item>
      <title>Re: whitelist AWS S3 buckets using complex URI / URL patterns?</title>
      <link>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27628#M5632</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Looks like this was all the result of confusion. With some help from &lt;A href="https://community.checkpoint.com/migrated-users/61970" target="_blank"&gt;Brian Butts&lt;/A&gt;‌, what we discovered is that if you request something like bucketname.s3.us-west-2.amazonaws.com from AWS, they will respond from s3.us-west-2.amazonaws.com, and their certificate shows *.s3-us-west-2.amazonaws.com. These translations that cut off the bucket name likely account for the thought that the rules woudl not work with longer address, since these longer addresses were not involved with the responses and therefore a bypass on them would never work. SO it's a different issue all together.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I've opened a new thread to discuss this: &lt;A href="https://community.checkpoint.com/message/28606-base-a-bypass-rule-on-the-request-address-not-the-response-address" target="_blank"&gt;https://community.checkpoint.com/message/28606-base-a-bypass-rule-on-the-request-address-not-the-response-address&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 21 Jun 2019 09:15:00 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/whitelist-AWS-S3-buckets-using-complex-URI-URL-patterns/m-p/27628#M5632</guid>
      <dc:creator>Jonathan_Sander</dc:creator>
      <dc:date>2019-06-21T09:15:00Z</dc:date>
    </item>
  </channel>
</rss>

