Mitigating spoofed IP attacks

[Mornincupofhate]

How would I go about detecting and dropping spoofed packets? Would I need expensive hardware from arbor or the equivilent?

No, this is not a volumetric UDP attack and I'm certain it can be blocked on premises as its just on the application layer.

Any help is appreciated.

[Nikolithebear]

Hmmm, interesting.  Is this incoming traffic or is it inside the network?

[U.Ho]

Any elaboration is appreciated.

You're telling us it's only on application layer. Yet you're talking about a spoofed IP attack.

 

Something in between there is missing.

 

If it's really about spoofed IP packets, you need to protect your network from spoofing. That's pretty basic security, no need for Arbors on that stuff.

 

If it's a machine sending spoofed packets into its own network, that's something to deal with locally, find the machine and hammer it down with a sledge or something.

 

If it's on application layer, then it's not IP spoofing.

[U.Ho]

One way to prevent spoofing from outside networks is to make a simple access list denying all inside networks and apply it to the outside interface's ingress traffic.

[Mornincupofhate]

8 hours ago, Nikolithebear said:

Hmmm, interesting.  Is this incoming traffic or is it inside the network?

Incoming. Outside server to my network.

[Mornincupofhate]

6 hours ago, U.Ho said:

Any elaboration is appreciated.

You're telling us it's only on application layer. Yet you're talking about a spoofed IP attack.

 

Something in between there is missing.

 

If it's really about spoofed IP packets, you need to protect your network from spoofing. That's pretty basic security, no need for Arbors on that stuff.

 

If it's a machine sending spoofed packets into its own network, that's something to deal with locally, find the machine and hammer it down with a sledge or something.

 

If it's on application layer, then it's not IP spoofing.

I host game servers, and the attacker is sending a2s info requests with a spoofed IP header.  The attack isn't near saturating my network link, but it's causing my server to cap out at 100%, crashing it. Therefore, it's on the application layer.

[Mornincupofhate]

6 hours ago, U.Ho said:

One way to prevent spoofing from outside networks is to make a simple access list denying all inside networks and apply it to the outside interface's ingress traffic.

But they're spoofing ip addresses from other sources than ones just inside my network...

 

i was reading into sophos anti spoof, and during a spoofing attack, it would drop all IPs that aren't currently on the state table. Would this be effective?

[foobar42]

So there are a few sensible firewall polices to set at the edge of your network to get started with, this list is a good start: https://en.wikipedia.org/wiki/Martian_packet

The problem is, that many ISPs don't RPF-Filtering, which is a simple firewall policy supported by every serious network vendor on the planet, where you only forward packets from an interface if you would route the source address of that packet over that interface as well. Very simple policy, but somehow 1/3 of the internet doesn't implement it. Ask your provider if he is implementing BCP 38 on his network.

However, there is not much you can do about source spoofing if you are only getting your connectivity from one upstream, like you do, so your easiest option would be to use some form of flow based network monitoring to a collector (netflow, openflow), start digging in the traffic and use specific rulesets based on what you see.

Iptables has support for BPF rules, which allows for incredibly efficient DPI on commodity hardware.

Have fun mitigating.

 

[Mornincupofhate]

On 11/10/2016 at 4:37 PM, foobar42 said:

So there are a few sensible firewall polices to set at the edge of your network to get started with, this list is a good start: https://en.wikipedia.org/wiki/Martian_packet

The problem is, that many ISPs don't RPF-Filtering, which is a simple firewall policy supported by every serious network vendor on the planet, where you only forward packets from an interface if you would route the source address of that packet over that interface as well. Very simple policy, but somehow 1/3 of the internet doesn't implement it. Ask your provider if he is implementing BCP 38 on his network.

However, there is not much you can do about source spoofing if you are only getting your connectivity from one upstream, like you do, so your easiest option would be to use some form of flow based network monitoring to a collector (netflow, openflow), start digging in the traffic and use specific rulesets based on what you see.

Iptables has support for BPF rules, which allows for incredibly efficient DPI on commodity hardware.

Have fun mitigating.

 

So, If I were to implement reverse packet forwarding, on to for say, a stateless firewall thats upstream in the network, it would pretty much deal with the spoofing attacks? Would it add latency since it needs to verify each source before accepting a packet?

[foobar42]

On 12/11/2016 at 6:00 AM, Mornincupofhate said:

So, If I were to implement reverse packet forwarding, on to for say, a stateless firewall thats upstream in the network, it would pretty much deal with the spoofing attacks? Would it add latency since it needs to verify each source before accepting a packet?

No, since it's unable to verify the source, since everything comes from your upstream ISP.

The latency impact if done in hardware though is negligible .

[Mornincupofhate]

7 hours ago, foobar42 said:

No, since it's unable to verify the source, since everything comes from your upstream ISP.

The latency impact if done in hardware though is negligible .

So if I'm correct, reverse packet forwarding just looks at the packets routing table? And it doesn't have to send out ping requests?

[gigabear]

It is impossible to block a Layer 4 flood over your network capacity, you can't just block spoofed packets and expect everything to be fine or then why would companies invest millions in hardware? Your connection is saturated before it has a chance to do anything. If you do truly belie that it is a Layer 7 flood (application) then this is rather simple to block. I made a script that uses netstat and access logs to detect how many connections and reloads a specific IP is doing and if it is doing over the amount I have defined, ban the IP in iptables for a certain amount of time. I also developed a fail safe into it, 3 strikes and your out type of thing.

 

If you aren't capable of doing that, Cloudflare is your answer.

[Mornincupofhate]

9 hours ago, gigabear said:

It is impossible to block a Layer 4 flood over your network capacity, you can't just block spoofed packets and expect everything to be fine or then why would companies invest millions in hardware? Your connection is saturated before it has a chance to do anything. If you do truly belie that it is a Layer 7 flood (application) then this is rather simple to block. I made a script that uses netstat and access logs to detect how many connections and reloads a specific IP is doing and if it is doing over the amount I have defined, ban the IP in iptables for a certain amount of time. I also developed a fail safe into it, 3 strikes and your out type of thing.

 

If you aren't capable of doing that, Cloudflare is your answer.

lol please read everything instead of just the first sentence. If you did read above, you'd realize that network capacity is not a problem, and that I'm not hosting a website either.