This mapping was completed the evening of Feb 19th, as such, people were submitting samples at the same time. The mapping can be found: http://shurl.ca/apt1vt
Here are some notes I posted to twitter about it:
T'was the night before Christmas and all through the house everyone felt shitty, even the mouse.
Dads at the whore house, mom's smokin' grass, and I just settled down for a nice piece of ass.
Then out on the lawn there arose such a clatter I sprang up from my piece to see what was the matter.
He came down the chimney like a bat out of hell, I knew right away that fat fucker fell.
He filled all the stockings with pretzels and beer and a big rubber dick for my brother the queer!
He rose up the chimney with one hell of a fart, that son of a bitch blew my chimney apart! He swore and cursed as he flew out of sight.
Piss on you all and have one hell of a night!
MONEY IS SHORT AND TIMES ARE HARD YOU JUST GOT YOUR CHRISTMAS CARD.
-- Via Text Message - Original Author Unknown
For a project I'm working on, we were having intermittent DNS issues. To try and figure out what's going on, I wanted to be able to monitor and track DNS response times, as close as I can get.
I started out with this article - http://www.zabbix.com/wiki/howto/monitor/services/monitor_dns_and_ntp_services_on_your_network which gave me the details on how to go about monitoring DNS, however their script would only tell me a yes or no if the query worked. I wanted times.
I modified the script to use dig, which gives a query time - however, by default, the dig query uses the local resolver, and if that has the domain cached, the next requests will be 0 ms. That we can't have. Using dig, we can add the +trace to the command which will manually go and do all the required polls to get the final answer. This means, we can track how long the query took from start to finish. But, of course, dig gives you query times for each request, but not the total time. Enter the command time - which lets us know how long a command took. Wrapping it all together gives the following script. Combine with the above link, and some tweaks from http://www.zabbix.com/documentation/1.8/manual/config/user_parameters and you have a pretty handy script.
if test -z "$1" ; then
echo "You need to supply a DNS server to check. Quitting"
MYTIME=$((time dig $DOMAIN +trace) 2>&1| grep real | cut -dm -f 2 | sed -e 's/[s.]//g')
if [ $? -eq 0 ]; then
So I was following along twitter and found out about the Stripe CTF challenge.
Basicly, you are given a bunch of Pentest type challenges and you are required to complete them to move forward.
Here I'll go over each challenge, and describe what I did to solve the puzzle.
Keep in mind, alot of those hours was sleep, work and weekends with the family ;)
You'll find my write ups some time after the CTF closes here: https://coolacid.net/stripe-ctf-aug-12
More information on the design of the back end systems can be found here: https://blog.gregbrockman.com/2012/08/system-design-stripe-capture-the-flag/
So, over the years I've worked in a number of places where IDSs are placed in different areas around firewalls on the edge.
I've debated with Bosses, colleges, and other people about the best place on the edge to place an IDS.
1. Outside the firewall
- You can see possible attacks hitting your firewall
- You can see traffic leaving your network if it's not suppose too
- You can use the IPS (if inline) to block bad traffic before hitting your firewall to save firewall resources (DDoS)
- Lots of false positives
- Need a beefier IDS/IPS because you are seeing all traffic, not just the stuff passed your firewall
2. Inside the firewall
- You only see possible successful attacks inbound
- Firewall protects the IDS from DDoS attacks
- You don't see possible attacks from the outside hitting your firewall
(This isn't an exhaustive list)
Now here; A misnomer:
If you have your IDS on the outside of your firewall, you will see attacks that hit your firewall. Let's think about this. If your firewall blocks packets to ports you don't allow - what kind of actual traffic are you going to see?
1. TCP ACK
2. Non-TCP Traffic
So, really, you'll never see any attack that happens over TCP because the handshake can never happen. Then, when you start looking at packets from UDP/ICMP etc You may start getting heart attacks and start running to your firewall admins thinking some traffic is getting passed the firewall.
If your going to implement IDS/IPS this is how I recommend it gets setup;
1. Put it inline AFTER your Firewall - Don't use a span, or tap.
2. Use a TAP (not a span port, unless you can specify traffic direction) before the firewall and only pass the OUTBOUND traffic to the IDS/IPS
This will give you a good indication of what has made it passed your firewall, inbound, and outbound.
I know what you're going to say. "But what about possible attacks against our network, we want to detect that..."
You're logging all traffic passing your firewall right?
Including dropped packets inbound?
You implemented some way to monitor those right?
This way, you'll be able to detect inbound brute force and mapping attacks - the only thing you'll miss is UDP/ICMP attack packets - but I figure that's a fair trade off.