Need guidance to block download/upload of any file types

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Need guidance to block download/upload of any file types


In my environment, we have a requirement to block download/upload any types of files between two machines.

I had deployed "File Blocking" profile and added the profile in the policy. Its served the purpose only for the known files types available in palo-alto, example:

.exe,.pdf,.zip etc are getting blocked

.txt, .log, .dat are getting blocked.


User needs a solution as in similar to other firewalls, like, if we blocking download, Then firewall has to block all the file types


Is there any solution available with Palo-Alto?


in-other words, when trying FTP. I need to drop all "ftp-get" commands or "ftp-put" commands.

Thank you


L5 Sessionator

Hello, and welcome,

your request sounds like very unusual one: you want to allow File Transfer Protocol but you want to prohibit file transfer with it. That is quite easy: disallow File transfer protocol in the first place.

If you are still trying to do what you asked above, this will be hard, because nobody planned to do that (allow FTP but block file transfers with it) so such context aren't necessarily included/exposed in the custom signature engine.

There is a few hacks you could try to do, to achieve the same, nevertheless. Hacks are weird because use case is weird, I guess, but:
- to block such requests as PUT or GET, you need custom signatures. Custom signatures for FTP context work by either looking at the context (byte pattern) or checking the length of the request (byte size).
- it is very hard to use custom pattern as those require at least 7 consecutive hard-coded bytes to catch on; what you COULD do is:
1. prepend all your files in said FTP server with fixed 3-character patterns, let's say you prepend them with three consecutive underscores, so "file.exe" becomes "___file.exe",
2. create blocking signatures for "GET ___" and "PUT ___" which will give you 7 consecutive characters (3 for text, 1 for space, 3 for underscores prepending all file names)
2a. alternatively, you could see if commands that you wish to allow contain 7 bytes or more; than you could create custom signatures for what you ALLOW instead of renaming all files in order to block. however, most of the FTP commands are 3-4 characters so it will still be hard to find 7 matching consecutive characters. maybe your use case allows for this approach.

- as you can tell, that's an ugly hack as it requires control over the files that are sitting in the server. sounds impractical. another approach would be byte size. this is tricky, because it could work possibly only by:
1. taking a pcap of the FTP session where you would execute some allowed commands;
2. allowing only a specific byte-length of the requests (that you observed above when you executed allowed requests).
this approach might work and would probably block most of the put/get requests, unless request weirdly matches exact length size allowed earlier

Another and proper approach, from the point of view of system administration, would be to simply disallow particular users/user group those commands on the FTP server itself, and leave firewall out of it. that would be recommended and proper approach in the real world.

Hope that this conversation humored you and that you'll still go with blocking whole FTP or blocking those users on FTP server itself, rather than trying to achieve very opposing goals at the same time (allow FTP but block file transfers).


Hi Lucky.


Thanks for your quick response.


This request is not for allowing FTP but blocking file transfer.


Let me explain the real requirement.


the requirement is not only with FTP, any mode of file transfers.


We have two servers,

1. only users can upload the files to the server

2. only users can download the files from the server



example scenarios tried:

1. Applied file blocking profile named "download_block" and mapped to the policy.

2. from client machine, using filezilla FTP to the upload server and uploaded a .exe, .dll, .txt., et., file successfully --> expected behaviour

3. from the same client machine, using filezila, FTP to the same upload server and tried to download, .exe, .dll, got blocked by file blocking profile "download_block"---> expected behaviour. BUT., .txt, .log files downloaded successfully --> This is not expected behaviour


Hope, the above might explain clearly about my requirement.


Thank you


Maybe you can solve this on the ftp server itself?

If you do prevent file listing (dir, ls, ...), the users can only download a file if they know the name. Would this approach help?

blocking plain-text data files is extremely tricky.

additionally, file-blocking policies, when you check them, don't show you any .txt or .log or any similar file types; basically because there exists no magic number by which file itself would be recognized. As long as you're allowing HTML, for example (web-browsing) you're allowing text files (HTML is actually just a text file, from a point of view of computer).

Let's turn this conversation around for a moment - what is it that you in particular need to allow to the end points? If it includes web-browsing as a rule, you're pretty much trying again to do opposite things - allow text files while blocking them.
You obviously want to restrict thoroughly an endpoint's communication; what is it that you want it limited to - that can be achieved again with security policies, and maybe even without custom signatures, or with some sig...

  • 4 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!