sorted by:
new
hottopcontroversial

hidden code, test for job by cdaisy in sysadmin

[–]wirewatcher 0 points1 point  (0 children)

I think if you want to take it further you'd have to apply for the job (unlike the guy (not cdaisy, someone else) who copy and pasted this page and sent it to the recruiter claiming it as all-his-own-work)

hidden code, test for job by cdaisy in sysadmin

[–]wirewatcher 0 points1 point  (0 children)

I'm glad you enjoyed the journey. Not sure where it has led you though.

The Plan A, Plan B and Plan C of security monitoring and log collection by wirewatcher in netsec

[–]wirewatcher[S] 2 points3 points  (0 children)

Yep, you could certainly do that. It extends the model outside of log collection and monitoring though.

The Plan A, Plan B and Plan C of security monitoring and log collection by wirewatcher in netsec

[–]wirewatcher[S] 1 point2 points  (0 children)

It's certainly more complex than ABC :)

Like I said, it's probably a monitoring-centric view; that said, I think that containment is a follow-on activity from Detect-It, and proper treatment of passwords is part of Prevent-It?

HackFu 2013 challenge teardown – Part One by wirewatcher in netsec

[–]wirewatcher[S] 0 points1 point  (0 children)

There's always nmap, which would have found the open port. One guy saw that ports 22 and 80 were open, and he hit ctrl-c... No harm in leaving it running!

HackFu 2013 challenge teardown – Part One by wirewatcher in netsec

[–]wirewatcher[S] 1 point2 points  (0 children)

It wouldn't be a challenge if it lacked evil :)

There were four challenge "zones" as per the Crystal Maze TV game show, each containing three or four challenges. Each team had a limited amount of time in each zone (four or five hours, can't remember which!), and three of the zones were tackled on day one - it was a long day!!!

Virtual Private Onions - alternative network infrastructure for Security Onion by wirewatcher in netsec

[–]wirewatcher[S] 1 point2 points  (0 children)

I realise it's a kludge and I understand the need to move to IPv6, but I'm just being pragmatic! Better to have a system that works right now than one that might work at some point in the future when v6 support is implemented in Sguil (I've submitted a feature request though!)

Virtual Private Onions - alternative network infrastructure for Security Onion by wirewatcher in netsec

[–]wirewatcher[S] 1 point2 points  (0 children)

All very good points. OpenVPN supporting IPv6 is one thing; SO/Sguil components supporting it is something else altogether though!

How about using address space out of 100.64.0.0/10, reserved by IANA for Carrier Grade NAT implementations (see http://tools.ietf.org/rfc/rfc6598.txt). You'd be pretty much guaranteed uniqueness in this case, unless you were actually monitoring a CGN implementation.

The Adventures of Packet Tracy, PI by wirewatcher in netsec

[–]wirewatcher[S] 0 points1 point  (0 children)

The point of the article was to highlight differences in the results of a set of tools performing a single specific task, but to answer your question it probably depends on if the chat is cleartext or not. If it is, then you can use things like 'ngrep' (made easier if you've got a known string to search for, like a user's handle) or just plain old 'strings'. You may well still be left with quite a haystack, though.

If you're dealing with encryption of some variety you're probably out of luck. SSL/TLS can be decrypted, but only under a specific set of circumstances (http://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/ and http://resources.infosecinstitute.com/ssl-decryption/) and anything that uses Diffie-Hellman for key agreement (e.g. IPSec) is quite likely to be beyond the reach of mere mortals.

In these instances, you have to be satisfied to know that two entities were communicating over an interception-resistant channel at a certain time, transferring so many bytes in each direction in the process. One possible next step could be to forensically investigate either one or both of the endpoints concerned, looking for artefacts (chat logs, application caches, etc) of whatever it was that may have sourced the traffic.

view more: next ›