FOR DUMPS SAKE

General notes
Subscribe to posts

Export Putty Sessions

posted 13 Aug 2019, 08:56 by Donald Ross   [ updated 13 Aug 2019, 08:57 ]

Run CMD as administrator
regedit /e "%USERPROFILE%\Desktop\putty-sessions.reg" HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions

Slitaz Linux

posted 13 Aug 2019, 08:56 by Donald Ross   [ updated 13 Aug 2019, 08:57 ]

**Notes
default
# /etc/httpd.conf: Busybox HTTP web server configuration file.

###
/etc/init.d/httpd stop

tazpkg get-install lighttpd

nano /etc/lighttpd/lighttpd.conf
$SERVER["socket"] == ":443" {
  ssl.engine = "enable" 
  ssl.pemfile = "/etc/ssl/certs/lighttpd.pem" 
}

cd /etc/ssl/certs
openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 365 -nodes
chmod 400 lighttpd.pem

Nagios Log Server

posted 2 Jan 2019, 04:27 by Donald Ross   [ updated 2 Jan 2019, 04:49 ]

#Download and install the ova
https://www.nagios.com/downloads/nagios-log-server/vmware/

#Initial setup
https://assets.nagios.com/downloads/nagios-log-server/docs/Installing-Nagios-Log-Server-with-VMware-Workstation-Player.pdf 

#Run this command if there is an issue with DHCP allocation
/etc/sysconfig/network-scripts/ifup-eth eth0

#make things easy
yum install nano

#Set static IP
nano /etc/sysconfig/network-scripts/ifcfg-eth0

So when you open up that file, you'll want to change:

BOOTPROTO=dhcp
To:
BOOTPROTO=static
Now you'll need to add the entries to set not only the IP address, but the netmask, gateway, and DNS addresses. At the bottom of that file, add the following:
IPADDR=192.168.1.200
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=1.0.0.1
DNS2=1.1.1.1
DNS3=8.8.4.4







VPN phases

posted 16 Sept 2016, 14:18 by Donald Ross   [ updated 16 Sept 2016, 14:39 ]

Phase 1 is IKE where you start things out...  Diffie-Hellman is used to set up your negotiation and setup of your traffic-encryption keys to get started.  Your IKE SA will be completed here.
 
Phase 2 is IPSec (ISAKMP) where you get into what specifics you set up in your policies to have your keys set.  This is the traffic keys themselves.  And the traffic is getting encrypted here.  IPSec SA is present if everything goes well.


IKE Phase 1 works in one of two modes, main mode or aggressive mode now of course both of these modes operate differently and we will cover both of these modes.

Main Mode:
IKE Phase 1 operating in main mode works with both parties exchanging a total of 6 packets, that’s right 6 packets is all it takes to complete phase 1.

The first packet is sent from the initiator of the IPSec tunnel to its remote endpoint, this packet contains the ISAKMP policy
The second packet is sent from the remote endpoint back to the initiator, this packet will be the exact same information matching the ISAKMP policy sent by the initiator.
The third packet is sent from the initiator to the remote endpoint, this packet contains the Key Exchange payload and the Nonce payload, the purpose of this packet is generate the information for the DH secret key
This fourth packet as you would expect comes from the remote endpoint back to initiator and contains the remote endpoints Key Exchange and Nonce payload.
The fifth packet is from the initiator back to the remote endpoint with identity and hash payloads, the identity payload has the device’s IP Address in, and the hash payload is a combination of keys (including a PSK, if PSK authentication is used)
The sixth packet from the remote endpoint to the initiator contains the corresponding hash payloads to verify the exchange.

Aggressive Mode:
IKE Phase 1 operating in aggressive mode only exchanges 3 packets compared to the 6 packets used in main mode. One downside in aggressive is the fact it not as secure as main mode.

The first packet from the initiator contains enough information for the remote endpoint to generate its DH secret, so this one packet is equivalent to the first four packets in main mode.
The second packet from the remote endpoint back to the initiator contains its DH secret
The third packet from the initiator includes identity and hash payloads. After the remote endpoint receives this packet it simply calculates its hash payload and verifies it matches, if it matches then phase one is established.

IKE Phase 2

Now let’s look at IKE Phase 2, IKE Phase 2 occurs after phase 1 and is also known as quick mode and this process is only 3 packets.

