Hardening Samba

This post details how you can set up your Samba server to be a bit more resilient than the defaults.

The Samba server security page gives information on using the hosts allow/deny directives, interface binding configuration, and keeping up-to-date, so I'm not going to mention those things here.

I am however going to jump into a few other directives.

First of all, there's no good reason to give out the server's version, so my server replies with "Samba".

I mandate SMB2 as the minimum required protocol, and enforce signing. I really recommend you do this and so does Microsoft. Without mandating signing you are leaving yourself open to man-in-the-middle attacks. These settings will work with clients on Windows 7 and newer, and any non-ancient Linux/macOS.

I'm using the "standalone server" server role, so I can disable NetBIOS completely, and without NetBIOS and SMB1 there's no need to listen on anything other than TCP/445.

Here are smb.conf server directives to get you started with those changes:

[global]
        server string = Samba
        disable netbios = Yes
        server min protocol = SMB2
        smb ports = 445
        server signing = required

In addition to the above, you should consider disabling anonymous authentication.

With anonymous authentication enabled (the default), anyone can specify a blank user and password to view shares and other information, and talk to IPC$:

user@client:~$ smbclient -m SMB2 -L server -U ''
Enter 's password:

        Sharename       Type      Comment
        ---------       ----      -------
        share           Disk
        IPC$            IPC       IPC Service (Samba)
Connection to server failed (Error NT_STATUS_CONNECTION_REFUSED)
NetBIOS over TCP disabled -- no workgroup available

To disable this, you can set restrict anonymous in smb.conf:

[global]

        restrict anonymous = 2

Restart Samba:

admin@server:~$ sudo systemctl restart smbd

You'll now be denied if you use blank credentials:

user@client:~$ smbclient -m SMB2 -L server -U ''

Enter 's password:

tree connect failed: NT_STATUS_ACCESS_DENIED

One other thing I'll mention is my tendency to add a "valid users" line to each share, and whitelist just the users/groups requiring permission.

Thanks for reading!

Electric bike build part 6

Continued from Electric bike build part 5.

My electric bike has almost hit 2,400km and only just now has required another re-torque of the motor. I haven't had any other issues other than a bit of rubbing from the 28mm tyres - it's really touch and go with this frame and I've been told the GP4000 tyres are fatter than advertised.

It looks like the rubber has been completely wiped out by motor movement:

A clamp came in handy to hold the motor in place while doing the re-torque:

Thread locker applied again to both rings:

I used the spanner through an old shirt to keep the alloy lock ring looking pretty:

I still think it's an awesome machine and a great way to commute! No regrets!

All I can think of is if I had to do it all over again I'd look at a bike with disc brakes and a bit more clearance for wider tyres so I can run lower pressures, but I'm in no rush to make the change.

Plex hardware accelerated transcoding within LXC

I run Plex Media Server within an LXC container on my NAS. The NAS itself is a QNAP TS-251+ but it is running Debian 9. I have all the functions I use separated into individual LXC containers.

Plex runs quite well considering the low powered Celeron J1900 processor, but it does tend to struggle with HD transcoding. I managed to get GPU assisted transcoding working this evening which appears to help considerably!

Here are the requirements:
https://support.plex.tv/articles/115002178853-using-hardware-accelerated-streaming/

Fortunately the Celeron J1900 supports Intel Quick Sync Video.

First of all I checked the host could see the DRI stuff:

tim@host:~$ journalctl
Jul 16 21:29:30 jupiter kernel: [drm] Initialized i915 1.6.0 20160919 for 0000:00:02.0 on minor 0

tim@host:~$ ls -l /dev/dri
total 0
crw-rw---- 1 root video 226,   0 Jul 16 21:29 card0
crw-rw---- 1 root video 226,  64 Jul 16 21:29 controlD64
crw-rw---- 1 root video 226, 128 Jul 16 21:29 renderD128

I then tried mapping the devices through to the container:

tim@host:~$ sudo vi /var/lib/lxc/plex/config
...
lxc.mount.entry = /dev/dri dev/dri none bind,create=dir 0 0

I restarted the container then installed the relevant driver and the vainfo program within it:

tim@plex:~$ sudo apt-get install i965-va-driver vainfo

Both the Plex user and my user were in the video group yet vainfo was just saying 'Abort' instead of giving any useful info. I did some further digging:

tim@plex:~$ strace vainfo
...
open("/dev/dri/renderD128", O_RDWR)     = -1 EPERM (Operation not permitted)
open("/dev/dri/card0", O_RDWR)          = -1 EPERM (Operation not permitted)
...

The container did not have permissions to talk to those devices.

