DEV Community: Martin Riedel

switching from gnu-screen to tmux

Martin Riedel — Tue, 17 Sep 2019 14:36:49 +0000

After using linux (or any sort of unix-like operating system) for a few years, most users get pretty comfortable on the command line - and from time to time open several terminal windows/sessions just to avoid having to stare on the output of another long running process. If you find yourself in this position more often, you'll find yourself searching for a thing called terminal multiplexers. This is a tool that enables you to switch between multiple terminal-panes inside of your shell-session. Awesome, right? They also might offer you features like tiling vertical or horizontal, if you need to see several things at once.

A few years back, I started using gnu-screen as my multiplexer. Recently I got a bit annoyed with it though. One thing that bothered me from the beginning was, that the name screen makes it pretty hard to find relevant information via online search engines. So it was almost always way more tedious to find the information i wanted as i would expect it... Something I also disliked more and more was, that I always had to open the same few panes after a while. I usually have very similar workloads and got used to having panes labeled as nmap, gobust or revshell (for example).
And then I discovered tmux-continuum while reading this post on stackoverflow - yes. tmux. Not screen - and the urge to finally ditch gnu-screen got strong enough. After reading several guides to switching, I decided that the work involved is not too much and that I would manage to do that within lunch break. And I went for it.

See the .tmux.conf I currently use below:

# set prefix to ctrl+a
unbind C-b
set -g prefix C-a

# toggling windows with ctrl+a ctrl+a
bind-key C-a last-window

# jump to the beginning of the line
bind a send-prefix

# don't rename windows automatically
set-option -g allow-rename off

# start with window number 1
set -g base-index 1

# Notifying if other windows has activities
setw -g monitor-activity on

# split panes using | and -
bind | split-window -h
bind - split-window -v
unbind '"'
unbind %

# vim copy mode
bind P paste-buffer
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi y send-keys -X copy-selection
bind-key -T copy-mode-vi r send-keys -X rectangle-toggle
bind -t vi-copy y copy-pipe "xclip -sel clip -i"

# statusbar
set -g status-position bottom
set -g status-justify left

# List of plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @plugin 'tmux-plugins/tmux-yank'

# tmux-continuum
set -g @continuum-restore 'on'

# Initialize TMUX plugin manager (keep this line at the very bottom of tmux.conf)
run -b '~/.tmux/plugins/tpm/tpm'

This offers me (so far) everything i need. From vim-like copy and pasting (as found in this blog post) to preserving my opened panes, the status-line and the shortcuts that are deeply ingrained in my muscle-memory.

this post has been publish on my blog before.

the infosec mindset

Martin Riedel — Tue, 29 Jan 2019 07:38:01 +0000

this has been published originally on my blog.

after being interested in hacking, malware, intrusion detection, social engineering and all the funny and interesting things that define the infosec field, i decided to drink from the fountain. i took the plunge and decided to invest in it and finally got serious with it. i started learning more, reading more and took part in ctfs.

after solving a few of the easy machines on hackthebox, i started to realize something:

you always learn
you’re forever a noob
sharing is caring. i got so much help and support that it would feel weird not to “give back” in some way
security is a mindset

the thing is the most important, and i’d like to elaborate a bit more on that. why should security be a mindset? isn’t it something that is easily solved with technology? in the end, it’s the technology that gets exploited, aye?

well, yes and no. there are lots of exploit out there that use weaknesses in the code. but yet, one of the most important - if not the most important attack vector is the human sitting in front of the keyboard. ask every experienced social engineer (or most children) - humans want to help and they want to make your life easier. so being aware of the human nature is one part of a security-aware mind. being aware, that someone might want to exploit you. not the computer in front of you, not the smartphone on your table. you are the target. because sometimes it’s just easier asking for a password than exploiting a vulnerability.

