antipaucity

Law 32

The truth is often avoided because it is ugly and unpleasant. Never appeal to truth and reality unless you are prepared for the anger that comes from disenchantment. Life is so harsh and distressing that people who can manufacture romance or conjure up fantasy are like oases in the desert: Everyone flocks to them. There is great power in tapping into the fantasies of the masses. –Robert Greene, The 48 Laws of Power (review)

They always go dead when you need them most – so stock up.

Especially at employee personal whiteboard, meeting rooms, and class rooms.

For a long time I have been interested in real, actual, legitimate security. I am not a fan of the widespread use of security theater in our “post-9/11 world”, as Bruce Schneier calls it.

Integrisure was supposed to be a real-world pentesting of “secure” facilities, a la Sneakers. In late 2000 / early 2001, I was working on a business plan and the initial legwork to find out what licensing, certificationss, etc I would need to do security testing at locations like airports.

Integrisure never happened. You can’t google it (well, ok – you can google it now: but you’ll only find this blog post and a bunch of unrelated businesses).

The basic business plan was as follows:

• establish contacts among management and security directors at various business and government facilities
• establish time ranges when we can arrive onsite
• using a team of known, documented, anonymous-looking individuals, find holes in security environments
• using always non-destructive means, attempt to tail-gate, leave “suspicious” items in conspicuous and inconspicuous locations, gain access to authorized zones, etc
• have plausible stories pre-built if anyone was “caught”
• report the results of our simulated attack, including all positives as well as issues, and provide consulting to our client “target” on how they could improve their physical security

More detailed aspects of the planned business were discussed, and written down, between myself and a couple of other folks who wanted to start with me.

We had a start date planned: we would form the company in Jan 2002 (so our fiscal year would align with the calendar year). We had several initial employee/contractors identified – some current or former military members, technical folks, and others.

I had even contacted a couple local companies that did security guard services to see if this was something they would either like to offer as a service, or would help participate in coordinating with their contacts.

Life was looking good. I graduated in May 2001 with my AAS, had some solid job prospects in computer programming and IT work, and was lining-up who I expected would be a great team to start Integrisure’s activities.

Then 9/11 happened.

Airport “security” was federalized, my two front-running programming/IT jobs went on hold and/or laid people off (most of their customers were in downtown Manhattan), and suddenly private companies checking for holes in security were not going to fly. (Especially at airports! 🙂 )

Establishing and building a community around a common interest is hard.

After exhausting your network of friends, coworkers, neighbors, etc – the only way of getting new folks into the community is to aggressively campaign and advertise to them.

Let’s say you’re a technical user group (like a couple of the ones I’m a part of). And every month you have about 5-7 folks who show up on the Appointed Day™ for the regular meetup. You can either be satisfied on the size of the group, or you can try to grow it.

Growing it, however, is never easy: there are scheduling conflicts, personality clashes, lack of contacts, etc.

What are the best ways – or even just “ways”, ditch the “best” – of growing a community after you have gone through everyone you know?

Law 31

The best deceptions are the ones that seem to give the other person a choice: Your victims feel they are in control, but are actually your puppets. Give people options that come out in your favor whichever one they choose. Force them to make chocies between the lesser of two evils, both of which serve your purpose. Put them on the horns of a dilemma: They are gored wherever they turn. –Robert Greene, The 48 Laws of Power (review)

Whether you’re familiar with the Stack Exchange family of sites and services (askubuntu.com, stackoverflow.com, etc), or not, I encourage you to check-out and support this new DevOps proposal to see if maybe it can get to a critical mass and launch as its own Q&A site on the SE network

http://area51.stackexchange.com/proposals/66151/devops?referrer=k13Ji_hD0QxN04cgiNoUkQ2

After running into some wacky networking issues at a recent customer engagement, I had a brainstorm about a smart[ish] DHCPd server that could work in conjunction with DNS and static IP assignment to more intelligently fill subnet space.

Here’s the scenario we had:

Lab network space is fairly-heavily populated with static assigned addresses – in a /23 network, ie ~500 available address on the subnet, about 420 addresses were in use.

Not all statically-assigned IPs were registered in DNS.

The in-use addresses were did not leave much contiguous, unused space (little groups of 2 or4 addresses open – not ~80, or even a couple small batches of 20-30 in a row).

DNS was running on a Windows 2012 host.

DHCPd (ISC’s) was setup on an RHEL 5×64 Linux machine.

The problem with using the ISC DHCPd server, as supplied by HPSA, is that while you can configure multiple subnets to hand-out addresses on, you cannot configure multiple ranges on a single subnet. So we were unable to effectively utilize all the little gaps in assigned addresses.

Maybe this is something DNS/DHCP can do from a Windows DC, but I have an idea for how DHCPd could work a little smarter:

• give a very large range on a given subnet (perhaps all but the gateway and broadcast addresses)
• before handing an address out, in addition to checking the leases file for if it is free, check against DNS to see if it is in use
• if an address is in use because it is static, update the leases file with the statically-assigned information as if it were assigned dynamically – but give it an unusually-long lease time (eg 1 month instead of 4 hours)
• on a periodic basis (perhaps once an hour, day, week – it should be configurable), scan the whole subnet for in-use addresses (via something like nmap and checking against DNS)
  • remove all lease file entries for unused/available IPs
  • update lease file entries for used/unavailable IPs, if not already recorded

This would have the advantage of intelligently filling address gaps on a given subnet, and require less interaction between teams that want/need to be able to use DHCP and those that need/want static addresses.

Or maybe what I’m describing has already been solved, and I just don’t know how to find it.