Security Resources

DZone's Featured Security Resources

By Aashreya Shankar

REST APIs are the heart of any modern software application. Securing access to REST APIs is critical for preventing unauthorized actions and protecting sensitive data. Additionally, companies must comply with regulations and standards to operate successfully. This article describes how we can protect REST APIs using Role-based access control (RBAC) in the Quarkus Java framework. Quarkus is an open-source, full-stack Java framework designed for building cloud-native, containerized applications. The Quarkus Java framework comes with native support for RBAC, which will be the initial focus of this article. Additionally, the article will cover building a custom solution to secure REST endpoints. Concepts Authentication: Authentication is the process of validating a user's identity and typically involves utilizing a username and password. (However, other approaches, such as biometric and two-factor authentication, can also be employed). Authentication is a critical element of security and is vital for protecting systems and resources against unauthorized access. Authorization: Authorization is the process of verifying if a user has the necessary privileges to access a particular resource or execute an action. Usually, authorization follows authentication. Several methods, such as role-based access control and attribute-based access control, can be employed to implement authorization. Role-Based Access Control: Role-based access control (RBAC) is a security model that grants users access to resources based on the roles assigned to them. In RBAC, users are assigned to specific roles, and each role is given permissions that are necessary to perform their job functions. Gateway: In a conventional software setup, the gateway is responsible for authenticating the client and validating whether the client has the necessary permissions to access the resource. Gateway authentication plays a critical role in securing microservices-based architectures, as it allows organizations to implement centralized authentication. Token-based authentication: This is a technique where the gateway provides an access token to the client following successful authentication. The client then presents the access token to the gateway with each subsequent request. JWT: JSON Web Token (JWT) is a widely accepted standard for securely transmitting information between parties in the form of a JSON object. On successful login, the gateway generates a JWT and sends it back to the client. The client then includes the JWT in the header of each subsequent request to the server. The JWT can include required permissions that can be used to allow or deny access to APIs based on the user's authorization level. Example Application Consider a simple application that includes REST APIs for creating and retrieving tasks. The application has two user roles: Admin — allowed to read and write. Member — allowed to read-only. Admin and Member can access the GET API; however, only Admins are authorized to use the POST API. Java @Path("/task") public class TaskResource { @GET @Produces(MediaType.TEXT_PLAIN) public String getTask() { return "Task Data"; } @POST @Produces(MediaType.TEXT_PLAIN) public String createTask() { return "Valid Task received"; } } Configure Quarkus Security Modules In order to process and verify incoming JWTs in Quarkus, the following JWT security modules need to be included. For a maven-based project, add the following to pom.xml XML <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-smallrye-jwt</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-smallrye-jwt-build</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-test-security-jwt</artifactId> <scope>test</scope> </dependency> For a gradle-based project, add the following: Groovy implementation("io.quarkus:quarkus-smallrye-jwt") implementation("io.quarkus:quarkus-smallrye-jwt-build") testImplementation("io.quarkus:quarkus-test-security-jwt") Implementing RBAC Quarkus provides built-in RBAC support to protect REST APIs based on user roles. This can be done in a few steps. Step 1 The first step in utilizing Quarkus' built-in RBAC support is to annotate the APIs with the roles that are allowed to access them. The annotation to be added is @RolesAllowed, which is a JSR 250 security annotation that indicates that the given endpoint is accessible only if the user belongs to the specified role. Java @GET @RolesAllowed({"Admin", "Member"}) @Produces(MediaType.TEXT_PLAIN) public String getTask() { return "Task Data"; } @POST @RolesAllowed({"Admin"}) @Produces(MediaType.TEXT_PLAIN) public String createTask() { return "Valid Task received"; } Step 2 The next step is to configure the issuer URL and the public key. This enables Quarkus to verify the JWT and ensure it has not been tampered with. This can be done by adding the following properties to the application.properties file located in the /resources folder. Properties files mp.jwt.verify.publickey.location=publicKey.pem mp.jwt.verify.issuer=https://myapp.com/issuer quarkus.native.resources.includes=publicKey.pem mp.jwt.verify.publickey.location - This configuration specifies the location of the public key to Quarkus, which must be located in the classpath. The default location Quarkus looks for is the /resources folder. mp.jwt.verify.issuer - This property represents the issuer of the token, who created it and signed it with their private key. quarkus.native.resources.includes - this property informs quarks to include the public key as a resource in the native executable. Step 3 The last step is to add your public key to the application. Create a file named publicKey.pem, save the public key in it. Copy the file to the /resources folder located in the /src directory. Testing Quarkus offers robust support for unit testing to ensure code quality, particularly when it comes to RBAC. Using the @TestSecurity annotation, user roles can be defined, and a JWT can be generated to call REST APIs from within unit tests. Java @Test @TestSecurity(user = "testUser", roles = "Admin") public void testTaskPostEndpoint() { given().log().all() .body("{id: task1}") .when().post("/task") .then() .statusCode(200) .body(is("Valid Task received")); } Custom RBAC Implementation As the application grows and incorporates additional features, the built-in RBAC support may become insufficient. A well-written application allows users to create custom roles with specific permissions associated with them. It is important to decouple roles and permissions and avoid hardcoding them in the code. A role can be considered as a collection of permissions, and each API can be labeled with the required permissions to access it. To decouple roles and permissions and provide flexibility to users, let’s expand our example application to include two permissions for tasks. task:read — permission would allow users to read tasks task:write — permission would allow users to create or modify tasks. We can then associate these permissions with the two roles: "Admin" and "Member" Admin: assigned both read and write. ["task:read", "task:write"] Member: would only have read. ["task:read"] Step 1 To associate each API with a permission, we need a custom annotation that simplifies its usage and application. Let's create a new annotation called @Permissions, which accepts a string of permissions that the user must have in order to call the API. Java @Target({ ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) public @interface Permissions { String[] value(); } Step 2 The @Permissions annotation can be added to the task APIs to specify the required permissions for accessing them. The GET task API can be accessed if the user has either task:read or task:write permissions, while the POST task API can only be accessed if the user has task:write permission. Java @GET @Permissions({"task:read", "task:write"}) @Produces(MediaType.TEXT_PLAIN) public String getTask() { return "Task Data"; } @POST @Permissions("task:write") @Produces(MediaType.TEXT_PLAIN) public String createTask() { return "Valid Task received"; } Step 3 The last step involves adding a filter that intercepts API requests and verifies if the included JWT has the necessary permissions to call the REST API. The JWT must include the userID as part of the claims, which is the case in a typical application since some form of user identification is included in the JWT token The Reflection API is used to determine the method and its associated annotation that is invoked. In the provided code, user -> role mapping and role -> permissions mapping are stored in HashMaps. In a real-world scenario, this information would be retrieved from a database and cached to allow for faster access. Java @Provider public class PermissionFilter implements ContainerRequestFilter { @Context ResourceInfo resourceInfo; @Inject JsonWebToken jwt; @Override public void filter(ContainerRequestContext requestContext) throws IOException { Method method = resourceInfo.getResourceMethod(); Permissions methodPermAnnotation = method.getAnnotation(Permissions.class); if(methodPermAnnotation != null && checkAccess(methodPermAnnotation)) { System.out.println("Verified permissions"); } else { requestContext.abortWith(Response.status(Response.Status.FORBIDDEN).build()); } } /** * Verify if JWT permissions match the API permissions */ private boolean checkAccess(Permissions perm) { boolean verified = false; if(perm == null) { //If no permission annotation verification failed verified = false; } else if(jwt.getClaim("userId") == null) { // Don’t support Anonymous users verified = false; } else { String userId = jwt.getClaim("userId"); String role = getRolesForUser(userId); String[] userPermissions = getPermissionForRole(role); if(Arrays.asList(userPermissions).stream() .anyMatch(userPerm -> Arrays.asList(perm.value()).contains(userPerm))) { verified = true; } } return verified; } // role -> permission mapping private String[] getPermissionForRole(String role) { Map<String, String[]> rolePermissionMap = new HashMap<>(); rolePermissionMap.put("Admin", new String[] {"task:write", "task:read"}); rolePermissionMap.put("Member", new String[] {"task:read"}); return rolePermissionMap.get(role); } // userId -> role mapping private String getRolesForUser(String userId) { Map<String, String> userMap = new HashMap<>(); userMap.put("1234", "Admin"); userMap.put("6789", "Member"); return userMap.get(userId); } } Testing In a similar way to testing the built-in RBAC, the @TestSecurity annotation can be utilized to create a JWT for testing purposes. Additionally, the Quarkus library offers the @JwtSecurity annotation, which enables the addition of extra claims to the JWT, including the userId claim. Java @Test @TestSecurity(user = "testUser", roles = "Admin") @JwtSecurity(claims = { @Claim(key = "userId", value = "1234") }) public void testTaskPosttEndpoint() { given().log().all() .body("{id: task1}") .when().post("/task") .then() .statusCode(200) .body(is("Task edited")); } @Test @TestSecurity(user = "testUser", roles = "Admin") @JwtSecurity(claims = { @Claim(key = "userId", value = "6789") }) public void testTaskPostMember() { given().log().all() .body("{id: task1}") .when().post("/task") .then() .statusCode(403); } Conclusion As cyber-attacks continue to rise, protecting REST APIs is becoming increasingly crucial. A potential security breach can result in massive financial losses and reputational damage for a company. While Quarkus is a versatile Java framework that provides built-in RBAC support for securing REST APIs, its native support may be inadequate in certain scenarios, particularly for fine-grained access control. The above article covers both the implementation of the built-in RBAC support in Quarkus, as well as the development and testing of a custom role-based access control solution in Quarkus. More

Zero Trust Network for Microservices With Istio

By Anas T

Security was mostly perimeter-based while building monolithic applications. It means securing the network perimeter and access control using firewalls. With the advent of microservices architecture, static and network-based perimeters are no longer effective. Nowadays, applications are deployed and managed by container orchestration systems like Kubernetes, which are spread across the cloud. Zero trust network (ZTN) is a different approach to secure data across cloud-based networks. In this article, we will explore how Istio, with ZTN philosophy, can help secure microservices. What Is Zero Trust Network (ZTN)? "Zero trust network" is a security paradigm that does not grant implicit trust to users, devices, and services, and continuously verifies their identity and authorization to access resources. In a microservices architecture, if a service (server) receives a request from another service (client), the server should not assume the trustworthiness of the client. The server should continuously authenticate and authorize a client first and then allow the communication to happen securely (refer to fig. A below). Fig. A: A Zero Trust Network (ZTN) environment where continuous authentication and authorization are enforced between microservices across multicloud. Why Is a Zero Trust Network Environment Inevitable for Microservices? The importance of securing the network and data in a distributed network of services cannot be stressed enough. Below are a few challenges that point to why a ZTN environment is necessary for microservices: Lack of ownership on the network: Applications moved from perimeter-based to multiple clouds and data centers with microservices. As a result, the network has also got distributed, giving more attack surface to intruders. Increased network and security breaches: Data and security breaches among cloud providers are increasingly common since applications moved to public clouds. In 2022, nearly half of all data breaches occurred in the cloud. Managing multicluster network policies has become tedious: Organizations deploy hundreds of services across multiple Kubernetes clusters and environments. Network policies are local to clusters and do not usually work for multiple clusters. They need a lot of customization and development to define and implement security and routing policies in the multicluster and multicloud traffic. Thus, configuring and managing consistent network policies and firewall rules for each service becomes an everlasting and frustrating process. Service-to-service connection is not inherently secure in K8s: By default, one service can talk to another service inside a cluster. So, if a service pod is hacked, an attacker can quickly hack other services in that cluster easily (also known as vector attack). Kubernetes does not provide out-of-the-box encryption or authentication for communication between pods or services. Although K8s offers additional security features like enabling mTLS, it is a complex process and has to be implemented manually for each service. Lack of visibility into the network traffic: If there is a security breach, the Ops and SRE team should be able to react to the incident faster. Poor real-time visibility into the network traffic across environments becomes a bottleneck for SREs to diagnose issues in time. This impedes their ability for incident response, which leads to high mean time for recovery (MTTR) and catastrophic security risks. In theory, a zero trust network (ZTN) philosophy solves all the above challenges. In practice, Istio service mesh can help Ops and SREs to implement ZTN and secure microservices across the cloud. How Istio Service Mesh Enables ZTN for Microservices Istio is a popular open-source service mesh implementation software that provides a way to manage and secure communication between microservices. Istio abstracts the network into a dedicated layer of infrastructure and provides visibility and control over all communication between microservices. Istio works by injecting an Envoy proxy (a small sidecar daemon) alongside each service in the mesh (refer to fig. B). Envoy is an L4 and L7 proxy that helps in ensuring security connections and network connectivity among the microservices, respectively. The Istio control plane allows users to manage all these Envoy proxies, such as directly defining and cascading security and network policies. Fig B: Istio using Envoy proxy to secure connection between services across clusters and clouds. Istio simplifies enforcing a ZTN environment for microservices across the cloud. Inspired by Gartner Zero Trust Network Access, I have outlined four pillars of zero trust network that can be implemented using Istio. Four pillars of zero trust network enforced by Istio service mesh. 1. Enforcing Authentication With Istio Security teams would be required to create authentication logic for each service to verify the identity of users (humans or machines) that sent requests. The process is necessary to ensure the trustworthiness of the user. In Istio, it can be done by configuring peer-to-peer and request authentication policies using PeerAuthentication and RequestAuthentication custom resources (CRDs): Peer authentication policies involve authenticating service-to-service communication using mTLS. That is, certificates are issued for both the client and server to verify the identity of each other.Below is a sample PeerAuthentication resource that enforces strict mTLS authentication for all workloads in the foo namespace: YAML apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: foo spec: mtls: mode: STRICT Request authentication policies involve the server ensuring whether the client is even allowed to make the request. Here, the client will attach JWT (JSON Web Token) to the request for server-side authentication.Below is a sample RequestAuthentication policy created in the foo namespace. It specifies that incoming requests to the my-app service must contain JWT that is issued, and verified using public keys by entities mentioned under jwtRules. YAML apiVersion: security.istio.io/v1beta1 kind: RequestAuthentication metadata: name: jwt-example namespace: foo spec: selector: matchLabels: app: my-app jwtRules: - issuer: "https://issuer.example.com" jwksUri: "https://issuer.example.com/keys" Both authentication policies are stored in Istio configuration storage. 2. Implementing Authorization With Istio Authorization is verifying whether the authenticated user is allowed to access a server (access control) and perform the specific action. Continuous authorization prevents malicious users from accessing services, which ensures their safety and integrity. AuthorizationPolicy is another Istio CRD that provides access control for services deployed in the mesh. It helps in creating policies to deny, allow, and also perform custom actions against an inbound request. Istio allows setting multiple policies with different actions for granular access control to the workloads. The following AuthorizationPolicy denies POST requests from workloads in the dev namespace to workloads in the foo namespace. YAML apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: httpbin namespace: foo spec: action: DENY rules: - from: - source: namespaces: ["dev"] to: - operation: methods: ["POST"] 3. Multicluster and Multicloud Visibility With Istio Another important pillar of ZTN is network and service visibility. SREs and Ops teams would require real-time monitoring of traffic flowing between microservices across cloud and cluster boundaries. Having deep visibility into the network would help SREs quickly identify the root cause of anomalies, develop resolution, and restore the applications. Istio provides visibility into traffic flow and application health by collecting the following telemetry data from the mesh from the data and control plane. Logs: Istio collects all kinds of logs such as services logs, API logs, access logs, gateway logs, etc., which will help to understand the behavior of an application. Logs also help in faster troubleshooting and diagnosis of network incidents. Metrics: They help to understand the real-time performance of services for identifying anomalies and fine-tuning them in the runtime. Istio provides many metrics apart from the 4 golden ones, which are error rates, traffic, latency, and saturation. Distributed tracing: It is the tracing and visualizing of requests flowing through multiple services in a mesh. Distributed tracing helps understand interactions between microservices and provides a holistic view of service-to-service communication in the mesh. 4. Network Auditing With Istio Auditing is analyzing logs of a process over a period with the goal to optimize the overall process. Audit logs provide auditors with valuable insights into network activity, including details on each access, the methods used, traffic patterns, etc. This information is useful to understand the communication process in and out of the data center and public clouds. Istio provides information about who accessed (or requested), when, and onto what resources, which is important for auditors to investigate faulty situations. The information is required for the auditors to suggest steps to improve the overall performance of the network and security of cloud-native applications. Deploy Istio for a Better Security Posture The challenges around securing networks and data in a microservices architecture are going to be increasingly complex. Attackers are always ahead in finding vulnerabilities and exploiting them before anyone in the SRE team gets time to notice. Implementing a zero trust network will provide visibility and secure Kubernetes clusters from internal or external threats. Istio service mesh can lead this endeavor from the front, with its ability to implement zero trust out of the box. More

How To Manage Vulnerabilities in Modern Cloud-Native Applications

By Harshad Ithape

10 Best Practices for Using Kubernetes Network Policies

By Emmanuel Moila

How To Scan and Validate Image Uploads in Java

By Brian O'Neill CORE

Configuring the Security Plug-In/Custom Security Providers for WebLogic Resource Protection

WebLogic Server is a Java-based application server, and it provides a platform for deploying and managing distributed applications and services. It is a part of the Oracle Fusion Middleware family of products and is designed to support large-scale, mission-critical applications. WebLogic Server provides a Security Framework that includes a default Security Provider, which provides authentication, authorization, and auditing services to protect resources such as applications, EJBs, and web services. However, you can also use security plug-ins or custom security providers to extend the security framework to meet your specific security requirements. Here is a brief explanation of the security plug-ins and custom security providers in WebLogic Server: Security Plug-in: A security plug-in is a WebLogic Server component that provides authentication and authorization services for external security providers. It allows you to integrate third-party security products with WebLogic Server. The security plug-in communicates with the external security provider using the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) protocol. You can configure the security plug-in using the WebLogic Server Administration Console or the command-line interface. Custom Security Providers: WebLogic Server provides several security providers such as the default security provider, LDAP security provider, and RDBMS security provider. However, if these security providers do not meet your security requirements, you can develop custom security providers. Custom security providers allow you to extend the security framework to meet your specific security needs. You can develop custom security providers using the WebLogic Server API or the Security Provider APIs. The development of custom security providers requires expertise in Java programming, and it is recommended that you test the custom security providers thoroughly before deploying them to a production environment. Security plug-ins and custom security providers allow you to extend the WebLogic Server Security Framework to meet your specific security requirements. You can use the WebLogic Server Administration Console or the command-line interface to configure security plug-ins and develop custom security providers. WebLogic Server provides several features to protect your resources, such as applications, EJBs, and web services. Here are some ways to implement resource protection in WebLogic Server from unauthorized access: Authentication: Authorization: SSL/TLS: Network Access Control: Firewall: Secure Sockets Layer Acceleration: WebLogic Server provides a security framework that allows you to protect your resources, such as applications, EJBs, and web services. You can configure the security plug-in or custom security providers for resource protection in WebLogic Server by following these steps: Determine the security requirements: Before configuring the security plug-in or custom security providers, you need to determine the security requirements for your application. This includes identifying the authentication and authorization requirements. Configure the security realm: The security realm is the foundation of the WebLogic Server security framework. You need to configure the security realm with the necessary users, groups, and roles. You can use the WebLogic Administration Console or the WLST scripting tool to configure the security realm. Configure the security providers: WebLogic Server provides several security providers, including the default security provider, LDAP security provider, and RDBMS security provider. Configure the security plug-in: The security plug-in is a WebLogic Server component that provides authentication and authorization services to protect your resources. You can configure the security plug-in using the WebLogic Administration Console or the WLST scripting tool. Configure custom security providers: If the default security providers do not meet your security requirements, you can develop custom security providers. You can develop custom security providers using the WebLogic Server API or the Security Provider APIs. Test the security configuration: After configuring the security plug-in or custom security providers, you should test the security configuration thoroughly to ensure that it is working as expected. Monitor the security configuration: It is important to monitor the security configuration to ensure that it is running smoothly. This includes monitoring security logs, error logs, and other important metrics. Following these steps, you can configure the security plug-in or custom security providers for resource protection in WebLogic Server.

By Kishore Kandepu

What Is mTLS? How To Implement It With Istio

This is a detailed guide on mTLS and how to implement it with Istio service mesh. We will be covering the following topics here: Understanding mTLS protocol wrt TCP/IP suite SSL vs TLS vs mTLS Why is mTLS important? Use-cases of mTLS Certificate Authority, Publick keys, X.509 certificate: Must-know mTLS concepts How does mTLS work? How to enable mTLS with Istio service mesh Certificate management for mTLS in Istio What Is mTLS? Mutual Transport Layer Security (mTLS) is a cryptographic protocol designed to authenticate two parties and secure their communication in the network. mTLS protocol is an extension of TLS protocol where both the parties- web client and web server- are authenticated. The primary aim of mTLS is to achieve the following: Authenticity: To ensure both parties are authentic and verified Confidentiality: To secure the data in the transmission Integrity: To ensure the correctness of the data being sent mTLS protocol: A Part of the TCP/IP Suite mTLS protocol sits between the application and transport layers to encrypt only messages (or packets). It can be seen as an enhancement to the TCP protocol. The below diagram conceptually provides the location of mTLS in the TCP/IP protocol suite. SSL vs TLS vs mTLS: Which Is New? Security engineers, architects, and developers use SSL, TLS, and mTLS interchangeably, often because of their similarity. Loosely mentioning, mTLS is an enhancement to TLS, and TLS is an enhancement to SSL. The first version of Secure Socket Layer (SSL) was developed by Netscape corporate in 1994; the most popular versions were versions 2 and 3- created in 1995. It was so widely popular that it made its way into one of the James Bond movies (below is the sneak-peak of Tomorrow Never Dies, 1997). The overall working of SSL is carried by three sub-protocol: Handshake protocol: This is used to authenticate the web client and the web server and establish a secured communication channel. In the handshaking process, a shared key will be generated, for the session only, to encrypt the data during communication. Record protocol: This protocol helps to maintain the confidentiality of data in the communication between the client and the server using a newly generated shared secret key. Alert protocol: In case the client or the server detects an error, the alert protocol would close the SSL connection ( the transmission of data will be terminated); destroying all the sessions, shared keys, etc. As there were more internet applications, the requirement for fine-grain security of the data in the network was more. So Transport Layer Security (TLS) - a standard internet version of SSL - was developed by IETF. Netscape handed over the SSL project to IETF, and TLS is an advanced version of SSL; the code idea and implementation of the protocol are the same. The main difference between the SSL and TLS protocols is that the cipher suite (or the algorithms) used to encrypt data in TLS is advanced. Secondly, the handshake, record, and alert protocols are modified and optimized for internet usage. Note: In the SSL handshake protocol, the server authentication to the client by sending the certificate was mandatory, but the client's authentication was optional to secure the line. But in TLS, there was only a provision to authenticate we-servers to the client, not vice-versa. Almost all the websites you visit with HTTPS as the protocol will use TLS certificates to establish themselves as genuine sites. If you visit Google.com and click the padlock symbol, it will show the TLS certificates. The TLS was mainly used for web applications with the client being the user. Additionally, ensuring the authentication of billions of clients or users is only feasible for some web applications. But as the large monolithic applications broke into numerous microservices that communicate over the internet, the need for mTLS grew suddenly. mTLS protocol ensures both the web client and the web server authenticate themselves before a handshake. (We will see the working model of the mTLS protocol later in this article). Why Is mTLS More Important Than Ever? Modern business is done using web applications whose underlying architecture follows a hybrid cloud model. Microservices will be distributed across public/private clouds, Kubernetes, and on-prem VMs. And the communication among various microservices and components happens over the network, posing a significant risk of hacking or malicious attacks. Below are a few scenarios of cyber-attacks on the web that can be avoided entirely by using mTLS protocols. Man-in-the-middle attack (MITM): Attackers can place themselves between a client and a server to intercept the data during the transmission. When mTLS is used, attackers cannot authenticate themselves and will fail to steal the data. IP Spoofing: Another case is when bad guys masquerade as someone you trust and injects malicious packets into the receiver. This is again solved by end-point authentication in mTLS to determine with certainty if network packets or the data originates from a source we trust. Packet Sniffer: The attacker can place a passive receiver near the wireless transmitter to obtain a copy of every packet transmitted. Such an attack is prevalent in banking and Fintech domains when an attacker wants to steal sensitive information such as card numbers, banking application usernames, passwords, SSNs, etc. Since packet sniffing is non-intrusive, it is tough to detect. Hence the best way to protect data is to involve cryptography. mTLS helps encrypt the data using complex cryptographic algorithms that are hard to decipher by packet sniffers. Denial-of-service (DoS) attacks: The attackers aim to make the network or the web server unusable by legitimate applications or users. This is done by sending vulnerable packets, or deluge to packets, or by opening a large number of TCP connections to the hosts (or the web server) so that the server ultimately crashes. DoS and Distributed DoS (advanced DoS technique) can be avoided by invoking mTLS protocols in the applicable communication. All the malicious DoS attacks will be discarded before entering into the handshake phase. Use Cases of mTLS in the Industry The use cases of mTLS are growing daily with the increasing usage of business through web applications and the simultaneous rise in threats of cyberattacks. Here are a few important use cases based on our experiences while discussing with many leaders from various industries or domains- banking, fintech, and online retail companies. Hybrid cloud and multicloud applications: Whenever organizations use a mix of data centers — on-prem, public, or private cloud — the data leaves the secured perimeter and goes out of the network. In such cases, mTLS should be used to protect the data. Microservices-based B2B software: Many B2B software in the market follows a microservices architecture. Each service would talk to the other using REST APIs. Even though all the services are hosted in a single data center, the network should be secured to protect the data in transit (in case the firewall is breached). Online retail and e-commerce application: Usually, e-commerce and online retail applications use Content Delivery Network (CDN) to fetch the application from the server and show it to users. Although TLS is implemented in the CDN to authenticate itself when a user visits the page, there should be a security mechanism to secure the network between the CDN and the web server through mTLS. Banking applications: Applications that carry susceptible transactions, such as banks, financial transaction apps, payment gateways, etc., should take extreme precautions to prevent their data from getting stolen. Millions of online transactions happen every day using various banking and fintech apps. Sensitive information such as bank usernames, passwords, debit/credit card details, CVV numbers, etc., can be easily hacked if the data in the network is not protected. Strict authentication and confidentiality can be applied to the network using mTLS. Industry regulation and compliance: Every country will have some rules and standards to govern the IT infrastructure and protect the data. All the policies, such as FIPS, GDPR, PCI-DSS, HIPAA, ISO27001, etc., outline strict security measures to protect the data-at-rest and data-in-transit. For strict authentication in the network, mTLS can be used, and companies can adhere to various standards. Below are the few concepts one needs to be aware of before understanding the mechanism of how mTLS works. (You can skip reading if you are comfortable.) Certificates and Public/Private Keys: Must-Know mTLS Concepts Certificates A (digital) certificate is a small computer file issued by a certificate authority (CA) to authenticate a user, an application, or an organization. A digital certificate contains information such as- the name of the certificate holder, serial number of the certificate, expiry date, public key, and signature of the certificate issuing authority. Certificate Authority (CA) A certificate authority (CA) is a trusted 3rd party that verifies user identity and issues an encrypted digital certificate containing the applicant's public key and other information. Notable CAs are VeriSign, Entrust, LetsEncrypt, Safescript Limited, etc. Root CA/Certificate Chain Certificate Authority hierarchies are created to distribute the workloads of issuing certificates. There can be entities issuing certificates from different CA at various levels. In the multi-level hierarchy (like parent and child) of CAs, there is one CA at the top, called the Root CA (refer to the below image). Each CA would also have its certificate issued by the parent CA, and the root CA will have self-signed certificates. To ensure the CA (which issued the certificate to the client/server) is trusted, the security protocol suggests that entities send their digital certificate and the entire chain leading up to the root CA. Public and Private Key Pair While creating certificates for an entity, the CA would generate a public and a private key- commonly called a public key pair. The public and private keys are used to authenticate their identity and encrypt data. Public keys are published, but the private key is kept secret. If you are interested to learn about the algorithms to generate public keys, read more on RSA, DSA, ECDSA, and ed25519. X.509 Certificate It is a special category of the certificate, defined by the International Telecommunications Union, which binds an application's identity (hostname, organization name, etc.) to a public key using a digital signature. It is the most commonly used certificate in all the security protocols SSL/TLS/mTLS for securing web applications. How Does mTLS Work? As explained earlier, the mTLS has a similar implementation of sub-protocols as SSL. There are 8 phases (mentioned below) for two applications to talk to each other using the mTLS protocol. Establish security capabilities with hello: The client tries to communicate with the server (also known as client hello). The client hello message would contain values for specific parameters such as mTLS version, session id, Cipher suite, compression algorithm, etc. The server also would send a similar response called server hello with the values (it supports) for the same parameters sent by the client. Server authentication and key exchange: In this phase, the server would share its digital certificate (mostly X.509 certificates for microservices) and the entire chain leading up to root CA to the client. It would also request the client's digital certificate. Client verifies the server's certificate: The client would use the public key in the digital certificate to validate the server's authenticity. Client authentication and key exchange: After validation, the client sends a digital certificate to the server for verification. Server verifies client's certificate: The server verifies the client's authenticity. Master key generation and handshake complete: Once the parties' authenticity is established, the client and server will establish a handshake, and two new keys will be generated; shared secret information is only known to the parties and active for the session. Master secret: for encryption Message Authentication Code (MAC): for assuring message integrity Communication encrypted and transmission starts: The exchange of the information will begin with all the messages or packets encrypted using the master secret key. Behind the veil, the mTLS protocol will divide the message into smaller blocks called fragments, compress each fragment, add the MAC for each block, and finally encrypt them using the master secret. Data transmission starts: Finally, the mTLS protocol will append headers to the blocks of messages and send it to TCP protocol to send it to the destination or receiver. Session ends: Once the communication completes, the session will close. If an anomaly is detected during the transmission, the mTLS protocol will destroy all the keys and secrets and terminate the session immediately. Note: In the above phases, we have assumed that the CA would have issued a certificate to the entities which are still valid. In reality, the certificate of mission-critical applications expires soon, and there is a requirement for constant certificate rotation (we will straight away jump into how Istio enables mTLS and certificate rotation). How To Enable mTLS and Certificate Rotation Using Istio Service Mesh Istio service mesh is an infrastructure layer that abstracts out the network and security later out of application layers. It does so by injecting an Envoy proxy (an L4 and L7 sidecar proxy) into each application and listening to all the network communication. mTLS Implementation in Istio Though Istio supports multiple authentication types, it is best known for implementing mTLS to applications hosted over the cloud, on-prem, or Kubernetes infrastructure. The Envoy proxy acts as Policy Enforcement Points (PEP); you can implement mTLS using the peer-to-peer (p2p) authentication policy provided by Istio and enforce it through the proxies at the workload level. Example of p2p authentication policy in Istio to apply mTLS to demobank app in the istio-nm namespace: YAML apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: "mTLS-peer-policy" namespace: "istio-nm" spec: selector: matchLabels: app: demobank mtls: mode: STRICT The working mechanism of mTLS authentication in Istio is as follows: At first, all the outbound and inbound traffic to any application in the mesh is re-routed through the Envoy proxy. The mTLS happens between the client-side Envoy proxy and the server-side Envoy proxy. The client-side Envoy proxy would try to connect with the server-side Envoy proxy by exchanging certificates and proving their identity. Once the authentication phase is completed successfully, a TCP connection between the client and service side Envoy proxy is established to carry out encrypted communications. Note that mTLS with Istio can be implemented at all levels: application, namespace, or mesh-wide. Certificate Management and Rotation in Istio Service Mesh Istio provides a stronger identity by issuing X.509 certificates to Envoy proxies attached to applications. The certificate management and rotation are done by an Istio agent running in the same container as the Envoy proxy. The Istio agents talk to the Istiod- the control plane of Istio- to effectively circulate the digital certificates with public keys. Below are the details phases of certificate management in Istio: Istio agents generate public key pairs (private and public keys) and then send the public key to the Istio control plane for signing. This is called a certificate signing request (CSR). Istiod has a component (earlier Galley) that acts as the CA. Istiod validates the public key in the request, signs, and issues a digital certificate to the Istio agent. When mTLS connection is required, Envoy proxies fetch the certificate from the Istio agent using Envoy secret discovery service (SDS) API. The Istio agent observes the expiration of the certificate used by the Envoy. Upon the certificate's expiry, the agent initiates a CSR to Istiod. Network Security With Open-Source Istio Microservices architecture is the norm nowadays. The distributed nature of applications gives a high attack surface for intruders since these applications communicate with each other over a network. Security cannot be an afterthought in such a scenario as it can lead to catastrophic data breaches. Implementing mTLS with Istio is an effective way to secure communication between cloud-native applications. And many leading companies like Splunk, Airbnb, and Salesforce, use open-source Istio to enable mTLS and enhance the security of their applications.

By Debasree Panda

Protecting Your Server Room: 5 Best Practices for Physical Security

Welcome to the world of server rooms — the beating heart of every digital enterprise. Whether you're an entrepreneur or a seasoned IT professional, you know that the security of your server room is of utmost importance. Without adequate physical security measures, your servers are vulnerable to theft, vandalism, and damage from natural disasters. Within the realm of safeguarding server rooms, a multifaceted approach to physical security is necessary, encompassing four distinct strata of fortification: namely, perimeter security, facility controls, computer room controls, and cabinet controls. The following are various physical security practices that may effectively preserve the sanctity and security of server rooms. Access Control The prevalent access control mode is the keycard system. Authorized individuals are given customized keycards to enter the server room, which can be restricted by time or day and instantly deactivated if lost or stolen. Advanced keycard systems also track entry and exit to establish an audit trail for enhanced security. Biometric Access Systems Biometric access control, utilizing physical traits such as fingerprints or facial recognition, offers unparalleled security by obviating the possibility of replication or theft. Keycards are rendered unnecessary, reducing the risk of loss or theft, and are increasingly popular in high-security environments, such as server rooms, due to their added protection. Two-Factor Authentication Two-factor authentication is a potent access control approach that demands two types of verification to allow access to the server room. For instance, an employee may require entering a code from their keycard and a password or PIN. Dual-factor authentication is extremely secure and thwarts unauthorized access to the room. Surveillance Surveillance stands as a vital element in safeguarding your server room. Monitoring its access and activity can thwart trespassers and promptly detect security breaches. Surveillance systems rely heavily on video cameras, enabling constant monitoring of server rooms regardless of physical presence. Top-notch cameras produce clear footage in all light conditions, including night vision. Mere installation of cameras falls short. To optimize surveillance, the acquisition of alarm systems and monitoring software is imperative. They enable instantaneous detection of security hazards and prompt, efficient responses. Environmental Monitoring Environmental monitoring involves the use of sensors and monitoring equipment to detect and alert you to any changes in the environment of your server room. Here are some key points to consider when implementing an environmental monitoring system: Temperature Sensors High temperatures can trigger server and equipment overheating, resulting in system crashes and downtime. Temperature sensors detect room temperature changes and signal alerts above or below designated thresholds, facilitating proactive measures to prevent damage. Humidity Sensors High humidity levels can lead to condensation and water damage to your equipment, while low humidity levels can cause static electricity buildup. Humidity sensors can help you maintain optimal humidity levels and avoid these issues. Water Leak Sensors The detrimental effects of water leaks on your equipment can lead to significant damage and operational downtime. Employing water leak sensors can promptly detect moisture in the area, preventing any potential harm. Implementing an environmental monitoring system in your server room guarantees the well-being and security of your equipment, providing you with peace of mind. Fire Protection System Swiftly, fires can inflict substantial harm on your server space, culminating in the forfeiture of data, downtime, or even total cessation of operations. Thus, a potent fire protection system is vital to mitigate fire hazards and promptly and efficiently manage any fire outbreak. The deployment of fire watch guards is a crucial element in safeguarding your server room against fire hazards. Their training enables them to diligently monitor the room and identify potential threats, such as overloaded electrical outlets and faulty wiring. Timely detection and intervention by the guards prevent the escalation of issues into more significant problems. It's also essential to have a fire safety plan in place that outlines what steps you should take in case of a fire. This plan should include evacuation procedures, emergency contact information, and details on how to shut down your equipment safely. Security Policies and Procedures The protocols and regulations pertaining to safeguarding your server room furnish a compilation of directives, clarifying the optimal methodologies for fortifying it, and thereby raising awareness throughout the enterprise regarding security best practices. Such policies and procedures encompass a spectrum of measures, such as access control policies, contingency plans for adverse events, and periodic security evaluations. Regularly revisiting security policies and procedures to align with evolving technology and threats is crucial. Equally vital is disseminating and consistently training the organization on these protocols. Conclusion Optimizing server room security through access control, surveillance, environmental monitoring, fire protection, and physical measures is crucial for data protection and business continuity. Yet, remember, security is an ongoing process requiring regular audits, updates, and training. Don't wait until it's too late. Prioritize server room security now for peace of mind.

By Michael Chukwube

Safeguard Your Code With GitHub Dependabot and IBM Cloud Toolchain

Have you ever wondered if people can take advantage of vulnerabilities present in your code and exploit it in different ways, like selling or sharing exploits, creating malware that can destroy your functionality, launching targeted attacks, or even engaging in cyber attacks? These mostly happen through known vulnerabilities which are present in the code, which are also known as CVEs, which stand for Common Vulnerabilities and Exposures. In 2017, a malicious ransomware attack, WannaCry, wrought havoc by infiltrating over 300,000 computers in more than 150 nations. The assailants were able to utilize a flaw in the Microsoft Windows operating system, which had been designated a CVE identifier (CVE-2017–0144), to infect the computers with the ransomware. The ransomware encrypted users’ files and demanded a ransom payment in exchange for the decryption key, causing massive disruptions to businesses, hospitals, and government agencies. The attack’s total cost was estimated to have been in the billions of dollars. When you have thousands of packages in use for a single functionality, it can be daunting to track every package utilized in your code and determine whether it is vulnerable. How do you ensure that your code is secure and cannot be abused in any way? What if you automatically get notified with a Slack alert — as soon as a new vulnerability is detected — in one of your many Git repositories. What if an issue automatically gets created, which can be used to monitor similar issues daily? This is where Dependabot enters the picture. Dependabot can be integrated with various development tools and platforms such as GitHub, GitLab, Jenkins, and Travis CI, among others. It also supports a wide range of programming languages, and it can also be used with Docker to examine Docker images for outdated dependencies. As a result, it is a versatile tool for managing dependencies and keeping projects current with the most recent security patches and bug fixes. To maintain the safety and security of your program dependencies, the use of Dependabot notifications is critical. Dependabot automates the process of scanning your code repositories for vulnerabilities and out-of-date dependencies. Dependabot alerts are notifications sent when a vulnerability is discovered in one of your dependencies. They are meant to keep you informed about any potential security risks that may emerge. Dependabot Alerts can only be viewed by individuals with admin access to a repository or to users, and teams who are given access explicitly will have permission to view and manage Dependabot or secret scanning alerts. However, most people will not have access to Dependabot alerts for the component or microservice which they are working on. How can a developer learn about CVEs present in the code? How can they remediate vulnerabilities if they are unaware of them? In this scenario, we can use a combination of GitHub API, Webhooks, and Tekton pipelines to our advantage. You can leverage the IBM Cloud toolchain to create an automation that creates issues in the repository where the CVE was identified and can also close the issue once the CVE has been remedied. This way, developers can keep track of the vulnerabilities present in the code and have a clearer idea, which aids them in remaining compliant. Flow Diagram The Pipeline Implementation GitHub has the ability to send POST requests to a webhook for a different set of events like repository vulnerability alerts (aka Dependabot Alerts) which will be useful for our case. Creating a webhook with this event selected will send POST requests whenever a new vulnerability is detected or remediated. The webhook can act as a pipeline trigger. Github Hooks Configuration Before implementing the pipeline, it is important to understand the payload of the POST request and how it can be utilized. The payload contains an “action” key and an “alert” key. The “action” key indicates whether it is a remediation alert or a creation alert, while the “alert” key contains an array of important details such as the affected package name, range, severity, and suggested fix. Git Issue To utilize this information and alert the team, a pipeline can be created with a generic webhook trigger, which will trigger whenever there is a request sent to the webhook. The pipeline can extract the affected package from the payload and check if an issue for the CVE already exists in the repository. If not, it will create an issue with all the required details to identify the CVE and provide a suggested fix, if any. The pipeline can also add IBM-recommended due dates based on the severity. Once the developer works on remediation and the changes are reflected in the default branch, Dependabot will send a request to the webhook with the action being “resolve.” The pipeline can extract the affected package name from the payload and check if the issue is open in the repository. If yes, it will automatically close the issue and add a comment saying, “Vulnerability has been remediated, closing the issue.” Automatic Git Issue Closure Additionally, the pipeline can be configured to send a Slack alert whenever an issue is created or resolved based on the team’s requirements. This pipeline can work at either the repository level or organization level, tracking all the repositories inside an organization if the webhook is integrated at an organization level. Slack Alert Overall, implementing this pipeline can help developers stay compliant and ensure safety and security. However, it is important to follow best practices as a team to ensure the effectiveness of the pipeline. Don’t miss out on the next blog post about setting up the automation. Subscribe to my page and receive instant notifications as soon as I publish it, so you can stay ahead of the game and keep your skills sharp!

By Rishi Patel

Build a Web3 Ticketing System and Disrupt Online Ticketing

A popular and practical use case for web3 is generating tickets to live events. Blockchains such as Ethereum can guarantee the ownership, originator, and authenticity of a digital item, effectively solving the problem of counterfeit tickets. While major players such as Ticketmaster struggle to mitigate scalpers (trying desperately to control who can resell tickets, where, and for how much) and ticket fraud—web3 already has a solution. The ticketing industry is ripe for disruption. In this tutorial, we’ll look at how to create such a ticketing solution using ConsenSys Truffle, Infura, and the Infura API. We’ll deploy a smart contract that acts as a ticketing service and creates tickets as ERC-20/ERC-721 digital tokens. We’ll also walk through a few architectures of potential frontends that could interface with the contract, and together function as an integrated, full-stack, web3 ticketing system. Let’s get building! Create a Ticketing System on Ethereum The basic architecture of our system is intended to create a smart contract that issues our tickets as digital ERC-20/ERC-721 tokens. These are perfect for what we want to build. They are probably unique digital tokens that allow us to ensure that every ticket is unique and cannot be copied or forged. This not only guarantees a secure ticketing experience for concertgoers, but also empowers artists (and event organizers) with greater control over ticket distribution, pricing, and resale. Using smart contracts even allows for new revenue streams such as royalty payments and revenue sharing! (If you need background info on any of these terms, blockchain technology, or web3 in general, check out this article on Learning to Become a Web3 Developer by Exploring the Web3 Stack). Step 1: Install MetaMask The first thing we’re going to do is set up a MetaMask wallet and add the Sepolia test network to it. MetaMask is the world’s most popular, secure, and easy-to-use self-custodial digital wallet. First, download the MetaMask extension. After you install the extension, MetaMask will set up the wallet for you. In the process, you will be given a secret phrase. Keep that safe, and under no circumstances should you make it public. Once you’ve set up MetaMask, click on the Network tab on the top-right. You will see an option to show/hide test networks. Once you turn the test networks on, you should be able to see the Sepolia test network in the drop-down menu. We want to use the Sepolia network so that we can deploy and test our system without spending any real money. Step 2: Get Some Test ETH In order to deploy our smart contract and interact with it, we will require some free test ETH. You can obtain free Sepolia ETH from the Sepolia faucet. Once you fund your wallet, you should see a balance when you switch to the Sepolia test network on MetaMask. Step 3: Install npm and Node Like all Ethereum dapps, we will build our project using node and npm. In case you don't have these installed on your local machine, you can do so here. To ensure everything is working correctly, run the following command: Plain Text $ node -v If all goes well, you should see a version number for Node. Step 4: Sign Up for an Infura Account In order to deploy our contract to the Sepolia network, we will need an Infura account. Infura gives us access to RPC endpoints for fast, reliable, and easy access to the Ethereum blockchain. Sign up for a free account. Once you’ve created your account, navigate to the dashboard and select Create New Key. For the network, choose Web3 API and name it Ticketing System, or something of your choosing. Once you click on Create, Infura will generate an API key for you and give you RPC endpoints to Ethereum, Goerli, Sepolia, L2s, and non-EVM L1s (and their corresponding testnets) automatically. For this tutorial, we are only interested in the Sepolia RPC endpoint. This URL is of the form https://sepolia.infura.io/v3/←API KEY→. Step 5: Create a Node Project and Install Necessary Packages Let's set up an empty project repository by running the following commands: Plain Text $ mkdir ticketing && cd ticketing $ npm init -y We will be using Truffle, a long-trusted development environment and testing framework for EVM smart contracts, to build and deploy our smart contract. Install Truffle by running: Plain Text $ npm install —save truffle We can now create a barebones Truffle project by running the following command: Plain Text $ npx truffle init To check if everything works properly, run: Plain Text $ npx truffle test We now have Truffle successfully configured. Let us next install the OpenZeppelin contracts package. This package will give us access to the ERC-721 base implementation (the standard for digital tokens) as well as a few helpful additional functionalities. Plain Text $ npm install @openzeppelin/contracts To allow Truffle to use our MetaMask wallet, sign transactions, and pay gas on our behalf, we will require another package called hdwalletprovider. Install it by using the following command: Plain Text $ npm install @truffle/hdwallet-provider Finally, in order to keep our sensitive wallet information safe, we will use the dotenv package. Plain Text $ npm install dotenv Step 6: Create the Ticketing Smart Contract Open the project repository in a code editor (for example, VS Code). In the contracts folder, create a new file called Ticketing.sol. Our ticketing contract will inherit all functionality offered by the ERC721Enumerable implementation of OpenZeppelin. This includes transfers, metadata tracking, ownership data, etc. We will implement the following features from scratch: Public Primary Sale: Our contract will give its owner the power to sell tickets at a particular price. The owner will have the power to open and close sales, update ticket prices, and withdraw any money sent to the contract for ticket purchases. The public will have the opportunity to mint tickets at sale price whenever the sale is open and tickets are still in supply. Airdropping: The owner will be able to airdrop tickets to a list of wallet addresses. Reservation: The owner will also be able to reserve tickets for himself/herself without having to pay the public sale price. Add the following code to Ticketing.sol. Plain Text //SPDX-License-Identifier: MIT pragma solidity ^0.8.19; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol"; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; import "@openzeppelin/contracts/utils/Counters.sol"; import "@openzeppelin/contracts/utils/Base64.sol"; import "@openzeppelin/contracts/utils/Strings.sol"; contract Ticketing is ERC721, ERC721Enumerable, ERC721URIStorage, Ownable { using Counters for Counters.Counter; Counters.Counter private _tokenIds; // Total number of tickets available for the event uint public constant MAX_SUPPLY = 10000; // Number of tickets you can book at a time; prevents spamming uint public constant MAX_PER_MINT = 5; string public baseTokenURI; // Price of a single ticket uint public price = 0.05 ether; // Flag to turn sales on and off bool public saleIsActive = false; // Give collection a name and a ticker constructor() ERC721("My Tickets", "MNT") {} // Generate metadata function generateMetadata(uint tokenId) public pure returns (string memory) { string memory svg = string(abi.encodePacked( "<svg xmlns='http://www.w3.org/2000/svg' preserveAspectRatio='xMinyMin meet' viewBox='0 0 350 350'>", "<style>.base { fill: white; font-family: serif; font-size: 25px; }</style>", "<rect width='100%' height='100%' fill='red' />", "<text x='50%' y='40%' class='base' dominant-baseline='middle' text-anchor='middle'>", "<tspan y='50%' x='50%'>Ticket #", Strings.toString(tokenId), "</tspan></text></svg>" )); string memory json = Base64.encode( bytes( string( abi.encodePacked( '{"name": "Ticket #', Strings.toString(tokenId), '", "description": "A ticket that gives you access to a cool event!", "image": "data:image/svg+xml;base64,', Base64.encode(bytes(svg)), '", "attributes": [{"trait_type": "Type", "value": "Base Ticket"}]}' ) ) ) ); string memory metadata = string( abi.encodePacked("data:application/json;base64,", json) ); return metadata; } // Reserve tickets to creator wallet function reserveTickets(uint _count) public onlyOwner { uint nextId = _tokenIds.current(); require(nextId + _count < MAX_SUPPLY, "Not enough tickets left to reserve"); for (uint i = 0; i < _count; i++) { string memory metadata = generateMetadata(nextId + i); _mintSingleTicket(msg.sender, metadata); } } // Airdrop function airDropTickets(address[] calldata _wAddresses) public onlyOwner { uint nextId = _tokenIds.current(); uint count = _wAddresses.length; require(nextId + count < MAX_SUPPLY, "Not enough Tickets left to reserve"); for (uint i = 0; i < count; i++) { string memory metadata = generateMetadata(nextId + i); _mintSingleTicket(_wAddresses[i], metadata); } } // Set Sale state function setSaleState(bool _activeState) public onlyOwner { saleIsActive = _activeState; } // Allow public to mint tickets function mintTickets(uint _count) public payable { uint nextId = _tokenIds.current(); require(nextId + _count < MAX_SUPPLY, "Not enough tickets left!"); require(_count > 0 && _count <= MAX_PER_MINT, "Cannot mint specified number of tickets."); require(saleIsActive, "Sale is not currently active!"); require(msg.value >= price * _count, "Not enough ether to purchase tickets."); for (uint i = 0; i < _count; i++) { string memory metadata = generateMetadata(nextId + i); _mintSingleTicket(msg.sender, metadata); } } // Mint a single ticket function _mintSingleTicket(address _wAddress, string memory _tokenURI) private { // Sanity check for absolute worst case scenario require(totalSupply() == _tokenIds.current(), "Indexing has broken down!"); uint newTokenID = _tokenIds.current(); _safeMint(_wAddress, newTokenID); _setTokenURI(newTokenID, _tokenURI); _tokenIds.increment(); } // Update price function updatePrice(uint _newPrice) public onlyOwner { price = _newPrice; } // Withdraw ether function withdraw() public payable onlyOwner { uint balance = address(this).balance; require(balance > 0, "No ether left to withdraw"); (bool success, ) = (msg.sender).call{value: balance}(""); require(success, "Transfer failed."); } // Get tokens of an owner function tokensOfOwner(address _owner) external view returns (uint[] memory) { uint tokenCount = balanceOf(_owner); uint[] memory tokensId = new uint256[](tokenCount); for (uint i = 0; i < tokenCount; i++) { tokensId[i] = tokenOfOwnerByIndex(_owner, i); } return tokensId; } // The following functions are overrides required by Solidity. function _beforeTokenTransfer(address from, address to, uint256 tokenId, uint256 batchSize) internal override(ERC721, ERC721Enumerable) { super._beforeTokenTransfer(from, to, tokenId, batchSize); } function _burn(uint256 tokenId) internal override(ERC721, ERC721URIStorage) { super._burn(tokenId); } function tokenURI(uint256 tokenId) public view override(ERC721, ERC721URIStorage) returns (string memory) { return super.tokenURI(tokenId); } function supportsInterface(bytes4 interfaceId) public view override(ERC721, ERC721Enumerable) returns (bool) { return super.supportsInterface(interfaceId); } } Make sure the contract is compiling correctly by running: Plain Text npx truffle compile Our contract is pretty complex already, but it is possible to add some extra features as you see fit. For example, you can implement an anti-scalping mechanism within your contract. The steps to do so would be as follows: Define a Solidity mapping that acts as an allowlist for wallets that can hold more than one ticket. Create a function that allows the owner to add addresses to this allowlist. Introduce a check-in _beforeTokenTransfer that allows mint or transfer to a wallet already holding a ticket only if it is in the allowlist. Add the following snippet below the contract’s constructor: Plain Text mapping(address => bool) canMintMultiple; // Function that allowlists addresses to hold multiple Tickets. function addToAllowlist(address[] calldata _wAddresses) public onlyOwner { for (uint i = 0; i < _wAddresses.length; i++) { canMintMultiple[_wAddresses[i]] = true; } } Finally, modify the _beforeTokenTranfer function to the following: Plain Text // The following functions are overrides required by Solidity. function _beforeTokenTransfer(address from, address to, uint256 tokenId, uint256 batchSize) internal override(ERC721, ERC721Enumerable) { if (balanceOf(to) > 0) { require(to == owner() || canMintMultiple[to], "Not authorized to hold more than one ticket"); } super._beforeTokenTransfer(from, to, tokenId, batchSize); } Compile the contract once again using the Truffle command above. Step 7: Update Truffle Config and Create a .env File Create a new file in the project’s root directory called .env and add the following contents: Plain Text INFURA_API_KEY = "https://sepolia.infura.io/v3/<Your-API-Key>" MNEMONIC = "<Your-MetaMask-Secret-Recovery-Phrase>" Next, let’s add information about our wallet, the Infura RPC endpoint, and the Sepolia network to our Truffle config file. Replace the contents of truffle.config.js with the following: JavaScript require('dotenv').config(); const HDWalletProvider = require('@truffle/hdwallet-provider'); const { INFURA_API_KEY, MNEMONIC } = process.env; module.exports = { networks: { development: { host: "127.0.0.1", port: 8545, network_id: "*" }, sepolia: { provider: () => new HDWalletProvider(MNEMONIC, INFURA_API_KEY), network_id: '5', } } }; Step 8: Deploy the Smart Contract Let us now write a script to deploy our contract to the Sepolia blockchain. In the migrations folder, create a new file called 1_deploy_contract.js and add the following code: Plain Text // Get instance of the contract const ticketContract = artifacts.require("Ticketing"); module.exports = async function (deployer) { // Deploy the contract await deployer.deploy(ticketContract); const contract = await ticketContract.deployed(); // Mint 5 tickets await contract.reserveTickets(5); console.log("5 Tickets have been minted!") }; We’re all set! Deploy the contract by running the following command: Plain Text truffle migrate --network sepolia If all goes well, you should see an output (containing the contract address) that looks something like this: Plain Text Starting migrations... ====================== > Network name: 'sepolia' > Network id: 5 > Block gas limit: 30000000 (0x1c9c380) 1_deploy_contract.js ==================== Deploying 'Ticketing' ----------------------- > transaction hash: … > Blocks: 2 Seconds: 23 … > Saving artifacts ------------------------------------- > Total cost: 0.1201 ETH Summary ======= > Total deployments: 1 > Final cost: 0.1201 ETH You can search for your contract address on Sepolia etherscan and see it live. Congratulations! You’ve successfully deployed the contract to Sepolia. Step 9: Interface With the Smart Contract We have our smart contract! The next step is to deploy frontends that interface with the contract and allow anyone to call the mint function to make a donation and mint a ticket for themselves. For a fully functional ticketing service, you would typically need the following frontends: A website (with a great user experience) where public users can pay and mint their tickets. An admin portal where the owner can reserve and airdrop tickets, update pricing, transfer admin role to another wallet, withdraw sales revenue, open and close sale, etc. A tool that verifies that a person has a particular ticket both online and IRL. Building these systems from scratch is out of the scope of this tutorial, but we will leave you with a few resources and tips. If you verify your contract on Etherscan, it will automatically give you an admin portal where you can call any function on your contract. This is a good first step before you decide on building a custom solution. Verifying that a wallet has a ticket from your collection is extremely simple using the balanceOf function. If someone can prove that they own a wallet containing one of our tickets, it’s basically proof that they have a ticket. This can be achieved using digital signatures. Verification Using the Infura API One more hint: once you have your smart contract and front end (or even before your front end is complete and you want to prove that everything works), you can use the Infura API to verify that your new ticket exists. The Infura API is a quick way to replace a lot of code with a single API call. For example, the information we need to show ownership of our ticket is easily available to us through the API. All we need to supply is the wallet address. The code would look something like this: JavaScript const walletAddress = <your wallet address> const chainId = "1" const baseUrl = "https://nft.api.infura.io" const url = `${baseUrl}/networks/${chainId}/accounts/${walletAddress}/assets/nfts` // API request const config = { method: 'get', url: url, auth: { username: '<-- INFURA_API_KEY –>', password: '<-- INFURA_API_SECRET –>', } }; // API Request axios(config) .then(response => { console.log(response['data']) }) .catch(error => console.log('error', error)); Run it: Plain Text $ node <filename>.js And you should see something like this: Plain Text { total: 1, pageNumber: 1, pageSize: 100, network: 'ETHEREUM', account: <account address>, cursor: null, assets: [ { contract: <contract address>, tokenId: '0', supply: '1', type: 'ERC20', metadata: [Object] }, … ] } Conclusion In this tutorial, we deployed a fully functional ticketing service using Truffle, Infura, and the Infura API. It’s obviously not everything you would need to disrupt Ticketmaster—but it’s a solid start and a great proof of concept! Even if you don’t take this code and start your own ticketing platform, hopefully, you’ve learned a little about web3 in the process.

By Michael Bogan CORE

Container Security: Top 5 Best Practices for DevOps Engineers

Containerization has resulted in many businesses and organizations developing and deploying applications differently. A recent report by Gartner indicated that by 2022, more than 75% of global organizations would be running containerized applications in production, up from less than 30% in 2020. However, while containers come with many benefits, they certainly remain a source of cyberattack exposure if not appropriately secured. Previously, cybersecurity meant safeguarding a single "perimeter." By introducing new layers of complexity, containers have rendered this concept outdated. Containerized environments have many more abstraction levels, which necessitates using specific tools to interpret, monitor, and protect these new applications. What Is Container Security? Container security is using a set of tools and policies to protect containers from potential threats that will affect an application, infrastructure, system libraries, run time, and more. Container security involves implementing a secure environment for the container stack, which consists of the following: Container image Container engine Container runtime Registry Host Orchestrator Most software professionals automatically assume that Docker and Linux kernels are secure from malware, an easily overestimated assumption. Top 5 Container Security Best Practices 1. Host and OS Security Containers provide isolation from the host, although they both share kernel resources. Often overlooked, this aspect makes it more difficult but not impossible for an attacker to compromise the OS through a kernel exploit so they can gain root access to the host. Hosts that run your containers need to have their own set of security access in place by ensuring the underlying host operating system is up to date. For example, it is running the latest version of the container engine. Ideally, you will need to set up some monitoring to be alerted for any vulnerabilities on the host layer. Also, choose a "thin OS," which will speed up your application deployment and reduce the attack surface by removing unnecessary packages and keeping your OS as minimal as possible. Essentially, in a production environment, there is no need to let a human admin SSH to the host to apply any configuration changes. Instead, it would be best to manage all hosts through IaC with Ansible or Chef, for instance. This way, only the orchestrator can have ongoing access to run and stop containers. 2. Container Vulnerability Scans Regular vulnerability scans of your container or host should be carried out to detect and fix potential threats that hackers could use to access your infrastructure. Some container registries provide this kind of feature; when your image is pushed to the registry, it will automatically scan it for potential vulnerabilities. One way you can be proactive is to set up a vulnerability scan in your CI pipeline by adopting the "shift left" philosophy, which means you implement security early in your development cycle. Again, Trivy would be an excellent choice to achieve this. Suppose you were trying to set up this kind of scan to your on-premise nodes. In that case, Wazuh is a solid option that will log every event and verify them against multiple CVE (Common Vulnerabilities and Exposure) databases. 3. Container Registry Security Container registries provide a convenient and centralized way to store and distribute images. It is common to find organizations storing thousands of images in their registries. Since the registry is so important to the way a containerized environment works, it must be well protected. Therefore, investing time to monitor and prevent unauthorized access to your container registry is something you should consider. 4. Kubernetes Clusters Security Another action you can take is to re-enforce security around your container orchestration, such as preventing risks from over-privileged accounts or attacks over the network. Following the least-privileged access model, protecting pod-to-pod communications would limit the damage done by an attack. A tool that we would recommend in this case is Kube Hunter, which acts as a penetration testing tool. As such, it allows you to run a variety of tests on your Kubernetes cluster so you can start taking steps to improve security around it. You may also be interested in Kubescape, which is similar to Kube Hunter; it scans your Kubernetes cluster, YAML files, and HELM Charts to provide you with a risk score: 5. Secrets Security A container or Dockerfile should not contain any secrets. (certificate, passwords, tokens, API Keys, etc.) and still, we often see secrets hard-coded into the source code, images, or build process. Choosing a secret management solution will allow you to store secrets in a secure, centralized vault. Conclusion These are some of the proactive security measures you may take to protect your containerized environments. This is vital because Docker has only been around for a short period, which means its built-in management and security capabilities are still in their infancy. Thankfully, the good news is that achieving decent security in a containerized environment can be easily done with multiple tools, such as the ones we listed in the article.

By Florian Pialoux

mTLS Everywere

Security in one's information system has always been among the most critical non-functional requirements. Transport Layer Security, aka TLS and formerly SSL, is among its many pillars. In this post, I'll show how to configure TLS for the Apache APISIX API Gateway. TLS in a Few Words TLS offers several capabilities: Server authentication: The client is confident that the server it exchanges data with is the right one. It avoids sending data, which might be confidential, to the wrong actor. Optional client authentication: The other way around: the server only allows clients whose identities can be verified. Confidentiality: No third party can read the data exchanged between the client and the server. Integrity: No third party can tamper with the data. TLS works through certificates. A certificate is similar to an ID, proving the certificate's holder identity. Just like an ID, you need to trust who delivered it. Trust is established through a chain: if I trust Alice, who trusts Bob, who in turn trusts Charlie, who delivered the certificate, then I trust the latter. In this scenario, Alice is known as the root certificate authority. TLS authentication is based on public key cryptography. Alice generates a public key/private key pair and publishes the public key. If one encrypts data with the public key, only the private key that generated the public key can decrypt them. The other usage is for one to encrypt data with the private key and everybody with the public key to decrypt it, thus proving their identity. Finally, mutual TLS, aka mTLS, is the configuration of two-way TLS: server authentication to the client, as usual, but also the other way around, client authentication to the server. We now have enough understanding of the concepts to get our hands dirty. Generating Certificates With cert-manager A couple of root CA are installed in browsers by default. That's how we can browse HTTPS websites safely, trusting that is the site they pretend to be. The infrastructure has no pre-installed certificates, so we must start from scratch. We need at least one root certificate. In turn, it will generate all other certificates. While it's possible to do every manually, I'll rely on cert-manager in Kubernetes. As its name implies, cert-manager is a solution to manage certificates. Installing it with Helm is straightforward: Shell helm repo add jetstack https://charts.jetstack.io #1 helm install \ cert-manager jetstack/cert-manager \ --namespace cert-manager \ #2 --create-namespace \ #2 --version v1.11.0 \ --set installCRDs=true \ --set prometheus.enabled=false #3 Add the charts' repository. Install the objects in a dedicated namespace. Don't monitor; in the scope of this post. We can make sure that everything works as expected by looking at the pods: Shell kubectl get pods -n cert-manager Plain Text cert-manager-cainjector-7f694c4c58-fc9bk 1/1 Running 2 (2d1h ago) 7d cert-manager-cc4b776cf-8p2t8 1/1 Running 1 (2d1h ago) 7d cert-manager-webhook-7cd8c769bb-494tl 1/1 Running 1 (2d1h ago) 7d cert-manager can sign certificates from multiple sources: HashiCorp Vault, Let's Encrypt, etc. To keep things simple: We will generate our dedicated root certificate, i.e., Self-Signed. We won't handle certificates rotation. Let's start with the following: YAML apiVersion: cert-manager.io/v1 kind: ClusterIssuer #1 metadata: name: selfsigned-issuer spec: selfSigned: {} --- apiVersion: v1 kind: Namespace metadata: name: tls #2 --- apiVersion: cert-manager.io/v1 kind: Certificate #3 metadata: name: selfsigned-ca namespace: tls spec: isCA: true commonName: selfsigned-ca secretName: root-secret issuerRef: name: selfsigned-issuer kind: ClusterIssuer group: cert-manager.io --- apiVersion: cert-manager.io/v1 kind: Issuer #4 metadata: name: ca-issuer namespace: tls spec: ca: secretName: root-secret Certificate authority that generates certificates cluster-wide Create a namespace for our demo. Namespaced root certificate using the cluster-wide issuer. Only used to create a namespaced issuer. Namespaced issuer: Used to create all other certificates in the post. After applying the previous manifest, we should be able to see the single certificate that we created: Shell kubectl get certificate -n tls Plain Text NAME READY SECRET AGE selfsigned-ca True root-secret 7s The certificate infrastructure is ready; let's look at Apache APISIX. Quick Overview of a Sample Apache APISIX Architecture Apache APISIX is an API Gateway. By default, it stores its configuration in etcd, a distributed key-value store - the same one used by Kubernetes. Note that in real-world scenarios, we should set up etcd clustering to improve the resiliency of the solution. For this post, we will limit ourselves to a single etcd instance. Apache APISIX offers an admin API via HTTP endpoints. Finally, the gateway forwards calls from the client to an upstream. Here's an overview of the architecture and the required certificates: Let's start with the foundational bricks: etcd and Apache APISIX. We need two certificates: one for etcd, in the server role, and one for Apache APISIX, as the etcd client. Let's set up certificates from our namespaced issuer: YAML apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: etcd-server #1 namespace: tls spec: secretName: etcd-secret #2 isCA: false usages: - client auth #3 - server auth #3 dnsNames: - etcd #4 issuerRef: name: ca-issuer #5 kind: Issuer --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: apisix-client #6 namespace: tls spec: secretName: apisix-client-secret isCA: false usages: - client auth emailAddresses: - apisix@apache.org #7 issuerRef: name: ca-issuer #5 kind: Issuer Certificate for etcd Kubernetes Secret name, see below Usages for this certificate Kubernetes Service name, see below Reference the previously namespaced issuer created earlier Certificate for Apache APISIX as a client of etcd Mandatory attribute for clients After applying the above manifest, we can list the certificates in the tls namespace: Shell kubectl get certificates -n tls Plain Text NAME READY SECRET AGE selfsigned-ca True root-secret 8m59s //1 apisix-client True apisix-client-secret 8m22s //2 etcd-server True etcd-secret 8m54s //2 Previously created certificate Newly-created certificates signed by selfsigned-ca cert-manager's Certificates So far, we have created Certificate objects, but we didn't explain what they are. Indeed, they are simple Kubernetes CRDs provided by cert-manager. Under the cover, cert-manager creates a Kubernetes Secret from a Certificate. It manages the whole lifecycle, so deleting a Certificate deletes the bounded Secret. The secretName attribute in the above manifest sets the Secret name. Shell kubectl get secrets -n tls Plain Text NAME TYPE DATA AGE apisix-client-secret kubernetes.io/tls 3 35m etcd-secret kubernetes.io/tls 3 35m root-secret kubernetes.io/tls 3 35m Let's look at a Secret, e.g., apisix-client-secret: Shell kubectl describe apisix-client-secret -n tls Plain Text Name: apisix-client-secret Namespace: tls Labels: controller.cert-manager.io/fao=true Annotations: cert-manager.io/alt-names: cert-manager.io/certificate-name: apisix-client cert-manager.io/common-name: cert-manager.io/ip-sans: cert-manager.io/issuer-group: cert-manager.io/issuer-kind: Issuer cert-manager.io/issuer-name: ca-issuer cert-manager.io/uri-sans: Type: kubernetes.io/tls Data ==== ca.crt: 1099 bytes tls.crt: 1115 bytes tls.key: 1679 bytes A Secret created by a Certificate provides three attributes: tls.crt: The certificate itself tls.key: The private key ca.crt: The signing certificate in the certificate chain, i.e., root-secret/tls.crt Kubernetes encodes Secret content in base 64. To get any of the above in plain text, one should decode it, e.g.: Shell kubectl get secret etcd-secret -n tls -o jsonpath='{ .data.tls\.crt }' | base64 Plain Text -----BEGIN CERTIFICATE----- MIIDBjCCAe6gAwIBAgIQM3JUR8+R0vuUndjGK/aOgzANBgkqhkiG9w0BAQsFADAY MRYwFAYDVQQDEw1zZWxmc2lnbmVkLWNhMB4XDTIzMDMxNjEwMTYyN1oXDTIzMDYx NDEwMTYyN1owADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQpMj/0 giDVOjOosSRRKUwTzl1Wo2R9YYAeteOW3fuMiAd+XaBGmRO/+GWZQN1tyRQ3pITM ezBgogYAUUNcuqN/UAsgH/JM58niMjZdjRKn4+it94Nj1e24jFL4ts2snCn7FfKJ 3zRtY9tyS7Agw3tCwtXV68Xpmf3CsfhPmn3rGdWHXyYctzAZhqYfEswN3hxpJZxR YVeb55WgDoPo5npZo3+yYiMtoOimIprcmZ2Ye8Wai9S4QKDafUWlvU5GQ65VVLzH PEdOMwbWcwiLqwUv889TiKiC5cyAD6wJOuPRF0KKxxFnG+lHlg9J2S1i5sC3pqoc i0pEQ+atOOyLMMECAwEAAaNkMGIwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMBMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU2ZaAdEficKUWPFRjdsKSEX/l gbMwEgYDVR0RAQH/BAgwBoIEZXRjZDANBgkqhkiG9w0BAQsFAAOCAQEABcNvYTm8 ZJe3jUq6f872dpNVulb2UvloTpWxQ8jwXgcrhekSKU6pZ4p9IPwfauHLjceMFJLp t2eDi5fSQ1upeqXOofeyKSYjjyA/aVf1zMI8ReCCQtQuAVYyJWBlNLc3XMMecbcp JLGtd/OAZnKDeYYkUX7cJ2wN6Wl/wGLM2lxsqDhEHEZwvGL0DmsdHw7hzSjdVmxs 0Qgkh4jVbNUKdBok5U9Ivr3P1xDPaD/FqGFyM0ssVOCHxtPxhOUA/m3DSr6klfEF McOfudZE958bChOrJgVrUnY3inR0J335bGQ1luEp5tYwPgyD9dG4MQEDD3oLwp+l +NtTUqz8WVlMxQ== -----END CERTIFICATE----- Configuring mTLS Between etcd and APISIX With the certificates available, we can now configure mutual TLS between etcd and APISIX. Let's start with etcd: YAML apiVersion: v1 kind: Pod metadata: name: etcd namespace: tls labels: role: config spec: containers: - name: etcd image: bitnami/etcd:3.5.7 ports: - containerPort: 2379 env: - name: ETCD_TRUSTED_CA_FILE #1 value: /etc/ssl/private/ca.crt - name: ETCD_CERT_FILE #2 value: /etc/ssl/private/tls.crt - name: ETCD_KEY_FILE #3 value: /etc/ssl/private/tls.key - name: ETCD_ROOT_PASSWORD value: whatever - name: ETCD_CLIENT_CERT_AUTH #4 value: "true" - name: ETCD_LISTEN_CLIENT_URLS value: https://0.0.0.0:2379 volumeMounts: - name: ssl mountPath: /etc/ssl/private #5 volumes: - name: ssl secret: secretName: etcd-secret #5 Set the trusted CA Set the certificate Set the private key Require clients to pass their certificate, hence ensuring mutual authentication Mount the previously generated secret in the container for access Now, it's Apache APISIX's turn: YAML apiVersion: v1 kind: ConfigMap #1 metadata: name: apisix-config namespace: tls data: config.yaml: >- apisix: ssl: ssl_trusted_certificate: /etc/ssl/certs/ca.crt #2 deployment: etcd: host: - https://etcd:2379 tls: cert: /etc/ssl/certs/tls.crt #2 key: /etc/ssl/certs/tls.key #2 admin: allow_admin: - 0.0.0.0/0 https_admin: true #3 admin_api_mtls: admin_ssl_cert: /etc/ssl/private/tls.crt #3 admin_ssl_cert_key: /etc/ssl/private/tls.key #3 admin_ssl_ca_cert: /etc/ssl/private/ca.crt #3 --- apiVersion: v1 kind: Pod metadata: name: apisix namespace: tls labels: role: gateway spec: containers: - name: apisix image: apache/apisix:3.2.0-debian ports: - containerPort: 9443 #4 - containerPort: 9180 #5 volumeMounts: - name: config #1 mountPath: /usr/local/apisix/conf/config.yaml subPath: config.yaml - name: ssl #6 mountPath: /etc/ssl/private - name: etcd-client #7 mountPath: /etc/ssl/certs volumes: - name: config configMap: name: apisix-config - name: ssl #6,8 secret: secretName: apisix-server-secret - name: etcd-client #7,8 secret: secretName: apisix-client-secret Apache APISIX doesn't offer configuration via environment variables. We need to use a ConfigMap that mirrors the regular config.yaml file. Configure client authentication for etcd Configure server authentication for the Admin API Regular HTTPS port Admin HTTPS port Certificates for server authentication Certificates for client authentication Two sets of certificates are used: one for server authentication for the Admin API and regular HTTPS, and one for client authentication for etcd. At this point, we can apply the above manifests and see the two pods communicating. When connecting, Apache APISIX sends its apisix-client certificate via HTTPS. Because an authority signs the certificate that etcd trusts, it allows the connection. I've omitted the Service definition for brevity's sake, but you can check them in the associated GitHub repo. Plain Text NAME READY STATUS RESTARTS AGE apisix 1/1 Running 0 179m etcd 1/1 Running 0 179m Client Access Now that we've set up the basic infrastructure, we should test accessing it with a client. We will use our faithful curl, but any client that allows configuring certificates should work, e.g, httpie. The first step is to create a dedicated certificate-key pair for the client: YAML apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: curl-client namespace: tls spec: secretName: curl-secret isCA: false usages: - client auth emailAddresses: - curl@localhost.dev issuerRef: name: ca-issuer kind: Issuer curl requires a path to the certificate file instead of the content. We can go around this limitation through the magic of zsh: the =( ... ) syntax allows the creation of a temporary file. If you're using another shell, you'll need to find the equivalent syntax or download the files manually. Let's query the Admin API for all existing routes. This simple command allows checking that Apache APISIX is connected to etcd, and it can read its configuration from there. Shell curl --resolve 'admin:32180:127.0.0.1' https://admin:32180/apisix/admin/routes \ #1 --cert =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.crt }' | base64 -d) \ #2 --key =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.key }' | base64 -d) \ #2 --cacert =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.ca\.crt }' | base64 -d) \ #2 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' --resolve avoids polluting one's /etc/hosts file. curl will translate admin to localhost, but the query is sent to admin inside the Kubernetes cluster, thus using the correct Service. Get the required data inside the Secret, decode it, and use it as a temporary file. If everything works, and it should, the result should be the following: JSON {"total":0,"list":[]} No routes are available so far because we have yet to create any. TLS With Upstreams Last but not least, we should configure TLS for upstreams. In the following, I'll use a simple nginx instance that responds with static content. Use it as an illustration for more complex upstreams. The first step, as always, is to generate a dedicated Certificate for the upstream. I'll skip how to do it as we already created a few. I call it upstream-server and its Secret, unimaginatively, upstream-secret. We can now use the latter to secure nginx: YAML apiVersion: v1 kind: ConfigMap #1 metadata: name: nginx-config namespace: tls data: nginx.conf: >- events { worker_connections 1024; } http { server { listen 443 ssl; server_name upstream; ssl_certificate /etc/ssl/private/tls.crt; #2 ssl_certificate_key /etc/ssl/private/tls.key; #2 root /www/data; location / { index index.json; } } } --- apiVersion: v1 kind: Pod metadata: name: upstream namespace: tls labels: role: upstream spec: containers: - name: upstream image: nginx:1.23-alpine ports: - containerPort: 443 volumeMounts: - name: config mountPath: /etc/nginx/nginx.conf #1 subPath: nginx.conf - name: content mountPath: /www/data/index.json #3 subPath: index.json - name: ssl #2 mountPath: /etc/ssl/private volumes: - name: config configMap: name: nginx-config - name: ssl #2 secret: secretName: upstream-secret - name: content #3 configMap: name: nginx-content NGINX doesn't allow configuration via environment variables; we need to use the ConfigMap approach. Use the key-certificate pair created via the Certificate. Some static content unimportant in the scope of this post The next step is to create the route with the help of the Admin API. We prepared everything in the previous step; now we can use the API: Shell curl --resolve 'admin:32180:127.0.0.1' https://admin:32180/apisix/admin/routes/1 \ --cert =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.crt }' | base64 -d) \ #1 --key =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.key }' | base64 -d) \ #1 --cacert =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.ca\.crt }' | base64 -d) \ #1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d "{ \"uri\": \"/\", \"upstream\": { \"scheme\": \"https\", #2 \"nodes\": { \"upstream:443\": 1 }, \"tls\": { \"client_cert\": \"$(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.crt }' | base64 -d)\", #3 \"client_key\": \"$(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.key }' | base64 -d)\" #3 } } }" Client auth for Admin API, as above Use HTTPS for the upstream Configure key-certificate pair for the route. Apache APISIX stores the data in etcd and will use them when you call the route. Alternatively, you can keep the pair as a dedicated object and use the newly-created reference (just like for upstreams). It depends on how many routes the certificate needs. For more information, check the SSL endpoint. Finally, we can check it works as expected: Shell curl --resolve 'upstream:32443:127.0.0.1' https://upstream:32443/ \ --cert =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.crt }' | base64 -d) \ --key =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.tls\.key }' | base64 -d) \ --cacert =(kubectl get secret curl-secret -n tls -o jsonpath='{ .data.ca\.crt }' | base64 -d) And it does: JSON { "hello": "world" } Conclusion In this post, I've described a working Apache APISIX architecture and implemented mutual TLS between all the components: etcd and APISIX, client and APISIX, and finally, client and upstream. I hope it will help you to achieve the same. The complete source code for this post can be found on GitHub (linked above in the "Configuring mTLS Between etcd and APISIX" section). To Go Further: How to Easily Deploy Apache APISIX in Kubernetes cert-manager A Simple CA Setup with Kubernetes Cert Manager Mutual TLS Authentication

By Nicolas Fränkel CORE

GitHub Exposed a Private SSH Key: What You Need to Know

Secrets leakage is a growing problem affecting companies of all sizes, including GitHub. They recently made an announcement on their blog regarding an SSH private key exposure: [Last week, GitHub] discovered that GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository. The company reassured the public explaining that the key was only used to secure "Git operations over SSH using RSA," meaning that no internal systems, customer data, or secure TLS connections were at risk. They reacted immediately by detecting the incident and changing the key: "At approximately 05:00 UTC on March 24, out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com." The impact has therefore been limited both in time and in scope: "This change only impacts Git operations over SSH using RSA. If you are using ECDSA or Ed25519 encryption, then you are not affected.", according to them. This is further evidence that secrets sprawl is not just being driven by inexperienced developers or new teams. In our State of Secrets Sprawl 2023 report, we uncovered more than 10,000,000 new secrets that were pushed to public GitHub repos. This is a 67% increase in the number of secrets we detected over the previous year's report, while GitHub itself only saw a 27% increase in new accounts. The increase in detected hardcoded credentials is driven by many factors, but it is clear that the developers involved in the incidents range in seniority from novice to expert and from organizations of all maturity levels. From our report, we discovered that 1 in 10 committers exposed a secret in 2022. If you have exposed a secret publicly, you are certainly not alone. GitHub serves as a good reminder we must stay vigilant in our security practices, no matter how large our team. Let's take a look at what the risks are in this situation, how GitHub handled the remediation process, and some simple steps to avoid exposing your own private keys publicly. The Risks of Leaked Private SSH Keys Later in their post, GitHub said: "We [replaced our RSA SSH host key] to protect our users from any chance of an adversary impersonating GitHub or eavesdropping on their Git operations over SSH. This key does not grant access to GitHub’s infrastructure or customer data."While we can take comfort in this last part, no customer data is exposed. It is also good that there is no known risk of a takeover of their infrastructure, especially given how many developers and so much of the internet relies on it day to day. But there is a serious risk from "adversary impersonating GitHub or eavesdropping on their Git operations." This is what is referred to as a "man-in-the-middle attack," where the end user can not tell the difference between the legitimate other party and the attacker. With so many developers and services relying on GitHub SSH communications to be truly secure, it made a lot of sense for the company to revoke and replace their SSH key. In that same article, they also published what you need to do if you are affected and how to tell if you are affected. If you get a warning when connecting to GitHub via SSH, WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! you will need to remove the old key or manually update your ~/.ssh/known_hosts file.Your GitHub Actions might be affected as well. GitHub's rotation of their private SSH key will mean workflow runs will fail if they are using actions/checkout with the ssh-key option. This might feel familiar to CircleCI customers, who experienced a similar unexpected workflow interruption due to a leakage incident. Reactions and Risk from Mass Replacement As expected, the developer community has had many public reactions to the event. No one, it seems, is happy about the situation., but some people are helping spread the word without adding much commentary. Other conversations speculated on how this could have happened and further potential security issues that might come into play.One concern that popped up in several conversations was the potential for a new man-in-the-middle attack. Attackers know that keys will be replaced by many developers by using the command ssh-keygen -R github.com without manually verifying the new fingerprint is the expected value. It is entirely possible that a bad actor could insert their own fingerprint in certain situations. This is a great reminder that we should be embracing Zero Trust, moving away from 'trust, but verify' to a stance of 'verify, only then trust.' A Lesson in Incident Remediation While it is an unfortunate situation that GitHub has needed to rotate this certificate, affected so many customers, and put out such a notice, we want to highlight some best practices they used to respond to the event. While we don't know how long the secret was exposed, we can assume it was fairly recently.Acting quickly and deliberately, without panicking, is essential in secrets remediation. Given the timestamp they published, we can assume this incident caused a sleepless night for the team involved, and they had to weigh many factors. It seems they thought the security risks merited the key rotation, even if it would potentially affect a large swath of users.We can also applaud them for communicating very quickly and publicly. While most people might not be subscribed to the GitHub blog, they pushed the news into multiple channels as publicly as they could. While some in the community felt there was a little bit too much "marketing spin" when using terms like "we have no reason to believe" or "an abundance of caution," the GitHub team has been straightforward in their communications throughout all of their security incidents. We will take a little soft pedaling versus not getting an overview that includes remediation steps. How to Prevent Leaking a Credential Nobody is perfect, and we all make mistakes from time to time. Expecting humans always to deliver flawlessly only sets you up for disappointment, especially when dealing with something as conceptually as complex as Git. While we all love the world's favorite version control system, most developers can tell you it is a bit too easy to do something wrong, such as pushing to the wrong remote repository.While we don't know precisely what caused this particular incident, we want to use this opportunity to remind you of some best practices. Never Add Credentials to Version Control This one might seem obvious, but all of us touching code are sometimes guilty of this. There are times, especially when debugging something when you just need to test a credential works. This is true of passwords, API keys, and, relevant to this, certificates. You might add a new cert directly in the project with the full intention of moving it someplace safe or modifying your .gitignore file, but then life happens, and you get distracted. One git add -A and git commit later, your cert is now in your git history. One 'git push' later, and it is now out in a shared repo. This is where tools like git hooks and ggshield can really come in handy. Setting up a pre-commit hook is very quick and simple. Once set up, every attempt at committing code will trigger a scan that will halt the operation if a secret is discovered in any of the tracked files. Catching a secret before it becomes part of your git history is the safest and cheapest place to remediate the situation. Double Check That Is the Right Remote One of the strengths of Git is the ability to easily push all your changes to any remote repository you have permission to connect. Unfortunately, this can get confusing rather quickly. Imagine you have two repos, one public and one private, with remote names proj-1-p and proj-1-pr respectively. You are only one letter away from potentially pushing to the wrong place. Accidents happen. It is a very good idea to make those origin names more explicit. Another factor a lot of developers deal with is their own shell aliases. For example, it is common to alias gpo as a shortcut for the often typed git push origin. It can be very easy to go into automatic mode and use a shortcut that might send the wrong branch to the wrong place. When in doubt, type it out. Rotate Secrets Often While rotating your SSH key might not be necessary for this event, do you know when the last time was that you rotated it? Was it this decade? If you don't know, then right now is a good time to go remedy that. The longer any valid credential lives, the more opportunities exist for that credential to be found and misused. We have found that teams that rotate keys more often are at the top of the pyramid, expert level when it comes to secret management maturity. Going through the exercise of rotating credentials regularly when there is no emergency will prepare you to better handle times when there are those added pressures. Stay Vigilant and Safe Leaks happen to us all sometimes, even to massive platforms like GitHub. While there likely are many workflows that have been affected and many developers who need to update their known_hosts files, thanks to GitHub's clear communication on the incident, there is a clear remediation path, and we know the overall scope of the incident. This is a good time to reflect on your own secrets management and detection strategy as well.Stay safe out there; we are all on the internet together.

By Dwayne McDaniel

Attaining Document Security in FileNet Content Management System

FileNet is a document management system developed by IBM that allows organizations to manage and store their digital content. Document Security is an essential aspect of any document management system, including FileNet. Important Considerations for FileNet Security 1. Authentication: FileNet provides various authentication mechanisms, such as LDAP, Kerberos, and Active Directory, to ensure that allows only authorized users can access the system. 2. Authorization: FileNet allows administrators to define roles and permissions to control access to resources within the system. This ensures that users can only access the resources they need to do their job. 3. Encryption: FileNet provides encryption capabilities to protect data at rest and in transit. This ensures that data is secure from unauthorized access or interception. 4. Auditing: FileNet logs all activities performed by users within the system, allowing administrators to monitor user activity and detect any potential security breaches. 5. Patching and updates: FileNet releases regular software updates and patches to address any security vulnerabilities or bugs in the system often. The FileNet system must be kept up-to-date with the latest patches and updates to maintain the security of the system. 6. FileNet marking sets are used to apply markings or classifications to documents or other content stored in the FileNet system. Marking sets provide a way to label content with metadata that describes the content, such as its sensitivity or classification level. Key Aspects of FileNet Marking Sets a. Marking Set Structure: Marking sets are defined as a hierarchical structure of markings, with each marking representing a specific classification level or attribute of the content. For example, a marking set might have markings for "confidential," "restricted," and "public" content. b. Marking set Attributes: Markings in a marking set can have attributes that describe the marking, such as its display name, abbreviation, and color. These attributes can be used to customize the display of markings in the FileNet system and make them easier to identify. c. Security: Markings can also be used to control access to content in the FileNet system. Overall, FileNet marking sets provide a way to classify and label content in the FileNet system, which can help with organization, searchability, and security. 7. FileNet Security Inheritance is a feature that allows security settings to be inherited by child objects from their parent objects. This feature simplifies security administration and ensures consistency across objects that have a similar security model. Key Aspects of FileNet Security Inheritance a. Inheritance Hierarchy: In FileNet, objects are organized in a hierarchy of parent-child relationships. For example, a folder can be the parent of a document or another folder. When a security model is defined on a parent object, its child objects inherit the same security settings by default. b. Inheritance Overrides: In some cases, it might be necessary to override the security settings that are inherited from a parent object. For example, a document in a folder might need to have different permissions than the folder itself. FileNet provides a way to override inherited security settings for individual child objects without affecting the security settings of other child objects. Overall, FileNet Security Inheritance simplifies document security administration and ensures consistency across all document objects that have a similar security model. It is important to understand the FileNet inheritance hierarchy, performance considerations, and override options to ensure that security settings are configured correctly for each object in the FileNet system. Overall, FileNet provides robust security features to protect your digital content. However, it is important to follow best practices and ensure that the system is configured correctly to ensure maximum security to the FileNet.

By Ravikiran Kandepu

Enhancing Threat Intelligence and Cybersecurity With IP Geolocation

In the face of mounting cybercrime risks, enterprises and institutions are progressively leveraging IP geolocation as an efficacious instrument for detecting and alleviating internet-based menaces. IP geolocation involves the identification of a device or user's geographical location through their IP address. This advanced technology empowers organizations to track and oversee online activities, recognize looming threats, and proactively thwart potential cyberattacks. Understanding IP Geolocation in Cybersecurity IP geolocation data unveils the whereabouts of network traffic and devices, affording organizations the ability to promptly detect potential threats and take suitable actions. Through meticulous analysis of IP geolocation data, organizations can effectively detect dubious activity, such as connections from unexpected locations, and swiftly impede or isolate them from causing any damage. Additionally, IP geolocation serves as a valuable tool in detecting and responding to intricate threats like advanced persistent threats (APTs) and botnets. By scrutinizing IP geolocation data over an extended period, organizations can determine recurrent behavior patterns and consequently pinpoint potential malevolent activity. It is crucial to remember that IP geolocation should not be viewed as the panacea for threat intelligence but rather as a single instrument within a larger array of technologies, such as intrusion detection systems and security information and event management (SIEM) systems. Benefits of IP Geolocation in Cybersecurity It has been observed that approximately 60% of these establishments shut down their operations within half a year of experiencing a cyber assault. However, utilizing IP geolocation can aid in curbing such incidents, thereby reducing the rate of a business closure. So, how can IP geolocation be useful in cybersecurity? Here are some of the key benefits: Identifying Potential Threats One of the key applications of IP geolocation in the realm of cybersecurity is the identification of possible threats. The analysis of the geographical origin of incoming traffic permits a rapid determination of suspicious locations. For instance, suppose that you are a business headquartered in the United States, and you observe traffic emanating from an IP address located in Russia. In that case, it might be prudent to undertake a thorough investigation to guarantee the legitimacy of such traffic. Blocking Malicious Traffic The implementation of IP geolocation affords the advantage of intercepting harmful traffic. By leveraging the power of IP geolocation, one can effectively obstruct traffic originating from specific regions, thereby mitigating the probability of malicious attacks. To illustrate, a company that solely conducts business within the borders of the United States could utilize IP geolocation to bar access from foreign nations, thereby curbing the incidence of potential cyber threats. Improved Fraud Detection IP geolocation can aid in detecting fraud by cross-referencing a user's location with their billing details. For instance, a mismatch between a billing address in the United States and an IP address in Europe could signal fraudulent activity. Compliance With Regulations Ultimately, IP geolocation can prove to be a valuable tool for adhering to regulatory requirements. Numerous countries like China, Canada, Australia, Brazil, and more have implemented stringent data privacy regulations mandating businesses to store data within specific geographical locations. By leveraging IP geolocation, enterprises can verify that they are storing their data adhering to these laws and avoid potential legal and financial consequences. Use Cases of IP Geolocation in Cybersecurity IP geolocation is a powerful tool in the fight against cyber threats. Here are some of the use cases of IP geolocation in cybersecurity: Network Security By harnessing the power of IP geolocation, one can accurately pinpoint the geographic coordinates of network-connected devices, thereby enabling the detection of unwarranted access and uncovering potential cyber threats that loom on the horizon. Endpoint Security The technique of IP geolocation can enable the tracking of endpoint locations, encompassing laptops, smartphones, and tablets. This valuable information facilitates vigilant surveillance by security teams and enables the timely detection of possible security incidents. Cloud Security By leveraging IP geolocation, security teams can effectively monitor cloud-based resources, including servers and applications, by identifying their geographical location. This enables them to verify that the resources are being accessed solely from authorized locations, bolstering the security posture of the organization's cloud infrastructure. Threat Intelligence The discerning employment of IP geolocation empowers the acquisition of critical intelligence on potential cyber threats. By methodically scrutinizing the precise locations of IP addresses linked with malevolent activities, security teams can effectively unearth the origins of cyber attacks and undertake pre-emptive measures to safeguard their systems. Future of IP Geolocation and Cybersecurity As we witness the ever-advancing frontiers of technology, the future of IP geolocation and cybersecurity stands to be equally impacted. Revolutionary technologies, including the Internet of Things (IoT), blockchain, and machine learning, are positioned to bring sweeping transformations to handling these crucial facets of online security. Particularly, machine learning and artificial intelligence (AI) offer immense potential in the realm of cybersecurity. These cutting-edge innovations can process and scrutinize colossal data sets at lightning-fast speeds, identifying abnormalities and warning signs of possible security breaches with unmatched efficiency. In doing so, they empower organizations to stay a step ahead of cybercriminals, safeguarding their most sensitive information from malicious actors. The intricately woven network of interconnected devices that is the Internet of Things (IoT) has brought forth a multitude of opportunities and challenges for IP geolocation and cybersecurity. While it enables more comprehensive monitoring of network traffic and possible threats, it also expands the attack surface and necessitates the implementation of robust security measures. New technologies bring great potential for IP geolocation and cybersecurity improvement but also entail challenges. Compliance with privacy regulations and ensuring reliable data are crucial. To stay protected from increasingly sophisticated cyber threats, organizations must keep up with technology and implement strong security measures. Final Thoughts According to the Cybersecurity and Infrastructure Security Agency, 14 out of the 16 critical infrastructure sectors in the United States were subject to ransomware incidents. Therefore, using IP geolocation in threat intelligence and cybersecurity is a vital tool in identifying potential cyber threats and improving overall security. As technology continues to evolve and cybercrime becomes more sophisticated, the accuracy and reliability of IP geolocation data will become increasingly important. As a result, organizations should continue to prioritize cybersecurity best practices and consider incorporating IP geolocation data into their security frameworks and tools. As we look to the future, it is clear that IP geolocation will play a significant role in protecting against cyber threats and maintaining a secure online environment.

By Michael Chukwube

Security

DZone's Featured Security Resources

Top Security Experts

The Latest Security Topics