This will not make any difference. Even if you instantly drop all packets from a set of IP's in the kernel's network stack (with iptables or whatever) the packets are still flowing through your network pipe connecting you to the rest of the internet, degrading quality of service (which is the "denial of service" part). Nothing you do locally will prevent that, the DOS attack does not even have to target the port your application is using, the DOS attack is done on a server, not on an individual application.

As I understand it the common technique to mitigate DOS attacks these days is to put your servers behind load-balancers with an absolutely colossal bandwidth that cannot (easily) be flooded enough to prevent legitimate users from passing through, and having these load-balancers do the filtering work in response to incoming traffic as needed, e.g. cloudflare. You generally rent those as a service.

If that is overkill for you, then I think just using operating system tools (again, like iptables) will do nicely for your usecase if you just need to stop a client from connecting every now and then. It's transparent to your application and you can write scripts to automate the process. For instance with iptables:

$ iptables -A INPUT -s 1.2.3.4 -j DROP

and your application will never hear of 1.2.3.4 again (remember to remove the rule eventually, because the IP could have gotten reused, and processing rules takes nonzero time, and because perma-banning IP's is generally bad form anyway).

Large apps handle this by (a) having a large number of geographically-diverse servers and (b) using expensive endpoint hardware and good devops in their datacenters.

What is a common method to handle a client trying to DOS the server by flooding it with udp packets?

I have heard of iptables in a typical web setup before but somehow didn't make the connetion

That's because it doesn't help. If someone tries to DDoS you through some kind of botnet/reflection/amplification attack, the main problem is that the wire between the internet and your servers is too narrow. It doesn't matter what you do with the packets that do make it through, because the problem is the overload upstream from you.

Typically, you will want to mitigate in a number of ways:

1) Try to call upstream through the ISP and carrier networks, to stem the traffic at sources. This works better if the attack is from a concentrated source, and you'll need to already have good working relationships with the ISPs involved to get anywhere. Residential Internet or "business cable" hosted? Forget about it.

2) Buy a DDoS protection service. There are a variety of companies, such as CloudFlare, Neustar, Verisign, Level 4, and others. This works by sending the traffic to the DDoS service while under attack, and they write filters that separate attack traffic from your real traffic, and only forward the latter. They have data centers with hundreds to thousands of gigabits of connectivity. The cheaper versions work through DNS, which means that it takes a while to activate, and it won't be 100% effective because the botnets may have cached your older IP addresses. The better (more expensive) ones let you swing your BGP announcement over to them -- they effectively "take over" your public IP addresses -- which takes effect within a minute. Requires a lot of networking knowledge and hardware on your team, though -- no "shared hosting" place is going to be able to enable this.

3) Buy more network capacity. It turns out, bandwidth is actually cheap once you're past the "last mile." If you put your servers in a well-connected data center somewhere, you can easily get multiple fat pipes straight into your section of the DC. As long as the first layer of router/firewall can filter "bad ports" (like DNS, NTP, and such) and your application servers can trivially reject packets from non-existing sessions (hash table look-up, drop the packet) then this is a fine way to solve the "rage booter service" level of DDoS. Again, "shared server" setups are unlikely to be able to do this, and "home internet" or "business cable" type deals aren't really going to cut it. If you're in a c-location facility, you should be able to get 10 Gbps Ethernet drops for a couple of thousand dollars per month from a cheap provider like Cogent. If you buy higher-quality connections, you can often get a lower commit (like 1Gbps 95th percentile) on a fatter pipe, so when the attack hits, if it's short, you dont' care; if it's long, the worst that happens is ISP overage charges.

4) Finally, if your "shared host" is really big, like Amazon Elastic Compute Cloud, or Google Cloud Computing / App Engine, then those data centers may have enough capacity to "swallow" the traffic (or at least ingest it.) Except the links to your servers may or may not be able to take it. And Amazon charges through the nose for bandwidth. (I think that's where they make most of their profit, to be honest!) However, there are some solutions, or options that can help, like smart configuration of Amazon Elastic Load Balancing or whatever. It depends on the attack.

I've dealt with denial of service attacks in multiple occasions and the only surefire way to fight them is with a firewall upstream from you that can absorb a much higher rate of traffic than you ever could receive on your servers. I've used services such as X4B and OVH, and these work by giving you a public and private ip address. You establish an IPIP or GRE tunnel to the private ip and then you bind all your daemons to a lan ip on the inside of your tunnel e.g. 10.0.0.1. You then point all your DNS records at the public ip provided by the anti ddos service. The reason you bind to a lan ip is so that if your server configuration leaks the IP it's bound to, e.g. a bad apache configuration or such then only that lan ip is leaked and not your real server ip that you want to protect.

You configure an allow list of udp and tcp ports, and anything not on your allow list is immediately considered malicious and dropped at the ddos service.

In the event of a ddos all bad traffic is absorbed by the service.

You usually only pay for your valid traffic which is passed along the tunnel on a pay as you go basis.

These services often have more available bandwidth than you could ever need or see and protect some of the biggest sites on the internet.

They can even do reverse proxies for http speeding up your Web services too.

Hope this helps!

What about a single person that tries to disturb your service from a typical home line?

Well, if they are paying for Google Fiber with a gigabit symmetric throughput, and you're serving on AT&T DSL with 10 Mbit down and 3 Mbit up, then you will fall over.

If the situation is the reverse, then you probably won't have any problems, as long as your incoming-packet and early-bad-packet-rejection handling is competently implemented.

When did that change? And does it work as well as advertized?

I haven't used OVH for this but I know others who have and they swear by it. It works well for them. Personally I've used X4B and they worked well (other admins on my irc net use OVH, so I've kind of used them by proxy). While I was using X4B, it absorbed a multi gigabit ddos attack. You have to adjust your server settings though to make sure the tunnel stays up and functional at all times as if it goes down and doesn't reconnect you obviously lose all connectivity for clients...