What are the general things/setup that you do after getting a VPS/Dedicated server?

evnix

The obvious one is to change the SSH port.

Would be interesting to hear what are the other things that you do?

yoursunny

I never change SSH port, but I disable password authentication. Virmach support complains about this every time.

If the server is for idling, the best command to ensure security is:

sudo shutdown -h now

ionswitch_stan

Apply all updates (yum update, apt-get update, etc).

Enable SSH based key auth. Disable root logins. Consider hardening SSH via the Mozilla recommendations (https://infosec.mozilla.org/guidelines/openssh.html) turning off old insecure ciphers and such. As a warning this can cause some trouble if you have systems that don't support secure ciphers (ie, centos 6 sshing to centos 7). Consider changing the SSH port, but understand it is primarily to reduce log noise not really adding security.

Remove any unneeded services.

Enable syslog to publish logs remotely to either another server you own, or a free syslog aggrogator service. This way if you get compromised the compromisor can't delete logs.

Install monit if you have nothing better.

Firewall off all ports you aren't using.

Enable automatic installation of security patches.

Mustafamw3

Install control panel

tester4

Install CSF/LFD and change SSH port, that's about it.

ouvoun

I have a super scrappy script that I use to bootstrap Debian-based servers. Definitely a personal script, but it might help you out?

#!/bin/bash

# Editable variables
V_USER='xx'
V_SSH_PORT='xxxxx'

# Update user settings
echo '**** Updating root password'
passwd

echo '**** Creating user: '"$V_USER"
read -p "Press enter to continue"
adduser $V_USER
usermod -aG sudo $V_USER
#su - $V_USER

# Update SSH settings
echo '**** Updating SSH port to '"$V_SSH_PORT"
read -p "Press enter to continue"
sed -i '/PermitRootLogin yes/c\PermitRootLogin no' /etc/ssh/sshd_config
sed -i '/Port 22/c\Port '"$V_SSH_PORT" /etc/ssh/sshd_config

# Install basic packages
echo '**** Installing packages'
read -p "Press enter to continue"
apt -y update
apt -y upgrade
apt -y install sudo ufw fail2ban htop curl python-pip

# Set up firewall
echo '**** Setting up firewall'
read -p "Press enter to continue"
ufw allow http
ufw allow https
ufw allow ssh
ufw allow $V_SSH_PORT
ufw enable

# Other settings
echo '**** Tweaking settings'
read -p "Press enter to continue"
timedatectl set-timezone America/Los_Angeles

# Install Docker
echo '**** Installing docker'
read -p "Press enter to continue"
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh
usermod -aG docker $V_USER

# Install Docker Compose
echo '**** Installing docker-compose'
read -p "Press enter to continue"
pip install docker-compose

echo '**** Completed. Rebooting in 5...'
sleep 5
reboot

evnix

@ouvoun said:
I have a super scrappy script that I use to bootstrap Debian-based servers. Definitely a personal script, but it might help you out?

#!/bin/bash

# Setup Variables
V_USER='xx'
V_SSH_PORT='xxxxx'

# Update user settings
echo '**** Updating root password'
passwd

echo '**** Creating user: '"$V_USER"
read -p "Press enter to continue"
adduser $V_USER
usermod -aG sudo $V_USER
#su - $V_USER

# Update SSH settings
echo '**** Updating SSH port to '"$V_SSH_PORT"
read -p "Press enter to continue"
sed -i '/PermitRootLogin yes/c\PermitRootLogin no' /etc/ssh/sshd_config
sed -i '/Port 22/c\Port '"$V_SSH_PORT" /etc/ssh/sshd_config

# Install basic packages
echo '**** Installing packages'
read -p "Press enter to continue"
apt -y update
#apt -y upgrade
apt -y install sudo ufw fail2ban htop curl python-pip

# Set up firewall
echo '**** Setting up firewall'
read -p "Press enter to continue"
ufw allow http
ufw allow https
ufw allow $V_SSH_PORT

# Other settings
echo '**** Tweaking settings'
read -p "Press enter to continue"
timedatectl set-timezone America/Los_Angeles

# Install Docker
echo '**** Installing docker'
read -p "Press enter to continue"
# apt -y install apt-transport-https ca-certificates curl gnupg2 software-properties-common python-backports.ssl-match-hostname
# curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
# apt update
# apt install -y docker-ce
# pip install docker-compose
# usermod -aG docker $V_USER
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh
usermod -aG docker $V_USER

# Install Docker
echo '**** Installing docker-compose'
read -p "Press enter to continue"
pip install docker-compose

echo '**** Completed. Rebooting in 5...'
sleep 5
reboot

This is amazing!! Exactly what everyone should be doing.
I hereby save it as ouvoun.sh
I might remove the docker part as I don't use docker for most of my projects.

Though would be interested to know how we could automate ssh keys here
Also, another important thing might be to configure/automate to somehow increase the ulimit. The default ulimits are always too small and often either slow down or crash most server software.

havoc

Basically as per @ouvoun except

Python3 not 2

I'd actually run the apt upgrade. Not sure why it's commented out

The firewall config section is broken. It's setting up the rules but never actually enabling the firewall. Add a ufw enable

And you'll also need a ufw allow 22 else it'll cut off your ssh session the second you enable it given that rule provides for custom port only.

ouvoun

@evnix said:
I might remove the docker part as I don't use docker for most of my projects.

Totally fair. Once I discovered Docker I was addicted to being able to set up my existing stack within a couple of minutes. I’d never go back now.

Though would be interested to know how we could automate ssh keys here

Yeah I’d like that too. Frankly I’m too lazy to use ssh keys, but I know I should.

ouvoun

@havoc said:
Basically as per @ouvoun except

Python3 not 2

I'd actually run the apt upgrade. Not sure why it's commented out

The firewall config section is broken. It's setting up the rules but never actually enabling the firewall. Add a ufw enable

And you'll also need a ufw allow 22 else it'll cut off your ssh session the second you enable it given that rule provides for custom port only.

Yeah, good catch on the firewall. I usually add a few more rules afterwards and then enable. I’ll edit the OP, thanks for the feedback!

seriesn

@ouvoun said:

@evnix said:
I might remove the docker part as I don't use docker for most of my projects.

Totally fair. Once I discovered Docker I was addicted to being able to set up my existing stack within a couple of minutes. I’d never go back now.

Though would be interested to know how we could automate ssh keys here

Yeah I’d like that too. Frankly I’m too lazy to use ssh keys, but I know I should.

Knowing how there’s so many idling VPs y’all keep, I would just whitelist 2/3 vms IP and lock down access to my servers

ouvoun

@seriesn said:
Knowing how there’s so many idling VPs y’all keep, I would just whitelist 2/3 vms IP and lock down access to my servers

Hey I’ve only got two idlers, and that’s one more than I usually have.

havoc

Anybody doing anything fancy with specific IPs? I've been toying with the idea of doing a dynamic dns type thing which tweaks firewall rules on the fly

Or alternatively blocking all countries except mine. I know iptables can do this via bulk rule import but havennt seen a clean way

havoc

@ionswitch_stan said: not really adding security.

I get what you're saying but don't agree 100%. Cutting down bot attempts from 100s to near zero has to have some security benefit

ionswitch_stan

@havoc said:
I get what you're saying but don't agree 100%. Cutting down bot attempts from 100s to near zero has to have some security benefit

This is classically known as security through obscurity. Changing the SSH port is obscuring it. If your SSHd/settings/users are secure, port 22 or 222 becomes simply a logging exercise. If your SSHd/settings/users are not secure, it becomes a hope that no one is scanning obscure ports, doing banner detection, and then brute forcing.

At the end of the day, SSH really shouldn't be exposed on a server to the public internet. In Amazon land (AWS) we Systems Manager that allows out-of-band access to VM's without SSH. In private datacenters you need (generally) a VPN. The majority of providers (myself included) do not offer an easy way to not expose SSH, but allow easy access when you need it.

To really go deeper, we would need a beer... It's a debatable gray area.

Anybody doing anything fancy with specific IPs? I've been toying with the idea of doing a dynamic dns type thing which tweaks firewall rules on the fly

Then I saw this -- which is exactly what I was suggesting.

./allow-access.sh instance
ssh instance
./remove-access.sh instance

Where allow and remove access would hit the providers API to open a network firewall to your instance.

evnix

@ionswitch_stan said: ./allow-access.sh instance
ssh instance
./remove-access.sh instance

This is neat, though I wouldn't be able to do this with multiple providers and I am not sure if all providers have such APIs.

Personally, I would probably use some kind of VPN server, but then again you would need another fallback VPN server if you loose access to the primary VPN server, you might end up locking yourself out.

ionswitch_stan

@evnix said: This is neat, though I wouldn't be able to do this with multiple providers and I am not sure if all providers have such APIs.

Personally, I would probably use some kind of VPN server, but then again you would need another fallback VPN server if you loose access to the primary VPN server, you might end up locking yourself out.

Unfortunately you are right... A next-best-thing is likely whitelisting a host or two as a jump-box that you keep updated and secured.

jvnadr

1. Update
2. Upgrade
3. Install necessary staff like sudo, wget, screen, fail2ban, unzip, git, curl etc.
4. Creating new user with sudo privileges
5. creating a SSH key
6. Disabling root login via password
7. Testing the configuration before exiting
8. Usually, install proxmox on top and NAT environment with bridged network
9. Disabling unnecessary ports
10. Changing root password
11. Then, idling

havoc

@ionswitch_stan said: This is classically known as security through obscurity

No its not.

Youre not relying on obscurity for safety. You're running the exact same security as normal. But moving it to a non 22 port.

Its a additional step on top of normal security measures that happens to cut login attempts dramatically. That's not security through obscurity. It's a big win basically for free

Given a choice do you want to be on a port that:
A) gets hammered 247 with login attempts
B.)does not

