Blocking TOR Exit nodes with scripting

[Luis_Borralho1]

Hello guys!

I'm planning to block all of TOR exit nodes using Checkpoint scripts created for that purpose, see link below.

How to block traffic coming from known malicious IP addresses 

My question is this..

Will these exit nodes be append to the SAM Rule, or when it updates the SAM Rule will it clean all my SAM Rules already created and in place?

Thank you very much for your support.

Best regards.

Luis Borralho

[PhoneBoy]

That SK uses the fw samp mechanism, which is completely different from SAM rules.

Note fw samp is SecureXL friendly and is more efficient than using SAM rules.

[Martin_Valenta]

Does it require anything else specific, except modification of script? 

I've configured and can see rules in samp, but it's not enforce, nothing get block from source IP's.

TAC case opened, just in case..

operation=add uid=<5cf8fc48,000003b0,65c5c30a,000068d2> target=all timeout=458 action=drop log=log comment=threatcloud_TOR_block service=any source=range:199.249.230.78 pkt-rate=0 req_type=quota

[Timothy_Weid]

Curious why this route and not simply blocking the TOR app in policy?  Do you not have app control?  I looked at the script but it would have to be redone after upgrade/lifecycle.  Simply blocking app makes it part of the policy.

[Borut]

Blocking TOR app in policy only achieves blocking outgoing traffic from your network. With this route you achieve, that your publicly accessible services (DMZ...) cannot be accessed from TOR exit nodes.

[Samuel_AL]

Greetings, @Martin_Valenta.

I too am having the same problem: I configured the script following step 3 from the link mentioned above, I can see rules in SAMP, but apparently nothing is blocked as I see allowed connections in SmartView Tracker.

We are running R77.30 and do not have Application Control blade enabled (not licensed).

Did you manage to get it working? Is App Control a prerequisite to use the script?

[Borut]

App control is not a prerequisite. We are using the script on gateways without it. 

There are some known limitations.

• Supported on Security Gateway running Gaia OS only.
• Not supported on VSX Gateway and on Scalable Platforms.
• Security Gateway behind a proxy is supported only with the modified scripts from
  section "(3) How to block traffic from custom IP feeds (managed from Management Server)".

Did not test it on R77.30 however, we're using it on versions from R80.10 - R80.40.

[Samuel_AL]

Thank you for your reply.

• Our SG is running Gaia OS.
• Not a VSX GW.
• Not behind a proxy.

The allowed connections that I see in SmartView Tracker are accepted by a rule in the firewall policy that is allowing from the Internet to a specific server in DMZ network through specific services.

Shouldn't this traffic be dropped by SAMP before it reaches the firewall policy?

[Borut]

Yes, it should. Not sure why it isn't working for you. Is this a cluster enviroment? Are rules applied on all gateways in a cluster?

On R80.40 we get "The packet violated the DOS module's rate limiting rule base (SecureXL device 0) (policy: 2045) (total rules: 3)" logs in SmartLog. No policy matches for this IP's.

@PhoneBoy : Any Ideas why we can search for this logs only by IP address and not by message contents? I have tried every string from the SK and some of my own, with no  success.

[PhoneBoy]

Depends on what field this message appears in.
Not every log field is indexed (and thus not searchable).

[Timothy_Weid]

Can't say i ever liked this solution.  More and more thinking ill wait for R81 and do an importable list and just update that off an api