I thought I’d already disabled mDNSResponder when I did some basic hardening of my Laptop. Turns out that when Marty (no, I am not refereing to myself in the third person) asked me whether I disabled it and I checked again, it was really not. Maybe I just killed the process, but here is how to really disable that service:

Launch the following command

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

The next step is turning off the mDNSResponder at startup. And where do you do that? As I am not really confident getting online here at BlackHat, I decided to just look around on the hard drive and what I found was that you could probably just change an entry in the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist file:

<key>OnDemand</key>
<false></false>

Replace false with true. Do you notice something? Someone really knew XML. Darn it. Two elements. One being the key, the other one being the value. Ever heard of attributes in XML? To whoever built this, this is how I would write the entry:

Or even better, re-architect the entire XML file to actually make sense!

I just now found the real way to actually disable the service by using the -w flag on the launchctl command from above. That will turn the process off permanently. A good reference is here.

No! OS X is not FreeBSD! Not sure if I’d like OS X better, if it was just FreeBSD on steroids.

I am sitting at BlackHat. Yes, I turned my laptop on, but the network interfaces are turned off! I was going to configure my firewall to lock everything down and then go online. First shock: <b>ipfw</b> is the firewall OS X uses. There is some history with me and ipfw. I am a big fan of OpenBSD and when Daniel wrote the pf firewall to replace ipfw , I was delighted. I started using pf and even fiddled around with the source code. I am no expert on all the features anymore, but I got a pretty good handle on that beast at some point. Now I have to learn ipfw… Okay. Let’s do that and face the challenge.
First things first. Where’s the configuration file for it? Hmm… There is a guy. Let me play with that. I am shocked. By default, UDP traffic is allowed in and out, even if you turn off all your services in the main tab. Only if you use the advanced tab, can you turn UDP off. Logging is not turned on either (what a surprise). Alright, I am turned that on too. How do the rules look now? OMG! Ridiculous. It allows port 5353, 137, 427, and 631 inbound! Why? Turn that off! Lesson learned: Don’t use the default config. Again, show me the configuration file. But where is it?

I still haven’t found it. I am just going to write a script which uses the <b>ipfw add</b> command to add ipfw rules one by one. That’s really the same thing I am doing with iptables on my Linux boxen. But before doing so, I wanted to see how ipfw log entires look. To test that, I added the following rule:
<code>deny log ip from any to any</code>
I just wanted to see how a log entry looks when I telnet to some port on my box. Well. Surprise surprise. Right after adding that rule not much worked anymore. <b>sudo</b> is not functioning anymore. Some digging around and I realized that the <b>/etc/passwd<b> file is not used for authentication! It’s some service that uses the loopback interface. Not really sure what to do without sudo and a bit frustrated, I closed the laptop to resume later. Well, later, the laptop did not wake up anymore. Authentication gone! It just hung. A reboot was necessary. Darn. At this point I am really frustrated!

I think my next step is to go out and take Jay’s Bastille Linux scripts to see what they are going to do to my box. I actually hope Jay is going to show up here in Vegas so I can bug him about some of my OS X things 😉
[tags]OS X,ipfw[/tags]

I am still waiting for that one company which is going to develop the univeral agent!

What am I talking about? Well, there is all this agent-based technology out there. You have to deploy some sort of code on all of your machines to monitor/enforce/… something. The problem is that nobody likes to run these pieces of code on their machines. There are complicated approval processes, risk analysis issues, security concerns, etc. which have to be overcome. Then there is the problem of incompatible code, various agents running on the same machine, performance problems, and so on.

Why does nobody build a well-desgined agent framework with all the bells and whistles of remotely managed software. Deployment, upgrades, monitoring, logging, etc. Then make it a plug-in architecture. You offer the most important functionality already in the agent and let other vendors build plug-ins which do some actual work. You would have to deploy and manage exactly one agent, instead of dozens of them.

Well, maybe this will remain wishful thinking.

Well, I was travelling again and I read my way through some of the ISSA magazines that stacked up on my desk over that past months. I have to admit, the quality of articles I read has actually improved. That does not mean that I don’t have any comments…

I read this article in the March 2006 issue of the ISSA journal about Auditing on Linux/Unix. While I like the article and how it outlines what you can do to harden a UNIX box, it is yet another article which fails to mention how hard it is to enable real auditing on Linux. I have yet to find a comprehensive guide about how to enable the auditing you really need on a Linux box. Not a single word was spent on the pam modules. The article mentiones process accounting via accton but does not really mention how that can be used and how this could be handled in a distributed logging environment. How do you get all of this data into syslog instead of looking at it via lastcomm?

Maybe these things could be addressed in a follow-on article?

I keep running into these little annoyances in Linux. (And as I said here before, I love Linux, but there are some things which are just bad.) This time I was trying to see what happens if you lock an accound. You didn’t even know you could do that?

passwd -l 

Do you know what syslog has to say about this?

Nov 14 16:35:12 zurich passwd[21226]: password for `test' changed by `root'

And even worse, if you unlock:

passwd -u 

Linux says:

Nov 14 16:35:12 zurich passwd[21226]: password for `test' changed by `root'

Great! What am I supposed to do with this? Is a password change really the same as a lock out of a user?

To continue on the path of auditing and such, have you tried to configure an automatic lock-out after a certain amount of failed logins? Good luck. After a while you might find pam_telly. You have to use this PAM module to achive that lockout. You can configure after how many failed passwords an account gets locked. Again, why is this in such a hidden module? Why not built-in? Is anyone going to rebuild the authentication sub-system? Please? And if you are at it, rethink the whole logging infrastructure too! Don’t forget to use a common log format, a specific fixed format that enforces certain information and is parsable! Stop logging copyright messages into syslog (Ok: dhclient?).

I am disappointed. Have you ever tried to audit your linux system? Well, have you tried to get syslog events for password changes? Why would linux not log an event like that? You have to go and mess with the PAM configuration of you system. And I don’t think it’s straight forward to actually get the user management sub-system to log audit events. I want to know when someone changes his password or a user account is disabled! I guess part of the problem is that you can always go to the configuration files (/etc/passwd) and just change the entries yourself, but you know, we are in 2006, you would thing someone has figured out how to audit these things. Have I already mentioned that I am disappointed? And don’t misunderstand me. I love Linux, but still.
One solution that VanHauser recommended was LAUS. An auditing subsystem which was initially developed for SUSE. A port for Redhat exists also. Since I switched to Ubuntu, I tried an apt-get install laus. No luck. Too bad.
Maybe I am just missing something and there is a solution to the audit log shortcomings of Linux?

While I am not at all a fan of the “security through obscurity” paradigm, I think in some cases it has its benefits. For example in preventing automated scripts (i.e., worms) to compromise your box. I found this page about “Port Knocking” which only opens port 22 if you connect to a series of other ports beforehand. What I like about this solution is the simplicity by using iptables.
The solution uses the

-m recent –rcheck

feature of iptables to open port 22 if a certain other port is being connected to.

Something that comes in handy all the time (as proven today when someone asked me about how to do it), is how to setup a reverse SSH tunnel. (Especially when you need to access your work computer from home.) Well, my SSH page explains the procedure.