Forget the high level arguments. That's just common sense

jvnadr

@tester4 said: Install CSF/LFD and change SSH port, that's about it.

@ouvoun said: I have a super scrappy script that I use to bootstrap Debian-based servers. Definitely a personal script, but it might help you out?

Really, it is not necessary and won't give any extra to security the change of the ssh port. If you are so paranoid, this is a good article (even if it's old) and suggests another approach to keep attackers blind as of port 22: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

skorous

@havoc said: Youre not relying on obscurity for safety.

It's a pretty simple argument, what security does moving the port provide other than obscurity? None. Therefore the only thing it provides is security through obscurity.

ouvoun

@jvnadr said:
Really, it is not necessary and won't give any extra to security the change of the ssh port. If you are so paranoid, this is a good article (even if it's old) and suggests another approach to keep attackers blind as of port 22: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

My opinion on this:
1) All of the tools I use on my boxes support ports other than the default
2) It’s super easy to change
3) A non-default port won’t get slapped as hard

So for me, it’s a no brainer. Might not be that more secure, but I don’t see why it hurts at all.

Of course I understand there are setups where a non-default SSH port complicates things. That’s not the case for me and (I assume) quite a few others on this forum.

evnix

Here is an updated version of the script from @ouvoun and some enhancements(untested) by @HostDoc to support/deploy SSH keys and hostname.
Don't forget to replace the XX

