I love my privacy screen on my laptop. I can work with a little more security, thinking that as like it’s less likely that someone is watching what I’m doing. That said, and there are some trade-offs. One of them is if you want to collaborate with someone, it’s harder for them to see your screen. You’ll need to be sitting directly in front of the screen, so both people will need to be sitting pretty close to each other. On a phone, The same issues apply. Except often, people like to make videos or take photos and if you’re taking photos away or example if you have to raise your arm up and try to snap a photo of something down like if you’re at a ball game or if you want to take a selfie, it will be more difficult. It’s more likely that you won’t even see yourself or see what you’re filming or taking a photo of. On top of this, other issues including when you if you’re watching high definition movies, you lose a little bit of picture. It does not look as good as if you were watching without the privacy filter. And also, you will need to adjust the brightness of your screen. On the phone, this causes another big problem.The battery does not last as long and the phone gets hot very quickly. All that said, I still prefer my privacy and I will continue to use my privacy screens on both my laptop and my phone. I just need to remove it when working with others or if I’m in the sun or driving.
This is a real-world situation I got myself into when I tried connecting to my client VM and found a BSOD that looked like this:
It’s pretty obvious that the reason for the crash is the USB stick that’s plugged in from the usbuhci.sys line in the blue screen. Since I tunnel into my client VM via SSH and VNC, the easiest way for me to shutdown my VM and remedy this issue is through vim-cmd. This only works if you have SSH allowed onto your ESXi host or if you are connecting to the host with the VMware CLI or vMA or whatever they’re calling it these days. I have the former.
The first thing I do after logging into the ESXi host as root is run:
vim-cmd vmsvc/getallvms
I need to know which one of my VMs is the one to manage. I get this:
With this information, I know that it’s VM 1, so I power it off by running:
vim-cmd vmsvc/power.off 1
Thinking the USB issue might be a fluke, I try to power the VM back on to see if it will boot.
vim-cmd vmsvc/power.on 1
I see that it starts booting, but as the resolution changes on the VM, my VNC viewer freezes. Since I normally don’t know exactly when it freezes, I didn’t know when I got the BSOD again.
Until I decided to at look at the vmware.log file. This is what I saw there:
Okay, so I see that my hunch is correct. I guess it’s time I remove the USB device from the VM. So I power off the VM again and open up the vmx file and just start removing all instances of USB.
These are the lines I removed. Don’t worry about breaking anything. The hypervisor will put them back if you need them later. Back up your vmx file before doing it though just in case.
After you’ve saved your changes, you’ll need to reload the changes so that ESXi will reread the .vmx file to remove the USB device. You can do this by running this command:
vim-cmd vmsvc/reload 1
Now you’re ready to power on the VM.
vim-cmd vmsvc/power.on 1
The VM powers up and I’m back in business. I just had to figure out the USB issue later. Turned out that I just needed to reconnect the device and reformat it. I haven’t seen the issue come up again.
At least kernel-3.10.0-514.26.2.el7.x86_64.rpm is broken. With it, you will not be able to use a stack size lower than ~4.5MB.
Here’s some reading on why your applications would want to do this: https://www.systemcodegeeks.com/shell-scripting/bash/using-rlimit-and-why-you-should/
Here’s an excerpt:
Why do we care?
Security in depth.
First, people make mistakes. Setting reasonable limits keeps a runaway process from taking down the system.
Second, attackers will take advantage of any opportunity they can find. A buffer overflow isn’t an abstract concern – they are real and often allow an attacker to execute arbitrary code. Reasonable limits may be enough to sharply curtail the damage caused by an exploit.
Here are some concrete examples:
First, setting RLIMIT_NPROC to zero means that the process cannot fork/exec a new process – an attacker cannot execute arbitrary code as the current user. (Note: the man pages suggests this may limit the total number of processes for the user, not just in this process and its children. This should be double-checked.) It also prevents a more subtle attack where a process is repeatedly forked until a desired PID is acquired. PIDs should be unique but apparently some kernels now support a larger PID space than the traditional pid_t. That means legacy system calls may be ambiguous.
Second, setting RLIMIT_AS, RLIMIT_DATA, and RLIMIT_MEMLOCK to reasonable values prevents a process from forcing the system to thrash by limiting available memory.
Third, setting RLIMIT_CORE to a reasonable value (or disabling core dumps entirely) has historically been used to prevent denial of service attacks by filling the disk with core dumps. Today core dumps are often disabled to ensure sensitive information such as encryption keys are not inadvertently written to disk where an attacker can later retrieve them. Sensitive information should also be memlock()ed to prevent it from being written to the swap disk.
This was a pretty fun project that I had gotten so I figured I would share the experience. There are multiple use cases for virtual desktops. In our case, it’s ephemeral – only need them for a few days for a class so that all students can share the same experience without the need for anything but a web browser. They can probably get a better experience with the PCoIP client, but it could be against some company policies. Most companies will allow HTTPs out, so we figured this would be the easiest way.
The way Amazon WorkSpaces works is that each desktop is assigned to a single user and the users sit in the directory service. The service I’m using is the Simple AD (Samba 4) as I had no need for a huge directory. To create the users, we will just need a UID (sAMAccountName in AD) and a password if using the API to create the desktops. If using the Amazon portal to create the desktops, you’ll need the first and last name and an email address as well. You can easily import a CSV file with this information, but for the sake of simplicity, I just use a generic account name and numbers.
After creating the directory and starting up a single desktop, I went to the “Programs” in the Control Panel and “Turn Windows Features on and off” and “Features” to install the “AD DS and AD LDS Tools”. More information on the RSAT tools is available here: https://wiki.samba.org/index.php/Installing_RSAT
Here’s a short video on how to do it:
Once the RSAT tools are installed, the “dsadd” command will be available to add users. This is the script I’m using that asks for the users and then creates the users:
echo off
set /p users=Number of users to create:
echo "Creating %users% students"
set count=0
:createusers
set /a count+=1
echo creating student%count%
dsadd user "cn=student%count%,cn=users,dc=corp,dc=amazonworkspaces,dc=com" -samid student%count% -pwd Student%count%
if "%count%"=="%users%" goto done
goto createusers
:done
The script will create users with the username student# with passwords Student# – the capital “S” is just for password complexity.
After creating the users, we can go and create the desktops. To do this, I used awscli. On a Mac or Linux system, it can be easily installed running “easy_install awscli”. After installation, there will be a config and credentials file that should be configured in the .aws directory in your home directory. Once that’s set, you can check to see what workspaces you have by running “aws workspaces describe-workspaces” – that gives you an idea of what your workspaces look like. The minimal template I’m using for workspaces looks like this:
The DirectoryId is the directory service where the users are housed, I’ll be replacing the %username% with student#, and I added RunningMode just to save on costs – they’ll automatically suspend after an hour of idling. It takes about 90s to spin back up if they suspend. The BundleId is the VM that you want to provision. This one is the customized one for our classroom.
With the template in place, we’re ready to run the script:
#!/bin/bash
echo "Number of Desktops to Create [20?]"
read desktops
echo $desktops
COUNTER=0
while [ $COUNTER -lt $desktops ]; do
let COUNTER=COUNTER+1
echo Creating Desktop number $COUNTER
sed "s/%username%/student$COUNTER/g" create-workspaces.json > /tmp/student$COUNTER.json
aws workspaces create-workspaces --cli-input-json file:///tmp/student$COUNTER.json
done
echo Created $desktops Desktops.
You can remove the temporary files in /tmp afterwards.
I had the privilege of experiencing AIX for the very first time this week. Hopefully this can save someone else time.
Some packages that aren’t installed by default that you might want include openssl, openssh, unzip, zlib, and IPFilter.
I would probably start with openssl/openssh. In AIX 7.2, you can do it in the OS installer. To do it outside of the installer, keep the installation cd in and run the following commands:
You can install IPFilter from https://www-01.ibm.com/marketing/iwm/iwm/web/reg/pick.do?source=aixbp. It will require a login, but not a serial number. Just create a login and download. Installing IPFilter is a little different. It installs like an AIX package, with installp. Unzip the contents of the IPFilter_Fileset.zip and go into the IPFilter_Fileset directory and run the following commands:
If you’ve got a *Nix machine on the public Internet, you will experience this at one time or another. If you run sshd on its’ known port 22, some script kiddie out there will attack it. With that, you’ll see that you’ll have a bunch of connections that probably and hopefully will never succeed. I saw these messages in my /var/log/auth.log:
Nov 15 06:44:26 chunli sshd[20634]: Failed password for root from 43.229.53.13 port 41751 ssh2
Nov 15 06:44:26 chunli sshd[20636]: Failed password for root from 43.229.53.13 port 41921 ssh2
Nov 15 06:44:26 chunli sshd[20638]: Failed password for root from 43.229.53.13 port 42948 ssh2
Nov 15 06:44:26 chunli sshd[20546]: message repeated 2 times: [ Failed password for root from 43.229.53.13 port 27586 ssh2]
I’ve experienced this before and to alleviate this problem, I used sshdfilter in the past. I know that there are others out there like sshblack that can do blacklisting of attackers or one of the easiest ways to alleviate this problem is just to run ‘sudo ufw limit ssh’. This is a way to block them from coming back for a while.
To get started, first stop SSH:
sudo initctl stop ssh
Then move /etc/init/ssh.conf out. We’ll start SSH with sshdfilter instead.
You’ll get a message in the auth.log here:
auth.log:Nov 16 19:54:36 chunli sshd[1150]: Missing privilege separation directory: /var/run/sshd
Because of this, we’ll just add a line in the /etc/init.d/sshdfilter file like this:
Under the “Add a block rule” section, I changed some iptables commands to ufw commands. You can see the comments ones here:
#firewalladd='iptables -A $chain -p tcp -s $ip --dport 22 -j DROP'
#firewalladd='iptables -A $chain -p tcp -s $ip --dport 22 -j DROP'
firewalladd='ufw insert 1 reject proto tcp from $ip to any port 22'
# Delete a block rule:
firewalldel='ufw delete reject proto tcp from $ip to any port 22'
#firewalldel='iptables -D $chain -p tcp -s $ip --dport 22 -j DROP'
That’s about it! With that, my machine started to grow a big list of IP addresses to block from failed logins.
I ran into issues with Bind 9 on Ubuntu 16 very recently. I use an internal caching DNS server for a few reasons – try to protect myself from malware, log DNS requests on my network to have an idea of where all hosts are going – mainly searching for malware or bad websites, block some domains i.e. ad blocking and some others that I might not want to visit, even by accident, etc. Suddenly at some point, I could no longer resolve any addresses that were not in my zones. My forwarders were no longer working, etc. It turned out to be:
dnssec-validation auto;
This line is default in Ubuntu 16’s Bind 9. Why it worked before, I don’t know. I changed it to
dnssec-validation no;
Then everything magically started working again. Hope this saves someone else’s time. 🙂
While we continue to see the WannaCry and other malware around, I thought I would secure my own network. Since I allow visitors onto their networks, I figured I would configure all new DHCP’d hosts to access the Internet only via HTTP and HTTPs and not allow them to use any DNS servers other than OpenDNS. Here’s how to do it:
The first thing I did was create an access restriction. I did this just to see what chain would be created and I would put subsequent rules into that chain.
The previous screenshot created this chain:
Chain rdev07 (1 references)
target prot opt source destination
DROP all -- 192.168.0.15 anywhere
With this chain, I can add additional rules. The first thing I want to do is allow only DNS access to OpenDNS servers and none other. For this, I would run the following commands:
These rules basically allow DNS queries from my network to the 2 OpenDNS servers. The last 2 rules mean that no other DNS servers outside of those 2 servers can be queried. The reason I do this is because there is some malware out there that will change the DNS servers to query on Windows, effectively overriding the DHCP setting. An alternative to this would be to configure Tomato to intercept DNS requests, but I would rather do it this way.
I added the following rules because I had noticed for some reason that some connections coming back from OpenDNS were dropped. I think they’re optional, but I put them in.
Next, I go to create my whitelist – this would be my iPhone, iPad, android, etc – any hosts that I trust. I’m going to allow these host to go out to any host with TCP and UDP.
I know that they can still get viruses. I hope they don’t. They can only use OpenDNS for DNS services, but they can access basically anything outside on any port.
Lastly, I configure the rules to allow only HTTP and HTTPs out.
iptables -A rdev07 -4 -p tcp -s 192.168.0.0/24 -d 0.0.0.0/0 --dport 80 -j ACCEPT
iptables -A rdev07 -4 -p tcp -s 192.168.0.0/24 -d 0.0.0.0/0 --dport 443 -j ACCEPT
iptables -A rdev07 -4 -p all -s 192.168.0.0/24 -d 0.0.0.0/0 -j DROP
With this, anyone else on the network can connect to port 80 and 443 of any host on the Internet. Then, any traffic going out to any other port is dropped.
After testing all commands and seeing that they worked for me, I put them all into Administration/Scripts/Firewall.
Have fun and be safe! Please post any comments below.
Twitter CLI is a wonderful tool for automatically sending tweets. Very simply, after installation, you just need to run ‘t update “message”‘ and it would tweet your message. I wanted to do some tweeting randomly via cron, but since cron runs regularly at an interval, it’s not very random. Just adding a couple of lines to the script will make it random.
Here’s how to do it.
First, download and install Twitter CLI from here: https://github.com/sferik/t
Afterwards, make a copy of the t script and call it what you want. I call it randomt:
cp /usr/local/bin/t /usr/local/bin/randomt
Finally, just make a change to the script. Here, I’m setting a variable called time and making it a random number between 1 and 1000. From there, I’m multiplying it by 60 to convert it to minutes.
#!/usr/bin/ruby2.0
#
# This file was generated by RubyGems.
#
# The application 't' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = ">= 0"
time = 1 + rand(1000) * 60sleep(time)
if ARGV.first
str = ARGV.first
str = str.dup.force_encoding("BINARY") if str.respond_to? :force_encoding
if str =~ /\A_(.*)_\z/
version = $1
ARGV.shift
end
end
gem 't', version
load Gem.bin_path('t', 't', version)
Now, my tweets go out at some random time between 1 and 1000 minutes later. Thanks for reading!
