Begränsa åtkomst till Check Point-hantering

Jag arbetar med att begränsa åtkomsten till vår Check Point-miljö (SmartConsole, Gaia, etc.) till enbart nödvändiga tjänster och portar. Jag vill försäkra mig om att jag inte missar något väsentligt.

Här är vad jag har just nu:

  • Källa: Hanteringsarbetsstationer.
  • Destination: IP-adressen till Check Point Hanteringsservern och Säkerhetsgateways.
  • Tjänst/Port:
    • TCP 18190, 18210, 257 (för SmartConsole-hantering)
    • TCP 443, 8443 (för SmartView/HTTPS-baserad hantering och Gaia-portal)
    • TCP 22 (för SSH-åtkomst till Check Point-enheter).

Är detta tillräckligt för säker hanteringsåtkomst? Finns det något annat du skulle rekommendera att lägga till eller justera?

Använd detta som referens kanske

Redigera
Vad är målet du försöker uppnå för att begränsa portarna från din hanteringsklient till checkpoint

Om din klient är komprometterad kan angriparen också kompromettera checkpoint-miljön via tillåtna portar

Konfigurera GUI-klienter också.

Firewallregler kommer bara att blockera/ tillåta trafik till hanteringsservern som färdas genom brandväggen. Om du har klienter som är bakom brandväggen och inte routar genom den till hanteringsservern så gör inte denna regel någonting, så du kan begränsa åtkomsten med GUI-klienterna också.

Bör inte behöva 257? Den används för att skicka loggar från säkerhetsgateways till hanteringsservern. Om detta är för att begränsa system-/brandväggsadministratörsåtkomst behövs det inte.

Om du försöker “härda” hanteringsservern genom att stänga av så mycket som möjligt för att minska potentiella sårbarheter etc. Då måste du titta på att inaktivera Implied Rules under Global Properties, men detta påverkar också vilka automatiska regler som finns för säkerhetsgateways.

Sedan måste du vara noggrann med checklistan från Check Mates för att se till att du inte öppnar mer än nödvändigt, inte bara för system-/brandväggsadministratörer, utan för hela trafiken mellan all din Check Point-infrastruktur.

Och om du använder VSX, inaktivera “Control Connections” kan förhindra att nya VSX-gateways/kluster distribueras, så om det är nödvändigt måste du aktivera “Control Connections” igen innan du distribuerar ny VSX-hårdvara. VSX-guiden tillåter inte att skapa nya regler under distributionen, och förinställningen skapar inte en regel för SIC / 18190, så den initiala VSX-konfigurationen kommer alltid att misslyckas tills Control Connections är aktiverade igen för att tillåta SIC / 18190 på implicerade regler / regel 0.

Jag håller helt med—det här kom faktiskt upp under vår senaste revision, så jag försöker bara finslipa allt nu och se till att allt är i ordning.

Vad han sa. Säkra det med LDAP eller någon form av SSO. Håll hanteringsuppgifterna i någon säker lagring och behandla det som bräckglas-inloggningar. VPN-åtkomst med certifikat. Sätt inte hanteringen på webben.

Detta förutsätter naturligtvis att ditt “hanterings”-subnät verkligen är ett hanteringsnät som bara ingenjörer kan få tillgång till i första hand. Brandväggsåtkomst till det är viktigare än autentisering på checkpoint.