Most of the techniques which will help you are anti-automation tools. The following may be a helpful resource in this regard:
http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation
This is the reason many websites deploy tools like re-Captcha and that may even be one of the easiest quick-fixes to your problem but it's not foolproof. There are even anti-anti-automation tools just to get around defenses like re-Captcha.
Another tool you will definitely want to look at is Fail2Ban but you will need to enable the specific configuration to protect your website. This is easy to do but by default, it only protects SSH. In many cases, Fail2Ban by itself will take care of your problem.
If you have a more persistent attacker you may need to look into what is unique about their attack technique and either stop it by writing a custom IDS rule for something like Snort or by using a tool like mod_security. Sometimes rate limiting tricks in IPTables works too if you are either on Linux or can place a Linux box in front of your website. There are a lot of ways to solve these but you may need to dig deeper into how their attacks work. Another low-tech way to handle this is by changing your "submit form" url semi-frequently via a cron job, this isn't the easiest solution but it can be very effective. There are many other techniques as well including things like using GEO-IP locations to block the source of the attacks but the key is looking for anti-automation tools which work with the stack you are currently using. Finally, search if the tools or frameworks you currently use have anti-automation tools built-in, some times these ship with things like web-frameworks but need to be enabled/configured by the user of these tools.
One problem you need to be aware of is the attackers likely already know your current public IP address so simply adding a cloud-based WAF solution, like CloudFlare, may not be a practical or useful option to quickly stop active attacks especially if you have other sites linking to your current website via IP (this shouldn't be the case but it happens). Likewise, you will have to make firewall changes to enforce that ONLY connections from CloudFlare can access your application otherwise it will have no effect at all on attacks directly to your current public IP address. This is still a useful security control for future attacks but may create other short-term problems if not implemented correctly and these won't protect from all types of attacks either. It should be noted that there are a number of WAF-bypass techniques which will allow attackers to continue to submit form requests even with one of these in place.
More information about these problems can also be found here:
OWASP Automated Threats to Web Applications
Finally, in case the attacker changes to brute force in response to your implementation of anti-automation tools you may want to go ahead and read the following too:
OWASP Blocking Brute Force Attacks
Hopefully, this helps.