#!/bin/bash

# Editable variables
V_USER='xx'
V_SSH_PORT='xxxxx'
V_KEY='ssh-rsa xxxxxxxxxxxxxx'
V_HOSTNAME='xxxxx'

# Update user settings
echo '**** Updating root password'
passwd

echo '**** Creating user: '"$V_USER"
read -p "Press enter to continue"
adduser $V_USER
usermod -aG sudo $V_USER
#su - $V_USER

# Update SSH settings
echo '**** Updating SSH port to '"$V_SSH_PORT"
read -p "Press enter to continue"
sed -i '/PermitRootLogin yes/c\PermitRootLogin no' /etc/ssh/sshd_config
sed -i '/Port 22/c\Port '"$V_SSH_PORT" /etc/ssh/sshd_config
sed -i '/PasswordAuthentication yes/c\PasswordAuthentication no' /etc/ssh/sshd_config
echo '****Adding SSH Key'
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
echo "$V_KEY" | dd of=.ssh/authorized_keys status=none
chmod 600 .ssh/authorized_keys

# Install basic packages
echo '**** Installing packages'
read -p "Press enter to continue"
apt -y update
apt -y upgrade
apt -y install sudo ufw fail2ban iotop htop curl python-pip

# Set up firewall
echo '**** Setting up firewall'
read -p "Press enter to continue"
ufw allow http
ufw allow https
ufw allow ssh
ufw allow $V_SSH_PORT
ufw enable

