Kali Linux in the Enterprise

[dgillette]

Anyone have any thoughts about how Kali Linux should be deployed in an Enterprise environment?

Here's a rough draft I came up with. Am I missing anything? The OS will be installed on a laptop.

1. Permanent install on HD
   1. Advantage: Work is saved between boots
   2. Disadvantage: Entire reinstall is required for fresh copy
2. Live boot from USB
   1. Advantage: Fresh install on each boot. Nothing is saved to HD. USB can be easily locked away or destroyed.
   2. Disadvantage: Work is not saved between boots
3. VM on Windows server
   1. Advantage: Can be destroyed between client assessments 
   2. Disadvantage: Wireless testing not possible without external antenna. Windows is (arguably) less secure than Linux.          

1. Access control
   1. MFA
   2. PAM
   3. IPTABLES

1. Physical  segmentation
   1. <how/where will the laptop be secured?>

1. Logical segmentation
   1. No access to internet except for upgrades
   2. Static IP
   3. Do not join to the company domain

1. Security
   1. Full Disk Encryption
   2. System files verification checks
   3. Disable all external network services unless needed (disabled by default). Disable when no longer needed.  

1. User qualifications
   1. <certifications?>

1. Availability
   1. Only connected to the network when in use
      1. Advantage: Not available to be used for nefarious purposes
      2. Disadvantage: Remote staff shut out if on-site staff unavailable
   2. Connected to the network at all times
      1. Advantage: Available for staff to use whenever needed
      2. Disadvantage: Available to be used for nefarious purposes

1. Logging
   1. Log all user activities and processes to Splunk
   2. Alert on all user activity. Throttle for estimated duration of work if authorized.

[mgoblue93]

> Anyone have any thoughts about how Kali Linux
> should be deployed in an Enterprise
> environment?

Why are you installing Kali in an enterprise?

> 1. Permanent install on HD
> Disadvantage

If you're testing with Kali and if you install in a VM rather than bare metal, keep in mind you'll have 2 NICs exposing yourself to your IDS.

> Live boot from USB
> VM on Windows server

I grouped these two things together because they are the same thing. You're deploying from a "template" so that you're not leaving a footprint.

The only thing I would say is your org allows USB drives?

> Availability

You haven't articulated your requirements yet. Without knowing your requirements, it's difficult to provide suggestions.

[Baechle]

David,

You got some really good information laid out.  I’m a little confused about what you’re doing with the document though.

Is this a decision support paper for deploying Kali Linux or is this supposed to be a standard operating procedure document?  Or is it something else entirely?

Also, there are many additional considerations you may want to make based upon what organization/data the enterprise systems are supporting.

Just a quick note:  Using a LIVE copy of any kind of pen-test or repair tool is a bad idea.  A marble may fall out of your pocket without notice – but it’s hard not to notice a cannon ball missing.  They’re easy to smuggle, forget and leave connected, drop, etc.  It gets even worse if you have a LIVE USB with a non-volatile storage area for your test results.  It’s best to have a dedicated computer for this kind of work that you can lock away in a cabinet or safe accessible by the security staff only.

Sincerely,

Eric B.

[dgillette]

Why are you installing Kali in an enterprise? For Security auditing and pen testing.

If you're testing with Kali and if you install in a VM rather than bare metal, keep in mind you'll have 2 NICs exposing yourself to your IDS. Thanks. This is the type of feedback I'm seeking.

The only thing I would say is your org allows USB drives? No, we don't. Would only be allowable on the laptop.

You haven't articulated your requirements yet. Without knowing your requirements, it's difficult to provide suggestions. This just means should the laptop be connected to the network at all times or not. I work remotely so I would have to get one of my colleagues to connect the laptop if I wanted to use Kali.

[dgillette]

Eric,

I'm making a presentation to my customer about deploying Kali in their environment. They are understandably concerned about the security implications and want to know all the facts.

Thanks for the feedback about not using a live copy. Makes total sense. 

[brianwaala]

I would recommend a permanent install on a HD but if you opt to use VM, then I'd recommend Oracle Virtual Box.     If doing an install to HD, I'd recommend that you use separate partitions for /usr, /var, and /logs and /boot. this way these partitions are limited and these partitions do not spoil or fill up your harddrive.   Also, when needing to do restores using these separate partitions will make your life a lot easier.  

