security
Security.txt
security.txt is a draft IETF standard for websites (webmasters) to communicate security vulnerability/ research policy. The purpose of the standard is to communicate in a standardized manner. The abstract of the RFC states: When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (“security.txt”) to help organizations describe the process for security researchers to follow in order to report security vulnerabilities. Specification The security.txt file contains seven fields: Acknowledgements: This directive allows you to link to a page where security researchers are recognized for their reports. The link MUST begin with “https://". Canonical: This directive indicates the canonical URI where the security.txt file is located. The link MUST begin with “https://". Contact: This directive allows you to provide an address that researchers SHOULD use for reporting security vulnerabilities. The value MAY be an email address, a phone number and/or a web page with contac information. This directive MUST be present in a security.txt file. The link MUST begin with “https://". Encryption: This directive allows you to point to an encryption key that security researchers SHOULD use for encrypted communication. The link MUST begin with “https://". Hiring: The “Hiring” directive is used for linking to the vendor’s security-related job positions. Policy: This directive allows you to link to where your security policy and/ or disclosure policy is located. The link MUST begin with “https://". Prefered-Languages: This directive can be used to indicate a set of natural languages that are preferred when submitting security reports. This set MAY list multiple values, separated by commas. Web-based services should place the security.txt file under the /.well-known/ path; e.g. https://example.com/.well-known/security.txt Example(s) https://www.google.com/.well-known/security.txt https://www.facebook.com/.well-known/security.txt https://securitytxt.org/.well-known/security.txt You can find the current RFC draft here
On Bastion Hosts
I was at a meetup the other night and a student mentioned that they were learning about bastion hosts and wanted to learn more. So I thought I would do a deep dive on what they are and why to use them. What Bastion hosts are instances that sit within your public subnet and are typically accessed using SSH or RDP. Once remote connectivity has been established with the bastion host, it then acts as a ‘jump’ server, allowing you to use SSH or RDP to log in to other instances. https://cloudacademy.com/blog/aws-bastion-host-nat-instances-vpc-peering-security/ Why Bastion hosts act as a gateway or ‘jump’ host into a secure network. The servers in the secure network will ONLY accept SSH connections from bastion hosts. This helps limit the number of points where you can SSH into servers from and limit it to a trusted set of hosts. This also significantly helps auditing of SSH connections in the secure network. Bastion hosts typically have more strigent security postures. This includes more regular patching, more detailed logging and auditing. How Bastion setups are rather quiet simple, here are a few simple steps to set one up: Provision a new server(s) that are ONLY dedicated for the purpose of bastion access Install any additional security measures (see the cyberciti reference below for specific recommendations Ensure that all servers in the secure network ONLY accept SSH connections from the bastion server(s) Configure your SSH client to talk to hosts in your private network. Replace the IdentityFile and domain-names to suit your network: $ cat ~/.ssh/config Host *.secure.example.com IdentityFile %d/.ssh/keyname.extension ProxyCommand ssh bastion.corp.example.com -W %h:%p Host bastion.corp.example.com IdentityFile %d/.ssh/keyname.extension Host * PubkeyAuthentication yes References https://www.cyberciti.biz/faq/linux-bastion-host/ https://cloudacademy.com/blog/aws-bastion-host-nat-instances-vpc-peering-security/ https://www.sans.org/reading-room/whitepapers/basics/hardening-bastion-hosts-420 https://blog.scottlowe.org/2017/05/26/bastion-hosts-custom-ssh-configs/
Complete guide to iptables implementation
I’ve been wanting to put this article together for some time, a complete guide to implementing iptables on a Linux Server. Firstly, my assumptions: You have a reasonable grasp of Linux and Iptables You want to use Iptables to secure a Linux server The Basics Iptables has by default three chains for the FILTER table: INPUT OUTPUT FORWARD In this case, we’re going to focus on the INPUT chain (Incoming to firewall. For packets coming to the local server) Implementation Automation I implement these rules using the puppet-iptables module. The module is regularly updated and has a very large feature-set. References: https://gist.github.com/jirutka/3742890 http://www.cyberciti.biz/tips/linux-iptables-10-how-to-block-common-attack.html
