Skip to main content

Posts

Elasticsearch - Auditbeat

Depending upon your platform find the setup file below: https://www.elastic.co/downloads/beats/auditbeat Unzip the file, rename it to Auditbeat and copy the unzipped folder to C:\Program Files as below: Auditbeat 2. Open Powershell with Administrator privileges, and type the following: In case of code execution restriction, please check my post here . Once the installation is successful, modify the C:\Program Files\Auditbeat\auditbeat.yml file to establish the connection with Elastic Cloud tenant we created above. Scroll down and un-comment: "cloud-id" to enter the following: cloud.id: " Deployment:Cloud ID " cloud.auth: "username:<password>" I have masked the Cloud ID and password details for my deployment (Deployment-1) Enter the following commands in Powershell to load Kibana dashboards. The setup is ready.. Check on Kibana if the Windows Audit logs are getting populated in Kibana. The logs can be found by clicking on the compass icon in

Elasticsearch : Windows Event Logs : Winlogbeat

My first foray into the Security SIEM seems is going to be with the prodigal ELK stack. Keeping the discussion later, w.r.t. the pros, cons and features of ELK, let's dive into our first implementation (integration of Windows Server with ELK) For testing purpose, I have created a 14 day free trial that ELK offers. Go to https://elastic.co Select Try Free Scroll down to find ElasticSearch and Click Launch on Elastic Cloud. It should ask for email details which needs to be verified. Create a Deployment. My deployment details are as below: Elasticsearch Deployment Click on the deployment to check the Cloud ID . Save this somewhere as this will be very crucial to direct traffic from endpoints to this Cloud Tenant Now, once the Cloud tenant is ready, let us install Winlogbeat on our Windows server to send Windows event logs to Kibana (ELK's GUI) Winlogbeat installation Download Winlogbeat from https://www.elastic.co/products/beats/winlogbeat Extract the contents of the zip file to

OSPF Options Field

OSPF Options Field DN = Down bit : used in MPLS Layer 3 VPNs. If a route learnt from a customer network via OSPF is advertised across a BGP / MPLS VPN using Multiprotocol BGP, and is advertised back to a customer network via OSPF, there is a possibility of a loop to occur in which the OSPF route is redistributed back to the VPN service provider network via BGP. The DN bit prevents this type of routing loop. O = The “O” bit is set when the originating router supports Type 9,10 and 11 opaque LSAs. Not used in normal OSPF implementations DC = The “DC” bit is set when the originating router supports OSPF over Demand Circuits. Not used in normal OSPF implementations L = Indicates whether the OSPF packet contains a LLS (Link-Local signalling) data block. This bit is set only in Hello and DBD packets. N = The N bit is used only in Hello packets. The N bit is set when the originating router supports Type-7 NSSA-External-LSAs. Neighboring routers with mismatched N bit value will not form

BGP Communities

BGP communities are optional transitive attributes They are used mainly to associate an administrative tag to a BGP route In spite of the communities being transitive, Cisco IOS routers do not pass them across the BGP sessions by default. The feature needs to be activated using the command “neighbor send-community” To display the community in the structured notation, you need to enter the global configuration command “ip bgp-community new-format” In order to set a community value, use the route-map command “ set community etc” or to add the community value on the existing community values use “set community additive ” The routes with communities assigned to them can be matched using “community-list” and which can then be referenced in a route-map later. There are two types of community lists : standard and extended. For eg. ip community-list 1 permit 101:1 101:2 ip community list 1 deny no-export Std community list NO-ADVERTISE community attribute: The well-known NO_ADVERTISE

BGP Best Path Selection Algorithm

Check if the next-hop is reachable. If yes, then proceed The path which has the highest WEIGHT The path which has the highest LOCAL_PREF The path which has been locally originated via a “network” or “aggregate” BGP command or through redistribution from an IGP The path which has the shortest AS_PATH The path which has the lowest origin type The path which has the lowest MED EBGP is preferred over IBGP Prefer the path which has lowest IGP metric to the BGP next hop Determine if multiple paths require installation in the routing table for “BGP multipath” In case both the paths are external, prefer the path which was received first (the oldest one) Prefer the route which comes from the BGP router with the lowest router ID If the originator or router ID is the same for multiple paths, prefer the path which has minimum cluster list length. (This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be awa

BGP Attributes

BGP attributes are broadly divided into two parts: Well Known attributes Optional attributes Well-known attributes : "MUST" be recognized by all BGP implementations Optional attributes : May or may not be supported by the BGP implementations Transitive attributes : BGP process has to accept the path in which it is included and should pass it on to other peers even if these attributes are not supported. Meaning if any optional attribute is not recognized by a BGP implementation, then BGP looks to check if the transitive flag is set. If the transitive flag is set then BGP implementation should accept the attribute and advertise it to its other BGP Peers. Non-transitive attributes : If the BGP process does not recognize the attribute then it can ignore the update and not advertise the path to its peers. If the transitive flag is not set then BGP implementation can quietly ignore the attribute, it does not have to accept and advertise this attribute to its other peers. Well kno

EIGRP K-values

The ultimate variables that decide whether a particular metric component should contribute towards EIGRP metric calculation or not are the EIGRP K-values. There are 5 in all, K1 to K5 with K1 (in conjunction with Bandwidth) and K3 (in conjunction with Delay) used primarily for EIGRP metric calculation. The K-values are not interface specific but router specific, meaning, the same set of K-values would be applicable to all the interfaces of a particular EIGRP router. Of course, changes can be done under "router eigrp ASN" command and not under interface. The command "show ip protocols" would display the current K-values. show ip protocols (EIGRP K-values) Let us now modify the K-values.. EIGRP metric weights The excerpt shows that the moment K values are modified, the EIGRP adjacency goes down due to the mismatch of K-values with the neighboring router. The changes are reflected again by using the command : show ip protocols