# Other settings
echo '**** Tweaking settings'
read -p "Press enter to continue"
timedatectl set-timezone America/Los_Angeles
hostnamectl set-hostname $V_HOSTNAME
echo xxxxx >/proc/sys/kernel/msgmax
sysctl vm.swappiness=xx

# Install Docker
echo '**** Installing docker'
read -p "Press enter to continue"
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh
usermod -aG docker $V_USER

# Install Docker Compose
echo '**** Installing docker-compose'
read -p "Press enter to continue"
pip install docker-compose

echo '**** Completed. Rebooting in 5...'
sleep 5
reboot

Neoon

Well, for me, it looks like, that script installs bloat, which makes the vps more insecure, instead of what it should do when you run it first, is making the vps more secure.

You may also try:

• Disable password auth + deploying your ssh keys
• Shutoff the SSH port via Firewall

ouvoun

@Neoon said:
Well, for me, it looks like, that script installs bloat, which makes the vps more insecure, instead of what it should do when you run it first, is making the vps more secure.

You may also try:

• Disable password auth + deploying your ssh keys
• Shutoff the SSH port via Firewall

The original poster asked for opinions on what people do on a new server. I assume by “bloat” you mean Docker. And that’s fair. But I depend on Docker; that’s why it’s included.

Of course if you want a secure box, disable login and shut it down forever.

teamacc

@skorous said:

@havoc said: Youre not relying on obscurity for safety.

It's a pretty simple argument, what security does moving the port provide other than obscurity? None. Therefore the only thing it provides is security through obscurity.

I like to think NOT getting hit with brute-force attempts lightens the load on the server, by not having to deal with that pesky aspect.

skorous

@teamacc said: I like to think NOT getting hit with brute-force attempts lightens the load on the server, by not having to deal with that pesky aspect.

Heh heh heh ... that I won't argue with but that's not really a security gain unless you're arguing it makes auditing the logs easier. I prefer iptables rate-limiting for that.

FAT32

I am low key afraid of limiting access of SSH for certain IP only because I keep thinking what if suddenly all my whitelisted IP are no longer usable? Given that no VNC, KVM or IPMI is available, that will cause more trouble and it compromised availability.

isunbejo

Change ssh port and set up IP allow SSH tcp wrapper on /etc/hosts.allow then /etc/hosts.deny for ssh deny all

sonic

Change SSH port, add new sudo user, disallow root, let idle till expired.

DP

@isunbejo said:
Change ssh port and set up IP allow SSH tcp wrapper on /etc/hosts.allow then /etc/hosts.deny for ssh deny all

I do this too.

On top of that, iptables ACCEPT/DROP

isunbejo

@thedp said:

@isunbejo said:
Change ssh port and set up IP allow SSH tcp wrapper on /etc/hosts.allow then /etc/hosts.deny for ssh deny all

I do this too.

On top of that, iptables ACCEPT/DROP

I do not need statefull connection tracking firewall (performance reasons)

If you use iptbales, just add a custom iptables rule in RAW table and mark everything as non tracking.

terrorgen

Install zerotier, add new vps to my zerotier network, close all firewall ports except from zerotier.

Daniel

