[khiltd]

Then you want to be a gateway, not a proxy.

[khiltd]

What kind of proxy? HTTP?

[khiltd]

There are “Misc” and “Open Mike” forums that would probably be more appropriate than the Q/A forum.

[khiltd]

Tiger’s version was slightly less buggy, and then there’s Iceberg. Otherwise you’ll have to do it on the command line sans project file.

[khiltd]

Leopard’s PackageMaker spontaneously changes your project’s settings without reason or warning on a fairly regular basis. Nobody at Apple has offered a solution more helpful than “file a bug” that I’m aware of, but you can check the mailing list.

[khiltd]

Did you create an A record for domain.com or just NS records?

[khiltd]

I’m not sure this belongs here, but good luck.

[khiltd]

Typically you’d setup a single A record and then create multiple CNAME records for its aliases.

[khiltd]

Any name you want to resolve needs to have a DNS record, yes.

[khiltd]

[QUOTE][u]Quote by: MacDave[/u][p]Thanks so much – that post was really helpful, and the DNS trojan you mentioned seems to be exactly what happened. I found this article on it:

http://ithreats.wordpress.com/2008/01/11/analysis-of-osx-trojan-dns-changer/

which goes into some detail about exactly what it does.[/p][/QUOTE]

That would be the original version which requires quite a bit of user assistance in order to elevate an installer script’s permissions. The hole I found requires no elevation whatsoever so long as it is run under an admin account.

[khiltd]

I can’t say that this is what’s to blame in your case, but I found and documented a fairly serious security hole in Leopard that allows pretty much anybody in the world to muck around with your network settings without so much as an authentication dialog:

[url]https://www.afp548.com/forum/viewtopic.php?showtopic=18982[/url]

The response I got from Apple was something along the lines of “so what.”

I’d grep for those IPs, strip them out of whatever files you find them in and make sure you keep your network settings locked. If they turn up again then it’s obviously another issue.

[url=http://www.khiltd.com/Downloads/Consultant’sCanary.zip]This script[/url] will catalog much of the third-party software installed on the machine and may turn up something suspicious, but if it really is a trojan of some sort odds are good the developer spoofed the Info.plist file to make it look like it came from Apple. If that’s the case it won’t find anything useful, but might be worth a shot anyway.

It’s pre-compiled Python so you’ll need to invoke it as follows:

[code]python cc.pyo [/code]

[khiltd]

Sounds like filesystem corruption to me.

[khiltd]

Certificate Assistant is incredibly buggy, and even when you do everything right it will frequently fail to generate anything useful and leave a bunch of hung orphan processes laying around you either have to find and clean up or restart the entire machine before it will let you try again. It’s much easier to simply use openssl directly:

[code]openssl genrsa -des3 -out ca.key 2048

openssl req -new -x509 -days 365 -key ca.key -out ca.crt[/code]

[khiltd]

Tomcat is for serving JSP content. You probably shouldn’t worry about it.

[khiltd]

I’m sure that somebody here has some experience with Windows 2003’s DNS server, but you would probably have better luck elsewhere since this really doesn’t seem to be a Mac issue at all.

[Author]

Posts