the block ip doesn't seem to work for ftp... what i've seen on my system is an ip doing brute force ftp login attempt and the "action" shows "block-ip"... but the attack continues on until i login to our router and block that ip on the router instead.
just this morning, i had 56,000+ sessions of such brute force ftp login attempts from 3 ip addresses... does the PA "block ip" only stop the tcp session? I'm just guessing here, but it may be because ftp and smb are more udp based?
It temporarily black lists the IP (up to 1hr, user configurable), so it should work regardless of application/protocol used in the brute force attack. I suggest you open a support ticket so we can get this resolved for you.
it does block ip for the other brute force attacks, but somehow for smb and ftp, it doesn't work... it shows that the action is "block ip"... but the attacks just continue on...
ok, i'll request a support ticket and hope this can be resolved... it's not a show-stopper...but it certainly is an irritation and a mystery...
Did you get anywhere with this? I have a custom vulnerability that I'm trying to have block IP's, and it won't. Same as you - the action says block-ip in the threat log, but that attack continues.....
unfortunately, no joy at my side on this particular issue... i can see that "block-ip" works for the MS-RDP brute force attack, but not for the FTP or SMB brute force attack...
it's very strange... but my guess is that the "block ip" blocks only TCP and not not UDP... and that's why it does not properly stop the FTP or SMB attacks as these 2 have a UDP side to their protocol... just a working theory... so, it's probable that your vulnerability also has a UDP component to the attack and that's probably why your PA doesn't block it entirely...
my only problem is that paloaltonetworks does not entertain "problem reports" directly from end-users like me and requires me to go through my vendor... quite frustrating...
good luck and hope you can get a solution...
Ehm FTP uses TCP and not UDP. Perhaps you are confusing this with TFTP which is different?
In my opinion this shouldnt matter since both UDP and TCP have srcip and dstip (which is used for the block).
oops... you're right... :smileyblush:
but the problem still remains that the PA firewall appliance claims it has the "block ip" action for the type "vulnerability"; name "FTP:login brute force attempt"; from zone "untrust"; to zone "trust"; to port "21"; application "ftp"; severity "high", yet the attack continues on until i manually block the attacker's IP on the router itself (Cisco : deny ip host "attacker"...)
whereas for MS-RDP brute-force attacks, when the console reports block-ip, the attack does actually stop for the next hour...
Just to verify... when you say that the attack continues - do you mean that each attempt is logged as "block-ip" in the PA-logs or do you mean that each attempt is actually reaching the target server (like if you run tcpdump on the server you would still see each attempt)?
Because if its the first case then I guess it can be because you have a "deny and block" rule as last rule in your ruleset or anyway I think each attempt should still be logged (or have an option if only the first block-ip for a particular srcip should be logged).
In my case, the two vulnerabilities (#1 is the intial sensor for the offending traffic, #2 is the time based vulnerability for it) keep incrementing after the block-ip events.
Attached is the log that shows the problem. These are all attacks from the same source IP - I have the block set to 5 minutes, but it never blocks them.
FYI - I have an active case going that's made it to engineering.
well, "attack continues" as in the PA console shows that the attack keeps going on and the "action" shows "block-ip" for the next few hours until i notice it and block the connection at the router... and each attempt does reach the server under attack.
the strange thing is this is part of the vultnerabilities profile and it does work for blocking MS-RDP brute force attacks... but not SMB and FTP brute force attacks...
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 Live Community as a whole!
The Live Community thanks you for your participation!