Posts Tagged ‘pfsense’
doing your part to stop Denial of Service
Virtually every organization that operates a network connected to the Internet has the ability to serve as an unwitting participant in DoS (denial of Service) attacks. There are simple steps that can be taken to ensure that you are a good net citizen in fact just two will help a great deal.
- Implement Egress Filtering to Stop Spoofed IP Packets from Leaving Your Network
- Stop Your Network from Being Used as a Broadcast Amplification Site
Imagine if every datacenter, broadband and Network provider implemented the broad application of these two steps: The end result would be a significant reduction to the threat posed by DoS Attacks.
Ok – so now your convinced — but how do I implement this? - well I am glad you asked.
I. Implement Egress Filtering to Stop Spoofed IP Packets from Leaving Your Network
- Stop Spoofed IP Packets @ the Edge: The purpose to implement Egress Filtering to Stop Spoofed IP Packets from Leaving Your Network is so that you can prevent forged communications leaving your network. These are often used in DoS attacks. This is a simple process – just ensure that your routers and firewalls are configured to only forward packets if those packets have the correct Source IP address local to your network. These of course would be IP’s that are in your BGP and or ARIN (or ISP) assigned network. While it is important to do this throughout your network, the network edge connection(s) are essential to have this protection, if you are going to be a good net-citizen.
- : Deny Invalid Source IP Addresses: Imagine if all organizations only allowed the traffic leaving their network if it had a valid Source IP address that belonged to that network. While this is not a full-proof way of stopping DoS – it would make finding the organization responsible much easier. This is a simple process – just permit all valid IP addresses access to the Internet via your firewall, gateway and routers – and Deny all other source addresses including private and Reserved Source IP Addresses. Keep in mind if your using NAT you want to do this on your NAT device as well.
-
- 0.0.0.0/8 – Historical Broadcast
- 10.0.0.0/8 – RFC 1918 Private Network
- 127.0.0.0/8 – Loopback
- 169.254.0.0/16 – Link Local Networks
- 172.16.0.0/12 – RFC 1918 Private Network
- 192.0.2.0/24 – TEST-NET
- 192.168.0.0/16 – RFC 1918 Private Network
- 224.0.0.0/4 – Class D Multicast
- 240.0.0.0/5 – Class E Reserved
- 248.0.0.0/5 – Unallocated
- 255.255.255.255/32 – Broadcast
II. Stop Your Network from Being Used as a Broadcast Amplification Site
- Configuring all of your systems – (from your routers, servers, workstations, etc…) so that they do not receive or forward directed broadcast traffic will assist in making sure your network is not used as a broadcast application site. Craig Huegen has a number of papers written on this topic you may find them here.
- Test your network to determine if it is an amplification site. This is as easy as using the “ping” command to send an ICMP echo request packet to the Network Base IP address of your network(s) as well as the broadcast IP address of your network(s). I suggest that you do this not only from your own network but from an independent 3rd party such as www.DNSStuff.com – Note the basic DNS Stuff is free.
- The HostMedic agency refuses to purchase hardware from any vendor that does not disable IP Directed Broadcast by Default as outlined in RFC 2644. In fact – we suggest using PFSense @ the Edge of your network if you are unsure of how to complete all of these tasks. PFSense is FREE and offers low cost support as well as FREE Community based support.
WiFi Security
Recently we attended the cPanel conference in Hoston TX. The event, like usual, was put on by a professional staff – and there is much we learned. It is important to note however security did not seem to be a concern when it came to the networking side of things at the event.
The first day, as tweeted, the cPanel event lacked WiFi for the better 1/2 of the morning due to issues with the Hotel itself. This rose to a number of rouge access points being setup, of which multiple persons logged into. These access points were giving the SSID such as “Official cPanel Wifi”, “cPanel Wireless” and many more various flavors using the cPanel name.
We logged into one such interface and turned on my systems security just to see what would happen and sure enough – someone came knocking and trying to gain access to our file system. The real fun part here is that virtually all of these fake access points were “point-to-point” connections and folks were hooking into someone’s laptop.
Next Year for 2010 – cPanel should think about setting up a captive Portal – one for which upon registration at the conference one is given their own user/pass to gain access to the network. A simple x86 system running PFSense would do this in a heartbeat. Through that system it would be wise to turn off netbios and other system-to-system traffic as well as redirect all port 2086 traffic to port 2087. Sadly – many users at the event are green behind the ears when it comes to security and systems administration…
While it is important to note – cPanel did nothing wrong here – it is also important to note that cPanel in the future would be wise to setup the infrastructure to assist in protecting their more greener clients from the bad boys in the room.
Just on our Mac alone – we saw a ton of cPanel employee computers sitting in the connection bin via Bonjour , as was Softlayers, the Planet, Microsoft’s and HostDimes. Blocking these types of services would be a great start in ensuring the security of the cPanel users both seasoned and the newbies on the block.
As for our Macs – We run through ssh and proxy always 
Cisco IOS Patch for TCP Flaw Released
Cisco (NASDAQ:CSCO) has just released a critical patch out for its IOS operating system fixing a TCP flaw that could trigger a Denial of Service (DoS) condition.
“By manipulating the state of a TCP connection, an attacker could force the TCP connection to remain in a long-lived state, possibly indefinitely,” Cisco’s warns in its advisory. “If enough TCP connections are forced into a long-lived or indefinite state, resources on a system under attack may be consumed, preventing new TCP connections from being accepted.”
In other words, a flaw in TCP could have enabled a DoS attack. Have you patched your IOS today ?
- I think this is just another reason to use vyatta or PFSense.