I do something similar to @ouvoun's script, except via Ansible. Just have to manually configure SSH keys and install Python3 and then Ansible handles the rest. The Debian installer already asks to create a new user, so I guess that part of your script wouldn't be necessary if you install from ISO.

Maybe I should post my Ansible playbooks somewhere.

debaser

@skorous said:

@teamacc said: I like to think NOT getting hit with brute-force attempts lightens the load on the server, by not having to deal with that pesky aspect.

Heh heh heh ... that I won't argue with but that's not really a security gain unless you're arguing it makes auditing the logs easier. I prefer iptables rate-limiting for that.

My 2 cents: If you secure your server correctly, you won't have to be afraid for those brute-force attempts. By changing the port you're merely obscuring that there is an SSH daemon running on your box. So it really is security by obscurity.

I don't change the default SSH-port because I work behind firewalls dat won't let me make an SSH-connection to a non-privileged port. I also think this is generally not a good idea.

I disable ssh root login after employing a new VM or dedi, adding a user with sudo-rights and only allowing access with keys. I setup Fail2Ban and iptables rate-limiting. Just to be sure I limit access to port 22 from a number of subnets that are well known for brute-forcing SSH (Online.net, China Telecom). That last part is security by obscurity as well of course...

On some boxes I don't want this hassle and I just limit access to SSH from my home ip-address, my work ip-address, the CGNAT subnets from my mobile provider and my other boxes.

No server I managed has ever been compromised, nor am I experiencing high load from those SSH bruteforcers.

evnix

@terrorgen said: Install zerotier, add new vps to my zerotier network, close all firewall ports except from zerotier.

I am curious, is this different from an OpenVPN jump box setup?

terrorgen

@evnix said:

@terrorgen said: Install zerotier, add new vps to my zerotier network, close all firewall ports except from zerotier.

I am curious, is this different from an OpenVPN jump box setup?

They might be similar. But zerotier is way easier to configure than openvpn though.

jvnadr

@FAT32 said: I am low key afraid of limiting access of SSH for certain IP only because I keep thinking what if suddenly all my whitelisted IP are no longer usable? Given that no VNC, KVM or IPMI is available, that will cause more trouble and it compromised availability.

That's why IMO is crucial to have a sudo user with complex username/pasword combilation that can be used in those cases.

mfs

I usually perform a set of action required to score 80+ on lynis. While the score, per se, is mostly pointless, some of the suggestions aren't pointless to me. These involve:

• automating install of security updates on a pre-defined day of the week (usually on Sunday), followed by a restart of the involved processes. I usually always prefer to perform updates manually, so the cron job isn't required. Yet, if I'm hit by a bus, my idling boxes will take care of themselves
• remove compilers if present and not needed
• disable not needed drivers (firewire, usb-storage, et al.)
• harden sysctl key pairs (the list is long)
• install at least a tool to record and collect system activities
• change banners with a German one to scary out skids
• properly configure hostname and hosts file

And more:

• check how much of a glory hole I've just bought
• configure postfix to send me warnings
• entirely disable the root account (I usually just keep a sudoer/%wheel user for administrative tasks)
• deploy hardened ip{,6}tables and ipsets services

I dare to harden OpenSSH too. Changing port is convenient even if it doesn't harden, a flooded log is a potentially unhelpful log (even more w/o fail2ban). I have no mandatory requirements about picking port 22 and leaving it wide open. I pick another privileged port and on top of it I restrict it to a handful of static IPs (Wireguard VPNs + office), I have no reasons to leave it open to the wide internet. If all my VPNs and my workplace gets nuked from orbit (or, more likely, if there's some exceedingly unexpected OpenSSH configuration error) there's an emergency rate-limited and filtered dropbear instance listening on an IPv6-only privileged port. Range scans are invariably caught with an ip{,6}tables "recent" module, the most obnoxious and notorious offenders are dealt with ipsets, using (highly conservative) blocklists too.

Then, I power it off.

poisson

I normally do this as well:

Neoon