another part of the security mindset affects the developer. the developer (as a persona) is very target-oriented. they want to get stuff done, implement yet another feature and are very methodical. tests get written, documentation gets writte - and before that user stories are breaken down into tasks and the necessary information gets extracted. all of this is part of the process, that defines the image, that the programmer has in their mind. an image, that is filled with what needs to work - and sometimes with the how. maybe they also have some test cases in mind. this can be pretty dangerous, because the developers might focus only on the expected behaviour, expected input etc. but what with all the edge cases? speaking from personal experience, this happens quite a lot. the owasp top-10 do not by accident contain lots of easily mitigated stuff. dealing with sql injections is really not a technical problem in 2019…

but even with security-conscious developers, this is not yet solved. the best team of security-aware developers can be mislead by or severly limited in their abilities by a product owner (or whoever creates the user-stories/specification) that focusses on features and on features alone. especially when time or budget is short (and it kinda always is), then security can easily be ignored (“if we don’t look, everything is secure, right?”) or be seen as a competitive disadvantage. creating a secure product is hard and expensive. at least more expensive than just ignoring security completely. as long as the customers don’t take their money somewhere else to punish organisations that obviously don’t care about their security, nothing will change in that regard.

and with customers in mind, we reached the next group where a security mindset could pay off: the paying customers. if scandals, breaches and gaping security holes are not enough to turn your back on some companies and products - well, why should anything change? if we do not vote with our money, nothing will change and everbodies data will be public in the end.

to sum it up

tl;dr
security is a mindset. developers, product-owners and customers can profit from developing an eye for security in the products they use - or we will be faced with more and more breaches.

to create secure software, everyone involved in the process can benefit from being aware of security not as a cost factor, but as a matter of quality.

My favourite aliases

Martin Riedel — Mon, 12 Nov 2018 11:01:54 +0000

Inspired by Daniels Blogpost, I had a look in my alias.zsh file, that i use to keep all aliases in one place.

alias for all the aliases

alias aliases="cat ~/.dotfiles/zsh/.zsh/aliases.zsh"

Not sure if you have an alias? Can't remember the specific alias you're looking for? Just aliases and you'll get the list.

git

For my git workflow, i'm relying heavily on aliases to reduce the typing necessary:

alias gc="git commit"
alias gs="git status"
alias gd="git diff"
alias gf="git fetch"
alias gm="git merge"
alias gma="git merge --abort"
alias gr="git rebase"
alias gp="git push"
alias gpf="git push --force-with-lease"
alias gu="git unstage"
alias gg="git graph"
alias gl="git log --pretty --oneline --graph"
alias gA="git add -A"
alias gri="git rebase -i"
alias grc="git rebase --continue"
alias gra="git rebase --abort"

sbt

Currently I'm working with scala and sbt most of the time, and due to that circumstance, I've added several aliases for that.

alias sfmt="sbt scalafmt test:scalafmt sbt:scalafmt"
alias sdt="sbt clean dependencyTree"
alias sdc="sbt clean dependencyCheck"
alias sdu="sbt clean dependencyUpdates"
alias ssg="sbt clean scapegoat"
alias sct="sbt clean test"

weather

Do you know the days, when you barely manage to glimpse the sun? Fear no more - with that alias you're informed about the weather in your <location>!

alias weather="curl http://wttr.in/<location>"

picture credit to kevin ku

My podcast-subscriptions

Martin Riedel — Wed, 29 Aug 2018 11:02:54 +0000

The following post is an overview of podcasts I follow. I'm using Pocket Casts to subscribe and listen. This list is still a work in progress after several years. Also: There is no sort of ranking implied here.

technology

Herr Mies wills wissen GER (Disclaimer: Coworker)
Command Line Heroes
nixers podcast
Autoweird.fm GER (Disclaimer: Coworker)
CaSE podcast
Coder Radio
Linux Unplugged
INNOQ Podcast GER
Linux Action News
Programming Throwdown
TechSNAP
Unsupervised Learning
uhl, steine, scherben GER (Disclaimer: Former Coworker)

infosec

politics and general news

agile

misc

Ear Hustle
CRE GER

I'd love to hear about the podcasts you enjoy or that you recommend. Feel free to drop me a comment!