Perfect Forward Secrecy PFS, if PFS is configured on both endpoints the will generate a new DH key for phase 2/quick mode.
Contained in this first packet from the initiator to the remote device are some of the hashes/keys negotiated from phase 1, along with some IPSec parameters IE: Encapsulation (ESP or AH), HMAC, DH-group, and the mode (tunnel or transport)
The second packet contains the remote endpoint’s response with matching IPSec parameters.
The last packet is sent to the remote device to verify the other device is still there and is an active peer.
That last packet concludes the forming an IPSec tunnel and the phase 1/2 process.

TCP DUMP

posted 2 Jul 2016, 07:16 by DR Labs

See the list of interfaces on which tcpdump can listen:

tcpdump -D
Listen on interface eth0:

tcpdump -i eth0
Listen on any available interface 
tcpdump -i any
Be verbose while capturing packets:

tcpdump -v
Be more verbose while capturing packets:

tcpdump -vv
Be very verbose while capturing packets:

tcpdump -vvv
Be verbose and print the data of each packet in both hex and ASCII, excluding the link level header:

tcpdump -v -X
Be verbose and print the data of each packet in both hex and ASCII, also including the link level header:

tcpdump -v -XX
Be less verbose (than the default) while capturing packets:

tcpdump -q
Limit the capture to 100 packets:

tcpdump -c 100
Record the packet capture to a file called capture.cap:

tcpdump -w capture.cap
Record the packet capture to a file called capture.cap but display on-screen how many packets have been captured in real-time:

tcpdump -v -w capture.cap
Display the packets of a file called capture.cap:

tcpdump -r capture.cap
Display the packets using maximum detail of a file called capture.cap:

tcpdump -vvv -r capture.cap
Display IP addresses and port numbers instead of domain and service names when capturing packets (note: on some systems you need to specify -nn to display port numbers):

tcpdump -n
Capture any packets where the destination host is 172.16.1.1. Display IP addresses and port numbers:

tcpdump -n dst host 172.16.1.1
Capture any packets where the source host is 172.16.1.1. Display IP addresses and port numbers:

tcpdump -n src host 172.16.1.1
Capture any packets where the source or destination host is 172.16.1.1. Display IP addresses and port numbers:

tcpdump -n host 172.16.1.1
Capture any packets where the destination network is 172.16.1.0/24. Display IP addresses and port numbers:

tcpdump -n dst net 172.16.1.0/24
Capture any packets where the source network is 172.16.1.0/24. Display IP addresses and port numbers:

tcpdump -n src net 172.16.1.0/24
Capture any packets where the source or destination network is 172.16.1.0/24. Display IP addresses and port numbers:

tcpdump -n net 172.16.1.0/24
Capture any packets where the destination port is 23. Display IP addresses and port numbers:

tcpdump -n dst port 23
Capture any packets where the destination port is is between 1 and 1023 inclusive. Display IP addresses and port numbers:

tcpdump -n dst portrange 1-1023
Capture only TCP packets where the destination port is is between 1 and 1023 inclusive. Display IP addresses and port numbers:

tcpdump -n tcp dst portrange 1-1023
Capture only UDP packets where the destination port is is between 1 and 1023 inclusive. Display IP addresses and port numbers:

tcpdump -n udp dst portrange 1-1023
Capture any packets with destination IP 172.16.1.1 and destination port 23. Display IP addresses and port numbers:

tcpdump -n "dst host 172.16.1.1 and dst port 23"
Capture any packets with destination IP 172.16.1.1 and destination port 80 or 443. Display IP addresses and port numbers:

tcpdump -n "dst host 172.16.1.1 and (dst port 80 or dst port 443)"
Capture any ICMP packets:

tcpdump -v icmp
Capture any ARP packets:

tcpdump -v arp
Capture either ICMP or ARP packets:

tcpdump -v "icmp or arp"
Capture any packets that are broadcast or multicast:

tcpdump -n "broadcast or multicast"
Capture 500 bytes of data for each packet rather than the default of 68 bytes:

tcpdump -s 500
Capture all bytes of data within the packet:

tcpdump -s 0

OSPF notes

posted 12 Apr 2016, 13:34 by DR Labs   [ updated 20 Jun 2016, 03:54 by Donald Ross ]