@FAT32 said:
I am low key afraid of limiting access of SSH for certain IP only because I keep thinking what if suddenly all my whitelisted IP are no longer usable? Given that no VNC, KVM or IPMI is available, that will cause more trouble and it compromised availability.

Well, you limit it, to multiple gateways, not just one.

yoursunny

I have no firewall, no SSH port change, no fail2ban. I just disabled password login. Why am I not hacked?
Or, am I already hacked but I don't know?

beagle

That script is just missing a few steps to cover all I need:

1. create a new user (add to wheel/sudo group)
2. set ssh keys for that user
3. change ssh port
4. disable root login on ssh
5. disable password auth on ssh
6. close all unused ports on firewall
7. set fail2ban to ban unauthorised login attempts
8. install hetrixtools and set alerts to monitor the server

I may add some additional jails on fail2ban depending on what services are running on the server.

elliotc

Bench script

terrorgen

@poisson said:
I normally do this as well:

Probably tie a yellow wrist ribbon somewhere?

vimalware

@yoursunny said:
I have no firewall, no SSH port change, no fail2ban. I just disabled password login. Why am I not hacked?
Or, am I already hacked but I don't know?

You're fine mate, as long as you're only idling the ssh daemon on a public port, and no other.

Most of my boxen are double duty and rsync over default ssh port is too important to give up. I use 3 trylimit fail2ban and a multiday bantime in order to keep my logs legible.

yoursunny

@vimalware said:

@yoursunny said:
I have no firewall, no SSH port change, no fail2ban. I just disabled password login. Why am I not hacked?
Or, am I already hacked but I don't know?

You're fine mate, as long as you're only idling the ssh daemon on a public port, and no other.

I also have nginx on 80 and 443.
I moved Asterisk to 15060. Someone keeps trying different SIP passwords, wanting to make long distance calls. My passwords are randomly generated so they can't succeed, and I only have $1 long distance credit. I changed port because Asterisk log file fills the disk every 3 days and then the server crashes.

Most of my boxen are double duty and rsync over default ssh port is too important to give up. I use 3 trylimit fail2ban and a multiday bantime in order to keep my logs legible.

I have virtual machines (VirtualBox in university servers, not VPS) on alternate ports. I use $HOME/.ssh/config to set the ports. rsync and everything else work fine.

uptime

@mfs said:

• change banners with a German one to scary out skids

I see what you did there ...

ACHTUNG!
ALLES TURISTEN UND NONTEKNISCHEN LOOKENSPEEPERS!
DAS KOMPUTERMASCHINE IST NICHT FÜR DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN.
IST NICHT FÜR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS POCKETS MUSS.
ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.

FlamingSpaceJunk

@evnix said:

@terrorgen said: Install zerotier, add new vps to my zerotier network, close all firewall ports except from zerotier.

I am curious, is this different from an OpenVPN jump box setup?

Zerotier is a mesh VPN, so it's more like a private P2P network. Traffic doesn't have to go through a central server. It's also a hosted service, so you don't have to keep your own box working.

Tinc and Wireguard are similar.

I keep meaning to get a wireguard network setup, and see if I can get rid of the IPSec/OpenVPN monstrosity at work.

terrorgen

@uptime said:

@mfs said:

• change banners with a German one to scary out skids

I see what you did there ...

ACHTUNG!
ALLES TURISTEN UND NONTEKNISCHEN LOOKENSPEEPERS!
DAS KOMPUTERMASCHINE IST NICHT FÜR DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN.
IST NICHT FÜR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS POCKETS MUSS.
ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.

Is this real German or fake German?

uptime

@terrorgen said:

@uptime said:

@mfs said:

• change banners with a German one to scary out skids

I see what you did there ...

ACHTUNG!
ALLES TURISTEN UND NONTEKNISCHEN LOOKENSPEEPERS!
DAS KOMPUTERMASCHINE IST NICHT FÜR DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN.
IST NICHT FÜR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS POCKETS MUSS.
ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.

Is this real German or fake German?

hörbar lachen

sicher, das ist kein Hochdeutsch!