Cheatsheet: Difference between revisions
Content deleted Content added
Line 276: | Line 276: | ||
</center> |
</center> |
||
=HTTP Request Methods= |
= HTTP Request Methods= |
||
GET: Retrieve Data |
GET: Retrieve Data |
||
HEAD: Header only without Response Body |
HEAD: Header only without Response Body |
||
Line 285: | Line 285: | ||
OPTIONS: Returns the HTTP methods that the server supports for the specified URL |
OPTIONS: Returns the HTTP methods that the server supports for the specified URL |
||
TRACE: Performs a message loop back test to see what (if any) changes or additions have been made by intermediate servers |
TRACE: Performs a message loop back test to see what (if any) changes or additions have been made by intermediate servers |
||
PATCH: |
|||
= SSL Handshake = |
= SSL Handshake = |
Revision as of 00:00, 20 August 2019
ARP vs MAC Table
ARP Table | MAC Table (or CAM Table) |
---|---|
Layer3 address to Layer2 address resolution | Layer2 address to Interface binding |
Matches IP addresses to MAC addresses | Maps Ports to MAC addresses |
Needed to forward packets at layer 3 | Used to Switch frames to the right output interface |
Kept by L3 devices | Kept only by L2 devices |
No entry for dest IP address, machine will send ARP request | If no entry, switch will flood the frame |
Default timeout is 4 hours | Default timeout is 5 minutes |
Filled by each ARP reply | Filled by source MAC of each frame passing through switch |
Fragmentation
- Before fragmentation
Sequence | Identifier | Total Length | DF Flag | MF Flag | Fragment offset |
---|---|---|---|---|---|
0 | 345 | 5140 | 0 | 0 | 0 |
- After fragmentation
Sequence | Identifier | Total Length | DF Flag | MF Flag | Fragment offset |
---|---|---|---|---|---|
0-0 | 345 | 1500 | 0 | 1 | 0 |
0-1 | 345 | 1500 | 0 | 1 | 185 |
0-2 | 345 | 1500 | 0 | 1 | 370 |
0-3 | 345 | 700 | 0 | 0 | 555 |
Headers
Version | HLEN | DSCP | ECN | Total Length | |||||||||||||||||||||||||||
Identification | Flags(DF,MF) | Fragment Offset | |||||||||||||||||||||||||||||
Time To Live | Protocol | Header Checksum | |||||||||||||||||||||||||||||
Source IP Address | |||||||||||||||||||||||||||||||
Destination IP Address | |||||||||||||||||||||||||||||||
Options (if HLEN > 5) |
Source port | Destination port | ||||||||||||||||||||||||||||||
Sequence number | |||||||||||||||||||||||||||||||
Acknowledgment number (if ACK set) | |||||||||||||||||||||||||||||||
Data offset | Reserved 0 0 0 |
N S |
C W R |
E C E |
U R G |
A C K |
P S H |
R S T |
S Y N |
F I N |
Window Size | ||||||||||||||||||||
Checksum | Urgent pointer (if URG set) | ||||||||||||||||||||||||||||||
Options (if data offset > 5. Padded at the end with "0" bytes if necessary.) ... |
Source port | Destination port |
Length | Checksum |
- ARP Header
Hardware type Protocol type Hardware address length Protocol address length Operation Source MAC Source IP Dest MAC Dest IP
- ICMP Header
Code Checksum Rest of Header
TCP
- Parameters determined during Handshake:
MSS WSF SACK Permitted
- MTU vs MSS
- Congestion Control
- Slow Start - Exponential Increase
- Sender starts with cwnd = 1 MSS, Size increases 1 MSS each time one Ack arrives, Increases the rate exponentially(1,2,4,8....) until a threshold is reached
- Congestion Avoidance - Additive Increase
- Increases the cwnd Additively, When a “window” is Ack cwnd is increased by 1, Window = No of segments transmitted during RTT - The increase is based on RTT, not on the number of arrived ACKs, Congestion window increases additively until congestion is detected
- Congestion Detection - Multiplicative Decrease
- If congestion occurs, Window size must be decreased, Sender knows about congestion via RTO or 3 Dup Acks received, Size of Threshold is dropped to half
- Tahoe
- If RTO occured, TCP Reacts Strongly - Reduces cwnd back to 1 Segment, starts the slow start phase again
- Reno
- If 3 Duplicate ACKs are received, TCP has a Weaker Reaction - Starts the Congestion Avoidance phase - This is called fast transmission and fast recovery
- Silly Window Syndrome: Sender creates data slowly or Receiver consumes slowly or both.
Syndrome due to Sender:
- Nagle’s Algorithm: Send data initially, accumulate data in output buffer, Wait for Ack or till 1 MSS Data in Buffer
Syndrome due to Receiver:
- Clark’s Solution: Announce window size 0 till 1) enough space for 1 MSS in Buffer or Half Receive buffer is empty - Delayed Acknowledgment: Segment not acknowledged immediately, Sender TCP does not slide its window, reduces traffic, sender may unnecessarily retransmit, Not delay more than 500 ms.
- Fast Retransmission
- If RTO has a larger value - If sender receives four acknowledgments with same value (three duplicates) - Segment expected by all of these Ack is resent immediately
- Persistence Timer
- Issue of Deadlock created by Lost Ack, used to reset Window size 0 advertized earlier, is resolved by this timer - Sending TCP sends a special segment(1 byte of new data) called Probe, causes the receiving TCP to resend Ack - If no reply, another probe is sent and value of persistence timer is doubled and reset - Sender continues sending probes, doubling, resetting value of persistence timer until it reaches a threshold(generally 60s) - After that the sender sends one probe segment every 60s until the window is reopened
VPN Messages
- Phase 1 - Main Mode
Cookie,Proposal List Cookie,Accepted Proposal DH Key,Nonce DH Key,Nonce ID,ID Hash ID,ID Hash
- Phase 1 - Aggressive Mode
ID,Proposal List,DH Key,Nonce ID,Accepted Proposal,DH Key,Nonce,ID Hash ID Hash
- Phase 2 - Quick Mode
Ph1 Hash,Message ID,Proposal List,Nonce, DH Key,Proxy-ID Ph1 Hash,Message ID,Accepted Proposal,Nonce,DH Key,Proxy-ID Ph1 Hash,Message ID,Nonce
HTTP Error Codes
Category | Type | Code |
---|---|---|
1XX | Informational | 100 = Continue |
2XX | Successful | 200 = OK 201 = Created (URL) 202 = Accepted (request accepted but not acted upon immediately) 203 = Non-authoritative Information(info in header is from local or third-party copy, not from original server) 204 = No Content (in body) |
3XX | Re-directional | 301 = Moved Permanently 302 = Found (temporary redirect) 304 = Not Modified 305 = Use Proxy (URL must be accessed through the proxy mentioned in the Location header) 307 = Temporary Redirect (requested page has moved temporarily to a new url) |
4XX | Client Error | 400 = Bad Request 401 = Unauthorized 402 = Payment Required 403 = Forbidden 404 = Not Found 405 = Method Not Allowed |
5XX | Server Error | 500 = Internal Server Error 501 = Not Implememted 502 = Bad Gateway or Proxy 503 = Service Unavailable 504 = Gateway or Proxy Timeout 505 = HTTP Version Not Supported |
HTTP Request Methods
GET: Retrieve Data HEAD: Header only without Response Body POST: Submits Data to DB, web forum, etc PUT: Replaces target resource with the uploaded content DELETE: Removes target resource given by URI CONNECT: Used when the client wants to establish a transparent connection to a remote host, usually to facilitate SSL-encrypted communication (HTTPS) through an HTTP proxy OPTIONS: Returns the HTTP methods that the server supports for the specified URL TRACE: Performs a message loop back test to see what (if any) changes or additions have been made by intermediate servers PATCH:
SSL Handshake
NetScaler
- LB Methods:
Least Connection = Service with fewest active connections Round Robin = Rotates a list of services Least Response time(LRTM) = Fewest active connections & lowest average response time Least Bandwidth = Service serving least amount of traffic measured in mbps Least Packets = Service that received fewest packets Source IP Hash = Destination IP Hash =
- Persistence Methods:
SOURCE IP = COOKIE Insert = Connections having same HTTP Cookie inserted by Set-Cookie directive from server belong to same persistence session. SSL Session = Connections having same SSL session ID RULE = All connection matching a user defined rule URL Passive = requests having same server ID(Hexadecimal of Server IP & Port) of service to which request is to be fwded Dest IP = SRC IP DST IP = CALL ID = Same Caller ID in SIP Header
- What is Stateful & Stateless Persistence? Which one is more scalable/Efficient?
Stateless Session Persistence: Cookie inserted by ADC is more efficient because no need to create a table, NS will insert cookie & forget, with reply, it will read cookie value, decrypt it & fwd request. State-full Session Persistence: Server will insert cookie, NS will hash it & fwd based on Hash value but will need to keep a table in memory with all hashes & IP Addresses. Same is true for Source IP based Persistence, Also inefficient behind NAT Using Set-cookie-header = by Server - insert Name & Value Fields Client sends cookie in Cookie Header Who ever generates cookie, will be able to read it
OSPF
- States
Down Attempt Init 2-Way ExStart Exchange Loading Full
- LSA Type
Type 1 - Router LSAs Type 2 - Network LSAs Type 3 - Network Summary LSA Type 4 - ASBR summary LSA Type 5 - AS external LSA Type 7 - NSSA External LSA
- Packet Types
Type 1 - Hello Type 2 - Database Description (DBD) Type 3 - Link-State request (LSR) Type 4 - LSU Type 5 - LSAck
- Neighbor Requirements
Same area Aame authentication config Same subnet Same hello/dead interval Matching stub flags
BGP
- Route Selection Criteria
Attribute | Which is better |
---|---|
Next Hop reachable | Route cannot be used if next hop is unreachable |
Weight | Bigger |
Local Preference | Bigger |
Locally Injected | Locally injected is better than iBGP/eBGP learned |
AS Path Length | Smaller |
Origin | Prefer I over E & E over Unknown |
MED | Smaller |
Neighbor Type | Prefer eBGP over iBGP |
IGP Metric to Next Hop | Smaller |
- BGP States
Idle Active Attempting to connect Connect TCP session established OpenSent Open message sent OpenConfirm Response received Established Adjacency established
- BGP Messages
Open Update Keepalive Sent every 60 seconds Notification Always indicate something is wrong
VPN Monitor vs DPD vs IKE Heartbeat
VPN Monitor | DPD | IKE Heartbeat |
---|---|---|
Juniper Proprietary | RFC Standard | Juniper Proprietary |
Work with Non Juniper | Work with Non Juniper | Cannot work with Non Juniper |
Uses ICMP | Uses ICMP(encrypted IKE Phase 1 message(R-U-THERE)) | -- |
Goes inside the Phase 2 Tunnel | Goes through Phase 1 Tunnel | -- |
Implies VPN is UP | Implies peer is up and responding | Enhancement to detect tunnel availability |
Works if supported by one peer only | -- | Both ends must support |
Configured in Phase 2 | Configured in Phase 1 | Configured in Phase 1 |
SRX Architecture
- First Path
Screens Static NAT | Dest NAT Route ==> Forwarding Lookup Zones Policy Reverse Static NAT | Source NAT Service ALG Session
- Fast Path
Screens TCP NAT Service ALG
ScreenOS
- ScreenOS Flow order
Sanity Check Screening Session lookup Route Lookup Policy lookup Session creation ARP lookup
- Route preference order
Policy Based Routing Source Interface Based Routing Source Routing Destination Routing
- NAT Preference order
Mapped IP Virtual IP Policy Based NAT (NAT-Src & NAT-Dst) Interface Based NAT
SYN Flood Protection
Threshold = Proxy connections above this limit If Syn-cookie is enabled, no sessions established between client & firewall or firewall & server directly Alarm Threshold = Alarm/Alert (to log) Queue Size = The number of proxied connections held in queue After this the firewall starts rejecting new connection requests Timeout Value is maximum time before a half-completed connection is dropped from the queue The range is 0–50s; default is 20s