Google

From Network Security Wiki

Topics

Stream Topics % Done
Networking OSI layers 100%
TCP, IP, UDP, ICMP, ARP, DHCP, NAT, FTP 100%
HTTP, SSL 100%
Caching, Cookies, Certificates Caching, Cookies,
DNS Done
SMTP
Latency, Tail Latency
BGP, OSPF Done
Load Balancing
Linux Shell scripting
Kernel, libraries, system calls Done
Memory Management
Permissions, file systems Done
Linux Commands Brushup Done
Programming Python Brushup
Algorithms
HTML, CSS
Databases, SQL, Indexing
Google Technical Quesitions
Behavioral Questions
Leadership Questions
Designing Medium sized Campus Design
Cheatsheet Done

Preparations

  • 1st round
  • 1st Week Dec starting
  • Video interview
coding
tech 
communication
thinking
  • 1 Hour:
1st Troubleshooting code
Distributes system
Web & Network technologies
  • F2F - Bangalore office
2 tech Networking/General Web troubleshooting
1 manager
  • Share use cases
  • Working with Code (15 min)
  • What is code, Issue & How to improve it.
  • Ask question about question
  • Break it down
  • No IDE
  • No library

Topics 2

  • Semaphores
  • Mutex
  • Threads
A process is a collection of code, memory, data and other resources. 
A thread is a sequence of code that is executed within the scope of the process. 
You can (usually) have multiple threads executing concurrently within the same process.

Questions

  • What are alternative solutions of Spanning tree?
Port Isolation
Vlan Isolation
Loopback Detection
  • Tail Latency
200ms latency -> initial rto by most OSs
Do not consider normal Retransmissions, but only RTOs
exponential backoff rto will double with each iteration -> 400ms, 800ms, 1000ms
congestion, pathmtu not honored, icmp rate-limited, reply pathmtud-reply packets dropped,
os issues -> Zero window -> cpu high(response slow), memory high, disk issue
  • 4k video file edit latency
RTP uses tcp, n/w level issues, check latency on which side traces,


Networking Followup

Moving of files BW APAC & EMEA

1 MBPS speed? whats wrong
  • Take Packet Captures
  • Check Duplex settings
In half duplex mode, both devices can transmit the signal, but one at a time. In full duplex mode, both devices can transmit the signal at the same time.
  • Multiple streams
Use locust or run multiple instances of iperf
  • Pearing
  • Latency
  • Congestion
  • QoS, Filtering, Routing, ISP issues
  • TCP Window size
WSF
  • Maximum Possible Transfer Rate = TCP Window Size/RTT
Where RTT is Ping Response in Millseconds/1000.
There are only two things you can do to affect your data thru-put on a wide area network:
  Increase your TCP window size, or
  Reduce latency.
  • Packet capture
Check for retransmissions after 200 ms --> RTOs
  • Large send offload (LSO) is a technique for increasing egress throughput of high-bandwidth network connections by reducing CPU overhead.
It works by passing a multipacket buffer to the network interface card (NIC). 
The NIC then splits this buffer into separate packets. 
The technique is also called TCP Segmentation Offload (TSO) when applied to TCP, or generic segmentation offload (GSO).
A similar concept to large segment offload for ingress traffic is large receive offload (LRO). 
LSO and LRO are independent and use of one does not require the use of the other.
  • Fragmentation
  • Packet Loss
  • Network throughput impacted by TCP window size, Latency and Congestion
  • Window Size
Maximum amount of data a sender can send before receiving an acknowledgement. 
Standard TCP Window Size = 65K bytes
  • It’s not just about latency, TCP doesn’t like congestion
Adding more traffic produces a negative marginal effect above about 30% utilization
  • Application is able to generate 10 GBPS traffic? OS limits - CPU - Memory, Network Card speed?
  • Window scaling changes the TCP window to:
64KB * 2n (n = window scale factor)

With a window scale factor of 7, which equals a TCP window of 8MB

Single-flow throughput is limited to:
TCP window size / RTT

Without window scaling, TCP is limited to:
64KB / 100ms = 5 Mbps

