There are a few layers of answers to that.
ip access-list 101 deny tcp any 10.10.10.10 0.0.0.0 eq ftp
Will only block port 21. If you additionally want to block port 20, that's another access list entry. I think the symbolic name is "ftp-data", although I'd probably just use "20".
However, that may not have quite the effect you want, depending on exactly how you think of "blocking all FTP".
The server data port number in a passive FTP transfer is actually negotiated on the control connection, and it can be any port. The same applies for the server source port in an active FTP transfer. Most FTP servers will use port 20 if they have no reason to do otherwise, but that's not universal and you'd need to verify how your server behaved. Note that there might be some edge cases where a server that usually used port 20 could be pushed to use a different port, say when it had several sessions running with the same client.
If you know for sure that your FTP server always uses port 20 for data connections, you're probably OK. However, remember that, in the default "active" mode of FTP, the server makes the connection to the client, so (assuming a control connection somehow got established in the first place to request a transfer) you'd get the server sending a SYN packet out to the client, and then timing out when you filtered the returning SYN-ACK. You may or may not be OK with that.
If you're filtering out the control connections anyway, that risk is probably OK. The concerns are resource exhaustion on the server and maybe information leakage to the client. If the client is in a position to make the control connection in spite of your filter, you probably have worse problems than that anyway.
... however, if you're willing to accept that much risk, even just filtering the control connections might be OK. A bug-free FTP server will ignore incoming data connections from IP addresses that don't have transfers set up on control connections, and of course the server can't make an outgoing data connection without a control connection to tell it where. The remaining concerns are
Buggy FTP servers letting one client steal another client's data (possibly common with quick and dirty small-footprint servers designed for desktops, although unlikely for a program that's ever handled a lot of traffic) and
"Outside" hosts trying to spoof the data connections for legitimate "inside" FTP sessions... which would be pretty tricky to time without inside collusion, but might conceiveably be doable in some odd circumstances.
Other things, like weird third-party FTP hacks, also require some kind of inside foothold, so they fall under the same umbrella. But all of them would work on a port other than 20 if the server chose to use such a port.
Upshot of the whole discussion you didn't ask for: I suggest you go ahead and filter 20, but be aware that, unless you trust your knowledge of your server's behavior, that filtering may not completely protect you from the (relatively minor) risks associated with FTP-data connections. The only way to do that would be to filter all ports that you didn't know were being used for something else.
Speaking of which, it's actually pretty unusual to see anybody filtering out *just* FTP connections to a host or network. It would be more common to block everything by default, and then open only the ports you actually want to allow. That's what we usually suggest people do.
