- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-30-2016 04:46 AM
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
03-30-2016 05:40 AM
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.
03-31-2016 01:40 AM
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.
03-30-2016 05:40 AM
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.
03-30-2016 06:52 AM
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
03-31-2016 01:17 AM
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://www.abuseipdb.com/report-history/200.0.90.90
Regards
dicu
03-31-2016 01:40 AM
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.
03-31-2016 03:12 AM
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
04-05-2016 08:05 AM
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
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!