OSPF open shortest path first  (link state protocol)

OSPF network types
P2P
Broadcast
non-broadcast
Point to Multi Point
Virtual links

Neighbour formation
Network command 
Interface command
Passive command

Example configuration -
Router OSPF 1
network 10.0.0.0 0.255.255.255 (wildcard)
network 50.1.1.1 0.0.0.0 area 0 (interface only)
network 0.0.0.0 255.255.255.255 area 0 (any)


OSPF states

Init - hello's  (nothing coming back) This state specifies that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet. When a router receives a hello packet from a neighbor, it should list the sender's router ID in its hello packet as an acknowledgement that it received a valid hello packet.

2 way - (see hello's coming back)  This state designates that bi-directional communication has been established between two routers. Bi-directional means that each router has seen the other's hello packet.

Exstart - (negoiate exchange information) Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR.

Exchange - (exchanging information)  OSPF routers exchange database descriptor (DBD) packets. Database descriptors contain link-state advertisement (LSA) headers only and describe the contents of the entire link-state database.

Loading - the actual exchange of link state information occurs. Based on the information provided by the DBDs, routers send link-state request packets.

Full -  In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the routers' databases are fully synchronized.


BDR
DROTHER


Passive interface default - no interface will send OSPF hello's


Packet Types
hello
adjacencies
LSA
Link state database
flooding
SPF
Route table 

type 1 - hello
type 2 - DBD (databse description)
type 3 - LSR (link state request
type 4 - LSU (ink state update)
type 5 - LSAck (Link state ACK)

Overview of OSPF LSA Types

We know that Link State Advertisements (LSA) are the life blood of an OSPF network. The flooding of these updates (and the requests for this information) allow the OSPF network to create a map of the network. This of course occurs with a little help from Dijkstra’s Shortest Path First Algorithm. But not all OSPF LSA’s are created equal. 

The Router (Type 1) LSA
We begin with what many call the “fundamental” or “building block” Link State Advertisement. The Type 1 LSA (also known as the Router LSA) is flooded within an area. It describes the interfaces of the local router that are participating in OSPF and the neighbors the local OSPF speaker has established.

The Network (Type 2) LSA
Do you remember how OSPF functions on an Ethernet (broadcast) segment? It elects a Designated Router (DR) and Backup Designated Router (BDR) in order to reduce the number of adjacencies that must be formed and the chaos that would result from a full mesh of these relationships. Well, the Type 2 LSA is sent by the Designated Router into the local area. This LSA describes all of the routers that are attached to that Ethernet segment.

The Summary (Type 3) LSA
Ready for a big difference with this LSA type? Recall that your Type 1 and Type 2 LSAs are sent within an area. We call these intra-area LSAs. Now it is time for the first of our inter-area LSAs. The Summary (Type 3) LSA is used for advertising prefixes learned from the Type 1 and Type 2 LSAs into a different area. Do you recall what device would send such an LSA? Sure, it would be the Area Border Router that separates areas.
So let’s say we have an area design like this – AREA 1-AREA 0-AREA 2. The Area 1 ABR would send the Type 3 LSAs into Area 0. It’s ABR into Area 2 would send these Type 3 LSAs into that area to provide full reachability in the OSPF domain. The Type 3 LSAs remain Type 3 LSAs during this journey, it is just OSPF costs and advertising router details that change in the advertisements. Notice also that in this example we are describing a multi area OSPF design that is not using any special area types like Stub or Totally Stubby.

The ASBR Summary (Type4) LSA
Do you recall the very special OSPF router that brings in routes from another domain (like an EIGRP domain)? It is the Autonomous System Boundary Router. In order to inform routers in different areas about the existence of this special router, the Type 4 LSA is used. This Summary LSA provides the router ID of the ASBR. So once again, the Area Border Router is responsible for shooting this information into the next area and we have another example of an inter-area LSA.

The External (Type 5) LSA
So the ASBR is the device that is brining in prefixes from other routing domains. The Type 4 LSA describes this device. But what LSA is used for the actual prefixes that are coming in from the other domain? Yes, you guessed it, it is the Type 5 LSA. The OSPF ASBR creates these LSAs and they are sent to the Area Border Routers for dissemination into the other areas. Remember, this might change if we are using special area types.

The NSSA External (Type 7) LSA
Remember that in OPSF there is a VERY special area type called a Not So Stubby Area. This area can act stub, but it can also bring in external prefixes from an ASBR. You guessed it, these prefixes are sent as Type 7 LSAs. When an ABR gets these Type 7 LSAs, it sends them alone in to the other areas as a Type 5 LSA. So the Type 7 designation is just for that very special NSSA area functionality.

OSPF LSA Types and Areas
  • Router (Type 1)
  • Network (Type 2)
  • Summary (Type 3)
  • ASBR Summary (Type 4)
  • External (Type 5)
  • NSSA External (Type 7)

If you are even slightly fuzzy on what these different LSAs are used for in OSPF, please quickly go over that previous post.

The purpose of this post if for us to discuss how these LSAs will be impacted by a multi area area design, especially one that might include special areas. What is wonderful about this exercise is the fact that it allows us to review what these special areas are for, and gives us a richer understand of exactly how they function. Of course, this is from the automatic filtering of certain LSAs from certain areas.

OSPF LSAs and Standard Areas

Think about an area 0.0.0.1 attached to the backbone area of 0.0.0.0. There are Type 1 LSAs flooding in this area 0.0.0.1. If we have broadcast segments, we also have Type 2 LSAs circulating in the area. The Area Border Router is sending LSA Type 3s into the backbone to summarize the prefix information in area 0.0.0.1. It is also taking in this information from the backbone for other areas that might exist. If there is an ASBR out there in the domain somewhere, our area 0.0.0.1 will receive Type 4 and Type 5 LSAs in order to know the location of this ASBR and the prefixes it is sharing with us. Whew! That is a lot going on. This is precisely why we have the special area types!

OSPF LSAs and the Stub Area

What is it that we want to accomplish with a stub area? We do not want to hear about those prefixes that are external to our OSPF domain. Remember what those were? Sure, they are the Type 5 LSAs. In fact, we do not even want to hear about those Type 4 LSAs that are used to call out the ASBR in the network. So the stub area is chock full of Type 1, Type 2, and Type 3 LSAs. In fact, how would this area get to one of those external prefixes it is needed to? We typically use a very special Type 3 LSA for this. This LSA represents the default route (0.0.0.0/0). It is this handy little route that allow devices in this area to get to all of those externals, in fact, to get to any prefix not specifically defined in the Routing Information Base.

OSPF LSAs and the Totally Stubby Area

Ok, with this area we want very little inside it right? Sure. So it makes sense that we are blocking those Type 4 and Type 5 once again, but now we are even blocking the Type 3 LSAs that are describing prefix information from other areas WITHIN our OSPF domain. There needs to be one big exception, however. We need a Type 3 LSA for a default route so we can actually get to other prefixes in our out of our domain.

OSPF LSAs and the Not So Stubby Area and the Totally Not So Stubby Area

Remember, the Not So Stubby Area needs to have those Type 7 LSAs. These Type 7 permit the proliferation of those external prefixes that are entering your OSPF domain thanks to this NSSA area you created. Obviously this area also has the Type 1, Type 2, and Type 3 inside it. Type 4 and Type 5 will be blocked from entering this area as you would expect. In both Juniper and Cisco environments, you can also create a Totally Not So Stubby Area by restricting Type 3s from this area.


BGP notes

posted 11 Apr 2016, 14:10 by DR Labs

TCP 179

Best Path Selection  

N WLLA OMNI

N = next hop reachability
W = weight, bigger is better  (Local router)
L = local preference, bigger is better  (AS / non transitive) 
L = locally injected preferred over BGP learned  (network / aggregate )
A = AS path length, shorter is better 
O = origin, (igp is better than egp is better than incomplete)  I IGP - E Exterior Gateway Protocol (EGP), ? INCOMPLETE.
M = MED, lower is better  (route suggestion)
N = neighbor type, ebgp better than ibgp (Prefer eBGP over iBGP paths)
I = IGP metric to BGP next-hop, lower is better
-Closest IGP neighbor
-Oldest learned (external)
-Lowest Cluster / Router ID
-Lowest neighbour Address





MP BGP

posted 11 Apr 2016, 14:10 by DR Labs   [ updated 11 Apr 2016, 14:36 ]

***WORK IN PROGRESS***

Multiprotocol Extensions for BGP (MBGP), sometimes referred to as Multiprotocol BGP or Multicast BGP and defined in IETF RFC 4760, is an extension to Border Gateway Protocol (BGP) that allows different types of addresses (known as address families) to be distributed in parallel. Whereas standard BGP supports only IPv4 unicast addresses, Multiprotocol BGP supports IPv4 and IPv6 addresses and it supports unicast and multicast variants of each. Multiprotocol BGP allows information about the topology of IP multicast-capable routers to be exchanged separately from the topology of normal IPv4 unicast routers. 

Multiprotocol BGP is also widely deployed in case of MPLS L3 VPN



Enable by configuring - Address family vpnv4

vpnv4 routes (VPN label)

Extended Communities 

neighbour 1.1.1.1 send-communities extended 

VRF name

Route Distinguisher 1.1.1.1:2 (keeps networks separate in MPBGP) local significant 

VRF (VRF PICTURE)
Route Targets
Export Target 10:10 ( out of the VRF into MPBGP )
Import Target 9:9 (out MPBGP into the VRF ) (how the routes should be shared with) 


router bgp 65020


LSP - Label Switching Path (each router applies its own label based upon its own routing table) 

Spanning Tree Notes

posted 11 Apr 2016, 13:22 by DR Labs   [ updated 11 Apr 2016, 13:29 ]

***WORK IN PROGRESS***

SPANNING TREE EXAMPLE PICTURE

Original Spanning Tree  - 802. 1d
PASSIVE (convergence 50 sec + )
*Blocking - 0-26 sec
*Listening - 15 sec
*Learning - 15 sec


Rapid Spanning Tree - 802. 1w RSTP
ACTIVE  (convergence 2 sec )


Per Vlan Rapid Spanning Tree  PVSTP
ACTIVE  
1 instance per vlan (can be different topology per vlan)

Multiple Spanning Tree MSTP
ACTIVE  
cut down on spanning tree instances

Region 
Matching Name
Matching Revision No
Matching Mapping e.g. instance 0 - catch all (internal spanning tree)  instance 1 - vlan 11 to 20 instance 2 - vlan 21 to 30

*Rules

1. Root bridge election
2. Best path to the root
 2a. lowest cost
 2b. lowest ID
 3c. lowest port number (advertising switch)

*no more than 7 in the chain*

BPDU - bridge protocol data unit

every 2 seconds 
Root and Loop detection 
Multicast Address 01:80:c2:00:00:00
Bridge MAC + Bridge Priority = Bridge ID
Find best path to the root using cost


DP designated port (one per segment)

RP root port
*AP alternate port (backup to RP)
BP blocked port

Bridge Assurance -  disables ports if BPDU is NOT seen

LoopGuard - RP/AP can't become DP
RootGuard - apply on switch port to another LAN
BPDU Guard - disables ports if BPDU is seen
PortFast - disables spanning tree
BPDU filter -


MAC flap ????




Handy Software

posted 17 Mar 2016, 14:05 by DR Labs   [ updated 10 Apr 2016, 00:06 ]

**Veeam Endpoint Backup**

Veeam® Endpoint Backup™ FREE provides a simple solution for backing up Windows-based desktops and laptops. With Veeam Endpoint Backup FREE, you can easily back up your PC to an external hard drive, NAS (network-attached storage) share or a Veeam Backup & Replication™ repository. And if your system crashes, hard drive fails, or a file gets corrupted or accidentally deleted, you can recover what you need in minutes — like it never even happened.

https://www.veeam.com/endpoint-backup-free.html

**Ninite**

Install and Update All Your Programs at Once!

Ninite will start working as soon as you run it
  • not bother you with any choices or options
  • install apps in their default location
  • say no to toolbars or extra junk
  • install 64-bit apps on 64-bit machines
  • install apps in your PC's language or one you choose
  • do all its work in the background
  • install the latest stable version of an app
  • skip up-to-date apps
  • skip any reboot requests from installers
  • use your proxy settings from Internet Explorer
  • download apps from each publisher's official site
  • verify digital signatures or hashes before running anything
  • work best if you turn off any web filters or firewalls
  • save you a lot of time!
https://ninite.com/


1-10 of 11