Let’s consider a scenario in which you are deploying your infrastructure using a Terraform code (infrastructure-as-code) which is stored in a remote git repository. Now working in an organization you need to make sure that all your deployments are always tracked without an exception, an add-on to that whether your Terraform code is following your security and compliance policies or not. Or maybe what is the monthly cost that you can expect with that infra and whether it lies under your budget or not. You may also want to take note that all your resources are being created in the same region… etc… etc.
Sounds magical right !!! We all know that these concerns are very important when you’re looking for a highly consistent, fully tracked, and automated approach. That’s why in this article we are going to look for a simple step-by-step way to automate and streamline our Terraform code using Azure DevOps (ADO).
Networking plays an important role in connecting the components of infrastructure. AWS networking feature works with various types of workloads and provides security, availability, and manageability. Now as most of the IT companies are working on cloud environments for cost reduction, high availability, data security, we are getting some interesting networking features as services. We can manage these quite easily too. Among those services is Elastic Network Interface (ENI) which we get by default when we create an EC2 instance on AWS and can be seen while the instance is being created. It may surprise many of us that the security group is attached to this elastic network interface.
MongoDB is the most popular NoSQL and an open-source document-oriented database. The term NoSQL means ‘non-relational’.This simply means mongo does not base on a table-like relational database structure. It is moreover a schemaless database. In Mongo information is stored in JSON-style documents.
It claims to be the world’s most widely used open-source host-based intrusion detection system. In short, we can call it HIDS. It performs log analysis, integrity checking, Windows registry monitoring, rootkit detection, time-based alerting, and active response. This is made up of two parts: Ossec server and Ossec agent. The Ossec server is used to monitor other servers that we call Ossec agents. At any time, an agent can be added to the Ossec server for its monitoring and can be removed. For that, server and agent connections need to be established, which we will be discussing. It also provides a Web interface for showing all alerts, logs, and agent information.
Possible scenarios that you might face of Intrusion on your servers:
1) Attacker launched a brute force attack against your machine. Now you need to track him. For that, you need his IP address. First, on your Ossec server, do:
Where you find Source IP against the alert of SSH insecure connection attempt rule. Secondly, we can get it from a UI-based alert.
A patch is a set of updates to a server or its supporting data designed to update, fix and improve, including fixing security vulnerabilities and other bugs. They may be applied to program files on a storage device or in computer memory. Patches may be permanent or temporary. In a brief overview, you need to perform the following tasks for patch management: 1. Create a patch catalog. 2. Analyze the target to determine the patches that need to deploy. 3. Deploy the required patches to targets requiring remediation. 4. Analyze the targets again to ensure each server has the correct patch.