Can I get Phoenix to not reply al all to certain http requests

How do you identify those requests? Is there some reverse proxy involved? If yes, let it handle that stuff, if no, it will act on that disconnect with a bad gateway or similar.

The software is for command and control of security devices. There are two scenarios where it would be desirable for “no response”. One is if the device thinks the request came from a hacker instead of a valid authenticated authorized controller. I.e. don’t give the hacker any info at all - let them time out not knowing why. The other example is when responding at machine speed to a massive DDoS attack. The controller of the network under attack would prefer to fire & forget to billions of devices. If some percentage don’t work, they can be cleaned up later. It would still be preferably to hit more devices faster without worrying about the responses. The command language has an option to request this as part of the command. Although the real reason why it needs to be done is because the requirements say so so I need to figure out how to do it.

I didn’t ask why you want to do so, but I asked if other software is involved that could do that.

Especially for the DDOS scenario, there are tools available that handle the connection drop at the kernel level and therefore could drop the connection faster than cowboy could even read the source IP.

I would handle these use cases from your firewall (iptables/pf) in cooperation with something like fail2ban. What nobbz said, you need to handle this as early as possible otherwise your can’t defend against the force of a DDoS (if you ever can). But in the generic use case of an attacker doing strange things on the TCP level you need firewalling (there’s so much more a firewall does for you like scrubbing/normalizing packets etc). If you detect stuff inside your app (so on the elixir level) you could write out log files that triggers fail2ban.

There are way more options to secure the device, should it really be completely open on the internet?
You could put it behind a wireguard vpn or on a zerotier private network (on top of the internet), you could secure it by running on TLS(https) but require the user to come in via mutal TLS (https where the client needs a certificate on the client side to connect).

edit: slight addition; not sure about the whole use case but if you’re afraid of DDoS then you could also go with services like cloudflare which do this as one of their core services, you just put them in front of your app(s).

If you want to close the TCP connection without sending a reply, and you can be sure the Plug adapter is Plug.Cowboy, then you could use this hack:

def no_reply(conn) do
  {Plug.Cowboy.Conn, %{pid: ranch_pid}} = conn.adapter
  Process.exit(ranch_pid, :kill)
end

Letting the connection time out without sending a TCP FIN while still clearing resources on the server would require low-level access to the kernel TCP stack. Not even the new socket module in OTP 22 can do that.

Edit: this works with Cowboy 1, probably not without changes on Cowboy 2, due to the changes in the process model

Processes are cheap. Process.sleep(:infinity)

And you hold onto an ephemeral port on the gateway in front of you, it runs out of ports–mission accomplished for the DDOSer!

Hmmm, good point. Yeah don’t do that.

Wrt to 'firewall (iptables/pf) ’ - This is the command coming in to tell you do exactly that. Ie it’s the theat intel coming in to tell you to not accept communications from this bad guy. And the threat intel box is telling billions of IOT devices, so doesn’t want to be bothered with replies. Probable answer is to either live with the replies or to use MQTT instead of HTTPS.

wonder if conn |> halt() works..

eg the example here Phoenix.Controller — Phoenix v1.8.8 and then remove the redirect..