CloudShark released a new packet capture challenge for this Christmas season! Unfortunately, I don’t have the time to participate right now, but I wanted to reshare this for those of you that do. I also wanted this to serve as a reminder for me to come back to it later. Good luck!
Well, Tom and the team at CloudShark have put together an excellent packet capture challenge on their blog once again. It has actually been awhile since I’ve dug into a capture due to my recent shift in focus to Amazon Web Services, so this was a lot of fun for me. I feel like once you’re a “packet junkie” you are always one! <span style="color: #ff0000;">*SPOILER ALERT*</span> The rest of this post describes the challenge and the process I followed for solving the challenge.
Just because you can do something doesn’t always mean you should. One such example of this is using large HTTP headers. While the HTTP specification itself doesn’t set boundaries, most web servers have default limits around 8 KB. Other devices in the path such as firewalls/WAFs, proxies, and load balancers also have similar limits. Problem The application testers were receiving a reset error. Their application and web server logs did not show any problems.
Everyone needs to do some housekeeping at different points, and I figured it was time I did some a basic security sweep of my setup. To get started, I performed a quick packet capture on the very server that hosts this blog. I decided to give one of CloudShark‘s newer and more distinct features a spin with my recently created account; their Threat Assessment tool. I thought it would be interesting to pit this against PacketTotal as well.