Block Traffic Based Upon Countries Source. Vulnerability Protection and For a Specific Time Interval

[SOC_CSG]

Hello

My objective is block automatically traffic IP for a different time intervals Based upon Countries (Top attack) and applying a vulnerability profile.

This is my Vulnerability Protection Profile and his rules:

Rules (1-3600 sec). I don't want block an IP for a long time.

1 test Critical1800. Where 1800sec=30minutes

2 test High 1200. Where 1200sec=20minutes

3 test Medium 900. Where 900sec=15 minutes

4 test Low 600. Where 600sec=10 minutes

5 test Informational 300.   Where 300sec = 5minutes

:

https://cert.europa.eu/cert/filteredition/es/ThreatsStrategic.html

Security policies:

What do you think? Do you think that it can work?

Thanks 😉

dicu

[santonic · Accepted solution]

Blocking IP for informational events? Seems a bit harsh 🙂

And do you have decryption rule for https traffic? Otherwise your IPS profile won't see much.

[SOC_CSG]

This doesn't seem so strict If we consider that only applies to top x countries sources attacks.

If you apply this filter ( severity contains 'informational' ) displaying 109 threats. Host "client" 21 threats and Host "server" 88 threats.

I think there are important signature Host "server" with CVE-20xx-xxxx CVE-2015-xxxx and CVE-2016-xxxx:

ID 37784 OpenSSL DTLS Handshake Memory Leak Vulnerability  CVE-2015-0206

ID 38924 SSL Version 2 Weak RSA Cipher Detected CVE-2016-0800 CVE-2016-0703

We have a decryption rule as you have said.

Thanks 

dicu

[SOC_CSG]

This is an example of what I want to avoid:

Source IP 200.0.90.90 

Destination Port 22

As you can see I have a policy at the very bottom.  To me this means that the source IP 200.0.90.90 has performed a scan network to port 22. It also means that this IP has conducted a test to all other policies that I have above.

I think if I applied what I posted probably detected as:

ID	Name	Severity	CVE
40015	SSH User Authentication Brute-force Attempt	High
38763	OpenSSH Roaming Feature Information Disclosure Vulnerability	Critical	CVE-2016-0777
37496	OzymanDNS SSH Traffic Evasion Applciation Detection	Informatio
37304	Gitlab Ssh Key Upload Remote Command Execution Vulnerability	High	CVE-2013-4490
36213	OpenSSH AES-GCM Auth Remote Code Execution Vulnerability	Low	CVE-2013-4548
36212	OpenSSH AES-GCM Auth Remote Code Execution Vulnerability	Low	CVE-2013-4548
31914	SSH2 Login Attempt	Informatio
30512	Putty SSH Client transport layer protocol incorrect length field buffer overflow vulnearbility	High	CVE-2002-1359
30511	SecureCRT SSH1 Identifier String Buffer Overflow Vulnerability	Medium	CVE-2002-1059
30509	OpenSSH sshd Identical Blocks Denial of Service	High	CVE-2006-4924
30508	SSH CRC-32 Compensation Attack Detector Vulnerability	Critical	CVE-2001-0144
30506	FreeFTPD/FreeSSHD SSH Server Remote Buffer Overflow Vulnerability	High	CVE-2006-2407

The Source IP have bad reputation

https://cymon.io/200.0.90.90

https://www.abuseipdb.com/report-history/200.0.90.90

Regards

dicu

[santonic · Accepted solution]

You've masked destination IP but yeah; I guess 200.0.90.90  has performed port scan for port 22 (at least).

But your action is set to 'drop' so this traffic will never hit any security profile (including IPS).

The only way this IP will be blocked by IPS is if you have port 22 open on one of your public servers and if the client triggers some IPS signature.

Better way to defend against this traffic is SYN-cookie and TCP port scan protectiion, both part of Zone Protection.

[SOC_CSG]

Hello Santonic

I agree; For this traffic won't be applied an IPS(block) security profile . If this doesn't meet any of the security policies that allow.

 - I have already a protection zone profile.

I know this other way "Dynamic Block List".

Thanks

dicu

[SOC_CSG]

Hello again

And how about if we implement for this design a honeypot system?

Does anyone know if someone has implemented? e.g. Kippo

http://www.behindthefirewalls.com/2014/02/ssh-honeynet-kippo-kali-and-raspberry-pi.html

http://www.csoonline.com/article/2115901/data-protection/all-about-honeypots-and-honeynets.html

Thanks

dicu