I did a bit of reading on control groups and device numbers and came up with the following rule to allow the container to use any character device with a major number of 226 (Direct Rendering Infrastructure):

tim@host:~$ sudo vi /var/lib/lxc/plex/config
...
lxc.cgroup.devices.allow = c 226:* rw
lxc.mount.entry = /dev/dri dev/dri none bind,create=dir 0 0

After stopping and starting the container, I could now run vainfo successfully:

tim@plex:~$ vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)

vainfo: Driver version: Intel i965 driver for Intel(R) Bay Trail - 1.7.3

vainfo: Supported profile and entrypoints

      VAProfileMPEG2Simple            : VAEntrypointVLD

      VAProfileMPEG2Simple            : VAEntrypointEncSlice

      VAProfileMPEG2Main              : VAEntrypointVLD

      VAProfileMPEG2Main              : VAEntrypointEncSlice

      VAProfileH264ConstrainedBaseline: VAEntrypointVLD

      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice

      VAProfileH264Main               : VAEntrypointVLD

      VAProfileH264Main               : VAEntrypointEncSlice

      VAProfileH264High               : VAEntrypointVLD

      VAProfileH264High               : VAEntrypointEncSlice

      VAProfileH264StereoHigh         : VAEntrypointVLD

      VAProfileVC1Simple              : VAEntrypointVLD

      VAProfileVC1Main                : VAEntrypointVLD

      VAProfileVC1Advanced            : VAEntrypointVLD

      VAProfileNone                   : VAEntrypointVideoProc

      VAProfileJPEGBaseline           : VAEntrypointVLD

Jenkins on Kali 2017.1

Here's a quick run through of getting the Jenkins Pipeline demos working on Kali 2017.1 for testing purposes.

Install Docker

Add the Docker package certificate:
tim@kali:~$ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -

If we try to use add-apt-respository we will get an error as Kali is not supported:
tim@kali:~$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian stretch stable"
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Kali/kali-rolling

We can instead manually add to /etc/apt/sources.list:
tim@kali:~$ sudo vi /etc/apt/sources.list
deb [arch=amd64] https://download.docker.com/linux/debian stretch stable
tim@kali:~$ sudo apt-get update
tim@kali:~$ sudo apt-get install docker-ce

Create users for services

We will be using key authentication or sudo so no need for passwords on the service accounts:
tim@kali:~$ sudo adduser --disabled-password git
tim@kali:~$ sudo adduser --disabled-password jenkins

We want Jenkins to be able to utilise Docker without having to be root:
tim@kali:~$ sudo adduser jenkins docker

Download and run Jenkins

When testing I prefer this method over the Debian package as it is all self-contained:
tim@kali:~$ sudo -u jenkins -i
jenkins@kali:~$ mkdir ~/jenkins && cd ~/jenkins
jenkins@kali:~/jenkins$ wget "http://mirrors.jenkins.io/war-stable/latest/jenkins.war"
jenkins@kali:~/jenkins$ java -jar jenkins.war --httpPort=8080

Set up Git remote

This will set up a repo you can access over SSH:
tim@kali:~$ sudo apt-get install git-core
tim@kali:~$ sudo systemctl start ssh
tim@kali:~$ sudo -u git -i
git@kali:~$ mkdir ~/.ssh ~/repo
git@kali:~$ chmod 0700 ~/.ssh
git@kali:~$ cd ~/repo
git@kali:~/repo$ git init --bare

Set up SSH keys

Create keys for your user and the Jenkins user and add to Git's authorized_keys file:
tim@kali:~$ sudo ssh-keygen
tim@kali:~$ sudo -u jenkins ssh-keygen
tim@kali:~$ cat ~/.ssh/id_rsa.pub | sudo -u git tee -a /home/git/.ssh/authorized_keys
tim@kali:~$ sudo -u jenkins cat /home/jenkins/.ssh/id_rsa.pub | sudo -u git tee -a /home/git/.ssh/authorized_keys

Set up local Git repo

Push your test Jenkinsfile to the remote repo:
tim@kali:~$ mkdir repo && cd repo
tim@kali:~/repo$ git init
tim@kali:~/repo$ vi Jenkinsfile
tim@kali:~/repo$ git add .
tim@kali:~/repo$ git commit
tim@kali:~/repo$ git remote add origin git@localhost:repo
tim@kali:~/repo$ git push --set-upstream origin master

You should now be able to successfully run the Pipeline demos here:
https://jenkins.io/doc/pipeline/tour/hello-world/

You can set the Git server in Jenkins as git@localhost:repo and it will work the same as a remote Git server (BitBucket etc).

As this is for testing purposes, if you reboot you'll have to start SSH and Jenkins again manually.