CCARPS 1.0.0-rc1 Changelog

We jumped from 0.9.5 to 0.9.6, which was rolled into the first Release Candidate for CCARPS 1.0. It has been a few weeks since there has been any more review done on it, and it seems that between me migrating the build system1)Actually, I broke it and had to patch it up., I forgot to post our changelog. Not much has changed since our previous one.

  • Updated Damage Level text to flow better near graphic.
  • Updated Damage Level boxes Modifiers to be better spread out.
  • Minor spelling and grammar fixes.

What we need to do now is import the contents into Scribus. Over the last week I have been taking a look at how to make it “publisher ready” so that we can have a good and proper PDF.

   [ + ]

1. Actually, I broke it and had to patch it up.

Web of Love

It is amazing how we live in an age where total strangers across the world can fall in love at the speed of information. It is pretty fantastic to meet people from everywhere even if one cannot afford to travel abroad (though, traveling should still be had, I believe). And even better when there is a beautiful mixture of the two across the spectrum of relations!

Some of my most dear friends are people who I have interacted with over the Web, some of which I have been fortunate enough to have met in the Meatspace. Many have drifted, as they do, into orbiting patterns that are their friend system, with tide-like contact between them and me. Even the ones that have drifted off completely into the aether, I still think fondly of.

When I think about things like this, I can see that not everything is Doom and Gloom like my brain presses with much insistence.

It is also times like this where I need to remember all the beings that are allies in the Battle of the BAD.

Securing Shell Access via SSH

Goal: Mitigate and securing shell access via ssh from:

  • SSH brute force attacks
  • SSH dictionary attacks
  • Buffer overflow attack

This assumes your sshd_config is located at /etc/ssh/sshd_config. In your sshd_config and that you have sudo and nano.

Open sshd_config for editing: sudo nano /etc/ssh/sshd_config

  • Change Port 22 to something unused on your server.
  • Update iptables/ufw/firewall to deny 22 and allow new port.
  • Bind to a single IP address: ListenAddress 1.2.3.4
  • Ensure Protocol 2 is used.
  • Set PermitRootLogin to no
  • Set DenyUsers root

Optionally, you can set a banner ( Banner /path/to/bannertext). This is useful if you want to show a legal disclaimer regarding login attempts:

Now restart the ssh daemon:

  • Debian-based: sudo systemctl restart sshd.service
  • RedHat-based: sudo service sshd restart
  • Arch-based: sudo systemctl restart sshd.service

Disable SSH Password Login

The best way you can secure from login attempts is to use a key pair login. This portion assumes you do not have an ssh public/private key pair. If you do, skip the generation step. Please note that <port> should be the port you chose above.

  • On a local terminal, issue ssh-keygen -t rsa and follow the prompts. Accept the highest key instead of the default 2048.
  • When that is finished, issue ssh-copy-id -i ~/.ssh/id_rsa.pub user@host to send the server your key1)Thank you, Tiger!P, for commenting about this..

Now we can ssh -p <port> user@host into your server. Upon sucess, you can edit your sshd_config and set PasswordAuthentication no and then restart the ssh daemon.

Since the ssh key pair handles authentication, we do not need to have a password login for ssh. Depending on how you set up your ssh key, you may still be prompted for a password. This is the key pair password, not your ssh user.

Please understand that you must back up your local ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub or you will lose access to your server. If you have multiple computers that connect to your server, I suggest you generate keys for each and add them to your ~/.ssh/authorized_keys2 on the server.

   [ + ]

1. Thank you, Tiger!P, for commenting about this.