CryptedNets

I’m not going to try to write a how-to on this, but suffice to say that it finally works!
I configured Samba3, PAM, and Kerberos on Ubuntu 9.10, and I can share folders to Windows client workstations using their existing authentication to the domain controller. I can even set ACLs that seem to be obeyed, and use Windows group membership to determine access rights.
Here are some links with relevant information:

The Samba WIKI (geared towards RHEL, but still helpful.)
How To Integrate Samba Using Active Directory For Authentication (geared towards Gentoo linux, but still helpful)
Ubuntu Samba info

I’ll certainly try to answer any questions you’ve got, just post ‘em.

The manuals are attached to the original post here->

http://www.cryptednets.org/?p=137

Thanks for emailing them, Robert!

You know, I’ve been reading a lot about this worm lately…
And it’s starting to piss me off..

If you stand back, and think about what the end-game of this worm is supposed to accomplish, the only valid goal of this worm that *I* can see is to teach everyone about DNSSEC.

Remember Dan Kaminsky’s finding about how insecure DNS is? And that in order to correctly secure it (DNS, and the whole Domain Namespace), *EVERYONE* needs to implement DNSSEC?

Well, you and I both know that “Ye can lead a man up to th’ University, but ye can’t make him think…” –Peter Finley Dunne

So, if *I* were an ultimate Uber-hacker, and I was tired of you un-washed, un-patched, un-protected legions of bandwidth-clogging, router hanging, mangled packet-spewing, infectionbots.. What better way to teach you all about how and why to secure your systems?

“If I can’t convince you, I bet I could *FORCE* you to start using DNSSEC….”

Say what you will… I call conspiracy….

P.S. – This in no way is meant to point the finger at Dan Kaminsky. I believe he is a true whitehat, and wouldn’t engage in such a guerilla tactic. We should all thank him for his contributions, and follow his lead.

Recently, I needed to determine which local LAN hosts were infected with spyware on a network of Windows XP computers. This network is a single Active Directory Forest, with a single ‘domain.local’ domain name.
In the absence of any anti-spyware management tools, I decided to use the DNS server on the domain controller to help me determine which workstations were infected.

First, I changed the outbound forwarder servers to use OpenDNS. OpenDNS is a free recursive DNS service that you can use to resolve all DNS queries on the Internet safely. The reason for this is that the OpenDNS servers will re-direct your infected machine’s traffic away from known botnets and known distribution points for spyware to their own, essentially cutting off an infected workstation’s access from known “bad guys”.

Usually, when I implement the OpenDNS service on a LAN, I notice an *INSTANT* improvement in available bandwidth.. Try it for yourself. More info here: www.opendns.org

Next, you need to clear the cache on your DNS server. To do this, open DNS Management in your MMC, right-click the server, and click “Clear cache”. Now, click “View”, and “Advanced” in the MMC’s menu, and you can now view the cache.
Right-click the server again, and click “Properties”.
On the “Logging” tab, turn on “Debug Logging”, note or set the location of the log to be written.
Now, right-click the server, and click “All Tasks” -> “Restart” to restart the DNS service.
Since most spyware infected hosts need to phone home on a regular basis, you can now just watch the cache for incriminating lookups, and read the DNS debug log for the IP address of the offending hosts.
Anyway, it worked for me, and I was able to identify the 3 hosts on the LAN that had spyware infections, in about 10 mins… (without staring at a protocol analyzer…)

Note: Do not forget to turn the DNS debug logging off again when you are finished. This logfile will grow *very* quickly, and become difficult to open or manage within hours on a busy LAN.