With CloudBridge default window scale, TCP is limited to:
8MB / 100 ms = 650 Mbps


  • WSF 64kB to 8MB
  • SACK to minimize data that is resent
  • Fast re-transmits to reduce delay before resend


Bandwidth Delay Product
Amount of data that can be in transit (flight) in the network
Bandwidth-delay product is the product of a data link's capacity (in bits per second) and its round-trip delay time (in seconds).
The result data is equivalent to the maximum amount of data on the network circuit at any given time, Or data that has been transmitted but not yet acknowledged.
A network with a large bandwidth-delay product is commonly known as a Long Fat Network(LFN). 
A network is considered an LFN if its bandwidth-delay product is significantly larger than 105 bits (12,500 bytes).
BIC TCP (Binary Increase Congestion control)
  • BIC TCP for faster recovery from packet loss
Allows bandwidth probing to be more aggressive initially when the difference from the current window size to the target window size is large, and become less aggressive as the current window size gets closer to the target window size.
A unique feature of the protocol is that its increase function is logarithmic; it reduces its increase rate as the window size gets closer to the saturation point.
  • BIC is optimized for high speed networks with high latency: so-called "long fat networks".
  • For these networks, BIC has significant advantage over previous congestion control schemes in correcting for severely underutilized bandwidth.
  • BIC implements a unique congestion window (cwnd) algorithm.
  • This algorithm tries to find the maximum cwnd by searching in three parts: binary search increase, additive increase, and slow start.
  • When a network failure occurs, the BIC uses multiplicative decrease in correcting the cwnd.
  • BIC TCP is implemented and used by default in Linux kernels 2.6.8 and above.
  • The default implementation was again changed to CUBIC TCP in the 2.6.19 version.
CUBIC TCP
  • CUBIC is an implementation of TCP with an optimized congestion control algorithm for high bandwidth networks with high latency (LFN: long fat networks).
  • CUBIC TCP is implemented and used by default in Linux kernels 2.6.19 and above, as well as Windows 10 & Windows Servers.
  • It is a less aggressive and more systematic derivative of BIC TCP, in which the window size is a cubic function of time since the last congestion event, with the inflection point set to the window size prior to the event.
  • Because it is a cubic function, there are two components to window growth.
  • The first is a concave portion where the window size quickly ramps up to the size before the last congestion event.
  • Next is the convex growth where CUBIC probes for more bandwidth, slowly at first then very rapidly.
  • CUBIC spends a lot of time at a plateau between the concave and convex growth region which allows the network to stabilize before CUBIC begins looking for more bandwidth.
  • Another major difference between CUBIC and standard TCP flavors is that it does not rely on the cadence of RTTs to increase the window size.
  • CUBIC's window size is dependent only on the last congestion event.
  • With standard TCP, flows with very short round-trip delay times (RTTs) will receive ACKs faster and therefore have their congestion windows grow faster than other flows with longer RTTs.
  • CUBIC allows for more fairness between flows since the window growth is independent of RTT.

SSH to remote server

GCP VM SSH Connection Timed out

Existing connection timed out or a new one? 

Was it idle connection?
It not, is there any network disconnection/lantency/congestion?

SSH Packets are reaching Destination? TCPDump on Destination(look for initial TCP packets with the SYN flags). 
If not check:
  - Using IP Correct in client side.
  - DNS Correct? try host file entry or direct ip access
  - Port Correct 
  - Routes in intermediate devices.
  - Packets going out of Client? check dest trace. Iptables might hv blocked, or networking issue.
  - Traceroute
  - Do Ping & check ICMP Traffic reaching

If yes check:
  - Reply packets going or not? if going, check Router reverse routes.
  - IPTables Rejecting packets (Flush IPTabeles -F)
  - Packets received on correct interface? (SSH might be listening on wrong interface/address - ListenAddress )
  - SSH to Server from localhost

Any traffic reaching Server? ifconfig RX, TX count bytes increasing.
If not check:
  - Networking Config
  - Interface check? correct ip on correct interface?
  - Host Level Networking in GCP/VMWare