And make your install default to runlevel 5.  Also, make sure you use UTC time variants.  This will make sure that applications work correctly, are time synchronized and that there is no confusion about the time stamps on your logs.  For example, for Chicago CST time, chose six time zones behind UTC.    Use the TZ variant to set the time zone.

Important consideration, LInux uses 5 file formats and I'd recommend considering using ext4 for the format. Reiser is probably overly complicated (one of the file formats).  

[Beads]

Personally I don't use any number of tools on the backtrack CD/kit itself however, am proficient with a number of FOSS tools contained therein, i.e. NMAP, Burp Suite, etc. I would be reticent installing a host of uncommon tools on my network supervised or not. Kismet, NetCat, SCat et. al. hold little to no value on my particular network at this time as better controls have already been installed.  A better practice would be to use VM Workstation on a separate laptop only used for such a purpose. Nothing like finding your network compromised while lo and behold! A full version of questionable FOSS tools for the taking. These just create more work for my NBADs.

Just because it exists doesn't mean its a good idea to install. Will admit you can't beat free and its good from a baseline of understanding but there are tools so much better than what your going to find within that compilation and so much of that CD is going to be of little value unless your going to spend months of time configuring and testing with it. Your time is likely (I hope) better spent learning your network and defending properly.

Kali is fine for many basic penetration tests but hardly a useful auditing tool. That's why SIEM was invented.

[mgoblue93]

> For Security auditing and pen testing.

For security auditing and pen testing isn't a reason to install Kali in the enterprise.  Putting something like kali in the enterprise is just increasing your attack surface.

Why not just have Kali on a laptop and plug it in when needed? 

> This just means should the laptop be connected

> to the network at all times or not

Well, that certainly depends on frequency of use.  Regarding my previous comment, and what we do here locally, is NOT keeping Kali on the network at all times.  We test about once a month and for a week.  Our Kali laptops are only connected when needed.

> I work remotely so I would have to get one of my colleagues 

> to connect the laptop if I wanted to use Kali.

You don't have a secure route when working remotely?  That may be something you want to look into when pitching this to your stakeholders.

[dgillette]

You don't have a secure route when working remotely?  That may be something you want to look into when pitching this to your stakeholders. I use a VPN of course. What I'm saying is if the laptop isn't connected to the network at all times I'd need to ring one of my colleagues up to have them connect the laptop to the network if I needed to use it. It seems like the consensus so far though is to not leave the laptop connected to the network at all times. I am not totally convinced of that at this point. If the right precautions are taken as I have outlined the risk is low as I see it. The biggest risk I see is an authorized user doing something stupid. That's hard to mitigate. But this is why I'm throwing the question out there. I could be missing something here.

[mgoblue93]

> What I'm saying is if the laptop isn't connected

> to the network at all times I'd need to ring one of

> my colleagues up to have them connect the

> laptop to the network if I needed to use it.

That seems really odd to me.  If you have a VPN from a remote location to the mothership, I'm not grasping this dependency upon a hard wired connection.  Oh well, I won't bog the conversation down with that anymore. 

> I am not totally convinced of that at this point. If the right

> precautions are taken as I have outlined the risk is low as I see it.

Yeah, I think folks are saying 2 things.  1. Having the Kali tools on the network 24/7 increases exposure.  2.  Relying on personnel controls is not a recommended practice. 

But of course, your mileage may vary and risk appetite is determined ultimately by the system owner. but just keep in mind, *nix doesn't protect one from themselves.  

> The biggest risk I see is an authorized user doing something

> stupid. That's hard to mitigate. But this is why I'm throwing

> the question out there

Fair enough... but perhaps taking a look at some network isolation is worth it for when that 24/7 connected laptop is idle.  Can you terminal into your layer 2 device to bring a vlan up for testing or down for storage example?  Then you're never calling your colleagues to connect the cable... just accessing the switch.

One final thought jumped in my head when I mentioned "network".  My colleagues and I find the Network Manager Debian ships to be painful.  In all of our Kali instances, the first thing we've done is uninstall and purge network-manager.  We then add our NICs to /etc/network/interfaces and /run/network/ifstate.  When running Kali, we manipulate addresses as needed from the command line and bring up NICs with ifup or ifdown.  It takes less than 2 seconds to configure the box and don't run into any of the profile contention problems one can see when using the GUI to manage the network.

HTH