Help Me Understand Packet Handling of Blocked Traffic
-
So today I got hit by a DDOS attack. And I saw something that surprised me.
The DOS attack was to IP addresses that were not even in use. There are no servers, nothing, that use these IP addresses.
This PFSense does not have any NAT turned on. It's got public ips on the WAN and public ips on the LAN, so no NAT is done by PFSense. (Manual outbound NAT rule generation)
What is strange is that PFSense was generating a huge amount of outbound traffic from these IP addresses. And there is nothing on those IP addresses. So effectively PFSense DOS'd me by filling up the pipe with a flood of outbound traffic. (Even my ISP confirmed the real problem was the outbound traffic.)
I am sure that there are no rules allowing any traffic in on those IP addresses. I even created an explicit block rule on the ips that were the target of this attack, and that didn't help. I could see the traffic on the WAN interface and on the LAN interface. How was the LAN interface even touched by this blocked traffic?
Was this outbound traffic from PFSense some kind of acknowledgement packets of the blocked traffic? The outbound traffic really surprised me. Anyone have any ideas on what was going on there?
-
By default, the only response(RST) packets PFSense will send out is if you configure it to do that. If you are seeing actual traffic for a real protocol response, that is a service you enabled on PFSense or you are forwarding to an internet server. Again, PFSense blackholes incoming connections by default. The only way for outgoing traffic is if you initiate it or enable a service.
-
Thank you for your time to answer this Harvy.
I did figure it out, I just wasn't understanding everything that was going on during this attack.
The actual source of the DOS attack was on our LAN, and they were using a computer on our LAN to DOS someone else, DOSing us in the process. (It wasn't a computer our company is responsible for…)
They were spoofing the packets as coming from the internet when the source was really on our LAN. That's why I was seeing this traffic on the LAN and WAN interface.
Another good reason to block all outgoing traffic (from LAN to WAN) except the traffic you explicitly allow.