If Yes check:
  - Firewall blocking traffic for port 22?
  - Firewall blocking all external traffic?
  - Host Level Firewall dropping SSH traffic?
  - Do Ping & check ICMP Traffic reaching


SSH Config File
/etc/ssh/sshd_config      # sshd server configuration file
Port 22
ListenAddress 0.0.0.0
PermitRootLogin prohibit-password
PubkeyAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no
KerberosAuthentication no
UsePAM yes
Banner none
TCPKeepAlive yes

/etc/ssh/sshd_config      # ssh client configuration file
Restart SSHD
sudo systemctl restart sshd.service
sudo systemctl status sshd.service
sudo service sshd status
Wrong IP
ssh: connect to host 192.168.1.51 port 22: No route to host
Wrong Port OR SSH Not installed (TCP Reset is sent)
ssh: connect to host 192.168.1.50 port 2222: Connection refused
SSH Running on correct port
netstat -anp | grep ssh       ==> Check port no of SSHD program in LISTEN State
Netstat
netstat -ant | grep 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
Check Service logs
journalctl -xe


Intermittent Timedout/Slow connection
top - Memory, CPU, IO CPU, etc
Network Congestion, Broadcast Storm
Duplicate IPs configured in same LAN, check ARP table repeatedly
Debug SSH Connection
ssh -vvv user@host
Error if Ciphers does not match
Unable to negotiate with 192.168.126.100 port 22: no matching cipher found.
SSH Version 2? v1 is not in use now a days

Check: 

telnet 192.168.1.50 22
Trying 192.168.1.50...
Connected to 192.168.1.50.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1

Else use SSH Debug: 

ssh -vvv user@server.com

System Design

  • Past system design you have done
              {XEN SERVER 1}                                                                  {XEN SERVER2}
[Asterisk]---[CB]---[Slax Router]---[WanEM]---------------[Phy Switch]--------------------[CB]---[Slax Router2]---[Phone1]
                                                                                                        \_________[Phone2]
                                                                                                         \________[Phone3]
  • Trade off you made in this?
Used VMs only
Could have used Physical devices - Cisco Call Manager, Physical CBs, Cisco Routers, IPNetSim, IP Phones
Used devices across 2 DCs in India & US.
  • Scaling this specific network
  • 3-tier network design in public cloud. How do you design?
Front End Application
Backend Application
Database

You need LoadBalancer
  • Will you need LB? Why?

How can you establish secure connectivity to public cloud

  • VPN tunnel
  • How do you ensure High Availability for this?
  • Webmin
  • VNC? Encryption? Not by default, can be run inside SSH Tunnel; port 5900, 5901
  • RDP? Encryption? Yes can be encrypted, port 3389
  • TeamViewer
  • Dataplicity
  • SSH Username-Password
Password authentication is used by users.
Username and password combination that you use to login to your SFTP server. 
When you try to log in, the server checks whether your username and password are both correct and if so, approves your request.

Pros: 

Convenience for users.
Easily remembered
if web login is possible, browsers can auto-fill these fields
Everyone knows how to log in using passwords.
Administrators can increase security by creating policies such as:
 - lock system after 5 retries
 - Requiring a certain amount of capitalized letters, numbers, and symbols in the password
 - Forcing users to reset their passwords periodically

Cons: 

Human nature for people to create passwords that are easily remembered. 
Simple passwords make these accounts extremely susceptible to intrusion.
If these simple passwords are used across multiple apps, the potential for a breach increases massively.
Usernames and passwords have to be directly transmitted to the server being logged into, thus making this method more prone to hacking.
You can mistakenly log into the wrong server or website, and now that server or website has your password. 
Hackers love making clones of popular websites to scam users out of their login credentials.
Companies could store your password in clear text in their database. 
Their system administrators can see your password at any time, and if hackers breaks in, they can see your password as well. 
Even if the password is salted and hashed, a hacker could steal all the passwords, brute force the salt and hash, and see if you used that same password for other apps and websites.
Employees may get frustrated by password policies set by IT administrators to increase security.


  • SSH Key based
Keys are used as the default method of authentication for SFTP Gateway.

How SSH keys work for authentication:

  1. An SSH key pair, which includes a public and private cryptographic key, is generated by a computer.
  2. The public key is stored on the server that you log into, while the private key is stored on your computer.
  3. When you attempt to log in, the server will check for the public key and then generate a random string and encrypt it using this public key. This encrypted message can only be decrypted with the associated private key.
  4. The server will send this encrypted message to your computer. Upon receipt of the message, your computer will decrypt it using the private key and send this message back to the server. If everything matches up, you’re good to go.

Pros: 

SSH keys can be up to 4096 bits in length, making them long, complex, and difficult to brute-force hack. 
These keys are typically at least 1024 bits long, which is the security equivalent of a password that is at least 12 characters.
SSH keys aren’t human generated, so they avoid easy-to-guess keys like “123456” or “password”.
Unlike passwords, your private SSH key isn’t sent to the server. 
So even if malicious actors hack into the server, they still can’t access your account.
SSH connection can only come from the computer where the private key resides. 
You can log in using a password from any computer, even a shared desktop at your local library.
You can add a password to your SSH key authentication (multi-factor authentication) to increase security even further.

Cons: 

Private key needs to be stored on the device with which you’re logging in. 
These devices can be lost or stolen And hackers can gain access to the private key and eventually the server.
SSH keys take a bit more work to set up.
System administrator can assign initial usernames and passwords and distribute them to employees easily. 
Employees can change these passwords so that only they know what they are. 
The sysadmin will no longer have access to employee’s passwords
Distribution of public keys and education of staff on how to use SSH keys can be more cumbersome. 
If the sysadmin provides an employee with a private key, he still has access to said private key and can log into the employee’s account.

Re-Evaluate the design

Room for improvement?

Dublin

Interview 1 (45 mins)

Technical RRK - Foundational technical knowledge where the interviewer will ask you at least one question from 2-3 areas based on your expertise. This would include areas like (but not all)
  • Connectivity (Layer-2 switching)
  • Connectivity (Layer-3 IP routing)
  • Network hardware devices
  • Network hardware performance
  • Webtech/troubleshooting/SQL
Troubleshooting - Focus on process of troubleshooting rather than technical details
  • Networking troubleshooting questions to demonstrate you can apply knowledge of Networking specific technologies to troubleshoot specific problems
System Design -
  • Designing technical solutions

Interview 2 (45 mins)

HrM Interview - This interview is based around the below criteria. This is some but not all they will cover.
  • Handling customer issues
  • Long term customer success
  • Escalating handling


A few additional tips which may help in your preparations
  • Talk through your thought process about the questions you are asked. In all of Google's interviews, our engineers are evaluating not only your technical abilities but also how you approach problems and how you try to solve them.
  • Ask clarifying questions if you do not understand the problem or need more information. Many of the questions asked in Google interviews are deliberately underspecified because our engineers are looking to see how you engage the problem. In particular, they are looking to see which areas leap to your mind as the most important piece of the technological puzzle you've been presented.
  • Think about ways to improve the solution you'll present. In many cases, the first answer that springs to mind isn't the most elegant solution and may need some refining. It's definitely worthwhile to talk about your initial thoughts to a question, but jumping immediately into presenting a brute force solution will be received less well than taking time to compose a more efficient solution.
  • When asked a question by the interviewer your answer should be:
SPECIFIC: inline with the question, no digressions.
SYNTHETIC: be factual, simple, short sentences, no long explanations. Inform the interviewer that you have additional info if he would like to know more.
TECHNICAL: your interviewer is an expert and they love to hear deep technical details in your answers (relevant to the question of course)... They are eager to learn something new.
OPEN: if you don't know the answer to the question it is not a problem but please please please tell the interviewer, don't pretend that you know by just guessing the answer. Tell them that you will attempt a solution by using the following X Y Z elements. ALWAYS explain the reasoning that you are following.
FLUID: keep the conversation going, no long blank moments, if you need additional information about the problem you are asked to solve, ask the interviewer. The interview is a conversation not a monologue, not an exam.
Retrieved from "https://aman.awiki.org/wiki/Google?oldid=4542"