Network Security Flashcards
Old way: remote access (network security)
Modern network access
PPP channels authentication
PPP is a protocol to encapsulate network packets (L3, e.g. IP), and to carry the ove a point-to-point link (physical, virtual l2, virtual l3).
PPP is activated by:
- LCP (Link Control Protocol)
- (optional) authentication (PAP, CHAP or EAP)
- L3 encapsulation (e.g. IPCP, IP control protocol)
Authentication protocols for network access
- PAP (Password authentication protocol): password sent in clear
- CHAP (challenge handshake authentication protocol): symmetric challenge
- EAP ( Extensible Authentication protocol): most widely used
- uses external techniques (challenges, OTP, TLS)
EAP
This is the PPP Extensible Authentication Protocol (RFC-3748). It is a flexible L2 authentication framework. It is L2 because before getting access to internet (which is L3) you must authenticate.
Authentication mechanisms that are predefined: MD5-challenge (similar to CHAP), OTP, generic token card.
Other mechanisms can be added, examples:
- RFC-2716 PPP EAP TLS authenticaton protocol
- RFC-3579 RADIUS support for EAP
In EAP the link is not assumed to be physically secure, EAP methods must provide security (on their own), some of these methods:
- EAP-TLS
- EAP-MD5 (only EAP peer authentication, not mutual)
- EAP-TTLS (tunnelled TLS, allows any EAP method to be protected by TLS)
- EAP-SRP (secure remote password)
- GSS-API (includes KERBEROS)
When authentication doesn’t work, it doesn’t mean that it failed, there could be a network problem. Network expert is needed to understand what is the problem.
EAP encapsulation
EAP has its encapsulation protocol because it needs to transport data to perform authentication at L2 (EAP authenticates before L3):
- EAP defines some small L3 protocol that is uses; this is completely independent from IP, and it’s designed to support any link layer.
- provides ACK/NAK requires for packets, but without windowing (differently than TCP)
- assumes packets arrive in-order
- PPP guarantees it, but if EAP is being used on virtual channels like UDP or raw IP this is not guaranteed, and it wouldn’t work in that case.
- Retransmission must be guaranteed to address packet loss, after N trials the authentication fails.
- No fragmentation (depends on the MTU of underlying L2), must be taken care of by EAP methods for payload greater than minimum EAP MTU.
Authentication for network access
Authentication works like in image.
On the left communication links (modems, access points) which are terminated in a device hosted by ISP (that are controlled by the NAS).
NAS receives requests from all clients and need to check user authorization; it will use protocol on the backend IP network to ask the centralized authentication server.
NAS manufacturers claim they sec. needs three functions AAA: AuthN (check identity based on credentials), AuthZ (is entity authorized to access services?) and Accounting ( tracking resource usage, capacity analysis and billing).
Authentication server offers exactly these functionalities and communicates with NAS with 1/more protocols.
Network authentication protocols
Protocols that NAS (Network access server) and AS (Authentication server) use to communicate, main ones:
- RADIUS: it is the de-factor standard, also most used
- nice feature that allows to behave like a proxy towards other authN systems.
- Can use external AS or implement it directly.
- DIAMETER: evolution of RADIUS, has focus on roaming among different ISP; has taken better care of security (since it’s new)
- TACACS+ (TACACS, XTACACS): competitor of RADIUS, technically better, but achieved lower adoption because it’s proprietary (CISCO).
RADIUS
- Remote Authentication Dial-In User Service
- Client-server protocol between NAS and AS.
- Supports AAA (authn, authz, accounting)
- physical ports (analogical, ISDN, IEEE 802)
- virtual ports (tunnel, wireless access)
- Has centralized system for administration and accounting (to store usage data)
- 1812/UDP authn; 1813/UDP accounting
- Each transmission has time-out (UDP is unreliable); there is max. number of tries before communication is declared impossible.
- To improve performance (and resistance to DoS): allows secondary servers.
- The protocol has various extensions (includign EAP support), and it also supports 802.1X (network access security architecture);
- user auth via PAP, CHAP, token-card and EAP
- CISCO provides a free server for CryptoCard
- other support SecurID
- RADIUS is extensible, attributes use TLV forma (type, length value)
RADIUS PROXY
RADIUS server can act as a proxy to authenticate with various authentication servers.
This means that RADIUS will act as a proxy for the authentication part and will redirect the request to the Windows domain controller. Then the authorization/accounting could be managed local by the RADIUS server. RADIUS can also be associated to another domain (e.g. UNIX NIS server).
Security measures needed by RADIUS
- Confidentiality, privacy
- NAS request (containing pwd) could be sniffed
- no problem with the response (can just be valid or not)
- NAS request (containing pwd) could be sniffed
- authn
- since this is UDP, an attacker could respond faster than AS, by allowing the user (even if not valid) or preventing access (even if valid) for Denial of Service.
- authn, integrity of AS resp
- otherwise it could be possible to change AS respo (y->n, n->y)
- anti-replay of AS resp
- attacker could replay AS resp (if not properly tied to NAS req)
- authN of NAS req
- otherwise an attacker could create a fake NAS and connect it to the back-end network between NAS and RADIUS server.
- availability
- DoS attacks can be performed by flooding the RADIUS server with requests coming from fake NAS.
- resistance to attack is proportional to amount of secondary servers.
- Real NAS assume that the server is busy if no response, and will switch to next one.
- DoS attacks can be performed by flooding the RADIUS server with requests coming from fake NAS.
RADIUS data protection
packet integrity and authentication via keyed-MD5:
- key = shared-secret
- client without key are ignored
password is transmitted “encrypted with MD5 (after padding with NULL bytes to a multiple of 128bit): password xor md5(key + authenticator)
RADIUS packet types
- ACCESS-REQUEST: contains credentials (username and password)
- ACCESS-REJECT: access is denied (bad username/password)
- ACCESS-CHALLENGE: requests additional information from the user (PIN, TOKEN CODE, secondary password)
- ACCESS-ACCEPT (parameters): access is granted, correlated with network parameters (e.g. IPaddr, netmask, MTU, host, port)
In each packet there is an authenticator, that has a double purpouse: in the server reply provides authentication and protection from replay, and masks the password.
- In ACCESS-REQUEST: Request Authenticator (16-byte randomly generated by NAS)
- In ACCESS-ACCEPT|REJECT|CHALLENGE: named Response authenticator, and it is computed via keyed-digest:
- md5 (code || ID || length || RequestAuth || attributes || secret)
NAI
Network Address Identifier: used to distinguish user requests made by local users or ones belonging to different security domains.
Syntax: user@realm
Rules say all devices must support NAI up to 72 bytes long.
All ASCII CHARACTERS < 128 ARE ALLOED.
username is the one used in PPP authentication phase, used when opening connection, not necessarily related to application username.
CHAP + RADIUS Example
The NAS is sending a CHAP packet containing a challenge request.
The client will sent the password through a challenge response, the the NAS will then create a RADIUS / ACCESS-REQUEST packet containing all necessary CHAP info.
RADIUS Server will answer with RADIUS / ACCESS-ACCEPT|REJECT, then the NAS will send the equivalent CHAP message.
NAS here is translating dialog between client and RADIUS server.
Then L3 will be enabled.
RADIUS ASSUMES WE ARE INSIDE A NETWORK ACCESS SYSTEM FOR A SINGLE PROVIDER.
DIAMETER
- evol. of radius
- special enphasis on roaming between ISP
- Better security w.r.t. RADIUS
- client must support IPsec and may support TLS
- server must support IPsec and TLS
- compulsory configs:
- (IPsec) ESP with non-null algo for both authentication and privacy
- (TLS) mutual authentication (client must have public-key certificate)
- (TLS) Must support RSA+RC4_128/3DES + MD5/SHA1 and may support RSA+AES_128+SHA1
IEEE 802.1X
General standard architecture based on RADIUS and DIAMETER. (authentication framework that supports multiple authentication methods)
Port-based Network access control:
- L2 authentication architecture
- usefule in wired network to block access
- absolutely needed in wireless networks (wifi is accessible from the outside)
- authentication and key management framework
- uses standard algos for key derivation (e.g. TLS, SRP)
- optional security services (authentication or authn + encryption)
- may derive session keys to use in packet authentication/integrity/confidentiality.
In picture: supplicant over wireless or lan, ask to connect to access points (authenticator, or etherNAS). When the authenticator receives EAP request, it will verify credenttials performing encapsulation/decapsulation of the packet into another protocol.
802.1X advantages
Exploits applicaiton level for the implementation of the security mechanisms, there is direct interaction between supplicant and Authentication Server, so the client are talking directly with the RADIUS/DIAMETER server.
The NAS and the network card on the other hand, now operate as a pass-through-device (encaps/decaps). This is important, because the security architecture doesn’t need to be changes with future evolution of authN techniques.
802.1X messages: example of connection
The switch acts like a pass-through element.
- The supplicant starts a negotiation by means of EAPOL-Start.
- The response from the switch is the EAP- Request/Identity and the Supplicant provides with the EAP- Response/Identity his identity, which is relayed to the Radius Server (Radius- Access-Request).
- RADIUS server will sent RADIUS-ACCESS-CHALLENGE tha will be translated in EAP-Request.
- At the end the user will be able to access the L3 network if authn works out.
Eduroam example
Eduroam is a world-wide a RADIUS network, involves universities and research centers allover the world.
Since it will be using that Network Access Identifier (NAI) syntax, the supplicant will use his identifier (e.g. s123456@studenti.polito.it) and the local Radius Server will know that it has to go through the Eduroam hierarchy (national, international,…) until it reaches the Radius AS in which the supplicant has created his credentials (e.g. the PoliTO Radius Server), which is called Home AS.
Once it has been found, there will be a direct connection through an E2E (End-to-end) virtual secure channel (e.g. EAP-TTLS) between the supplicant and the Home AS to perform authN and then the latter will provide the answer to the access point, which will permit to the user to navigate.
Which is the best OSI level to implement security?
“Presentation” is the only one in which security measures are not useful.
Unfortunately, there is not a single optimal level.
The upper we go in the stack, the more specific can be our security function.
If the functions are placed at application level only, attacks at lower levels are possible (in particular, DoS attacks are available).
The lower we go in the stack, faster we can “expel” the intruders, but the fewer are the data for the decision.
DHCP security
DHCP (in)security:
- When L3 is reached, DHCP is one of the first things to be activated, since the client needs to know network parameter to access the network.
- But the protocol is non-authenticated and broadcast, the protocol provides address, netmask, default gateway, localnameserver and local DNS suffix.
- Making fake DHCP servers is trivial, since it works as L2 broadcast frame, attacker just needs to stay in the broadcast domain of the victing and sniff the DHCP request.
Possible attacks:
- DOS: providing wrong network configuration
- Logical (MITM): valid ip address is provided to victing, but subnet has size of 1 (netmask has only last two bits to 0), attacker ip is set as default gateway. This way victim maching is isolated, and in order to communicate with the outside it needs to go though the attacker.
- replies could reach directly the victim, but the attacker could set up a NAT to be able to receive replies too.
- Malicious name-address translation: attacker declars itself the local name server. The user then will get the addresses the attacker wants him to see. (used for phishing and pharming)
Manufacturers have tried to provide sec. improvements:
- DHCP snooping: accepts only replies from trusted ports.
- IP guard: provides room only for ip addresses got from a valid DHCP server (issue: limited number of recognied addresses)
- RFC-3118 “AuthN for DHCP messages) which uses HMAC-MD5 to authenticate the messages.
- rarely adopted because a symmetric key needs to be installed in each machine that needs to use DHCP.
- key distribution problem
- key management problem (what if a key is captured in some way?)
- rarely adopted because a symmetric key needs to be installed in each machine that needs to use DHCP.
Network Level Secuirty (L3)
Since it is the first layer to offer end-to-end connectivity, it allows end-to-end protection for L3-homogenous networks.
If end-to-end encryption is provided, then data are secured as soon as they exit from client/server, and it’s not important if routers are not properly managed, or if network is unsecure, because data are protected as soon as they exit the network interface.
For these reasons, L3 security allows to forget about all other attacks at network level, but DoS (attacket could still take out the network).
VPN
A way (HW or SW enabled) to create a private network… while using shared/untrusted channels and transmission devices. You as a company don’t have to lay cables for your private network.
Techniques:
- via private addressing
- via protected routing (IP tunnel)
- via cryptographic protection
VPN via private addressing
Network to be part of VPN use non-public addresses, so that they are unreachable from other networks (e.g. private IANA networks).
Different addressing class to each customer, with ACL to control access.
This protection can be easily defeated if:
- somesone guesses or discovers the addresses.
- can sniff packets during transmission
- has access to the communication devices
NO REAL PROTECTION.
VPN via tunnel
- Routers encapsulate whole L3 packets as a payload inside another packet
- IP in IP
- IP over MPLS
- other
- Routers use Access Control List ( ACL ) to perform access control
- Defeatable by anybody that manager a router or can sniff packets during transmission.
- This is a protection only for Network Providers (from malicious end-users that change subnet of membership), customers are not protected (say network providers is malicious or has malicious employee).
VPN via IP tunnel
During transmission the packet can be readable, manipulated, injected.
Net1 and Net2 are part of the same subnet. If an IP tunnel is being used, when the packets goes from node A in subnet 1 to the node B in subnet 2, it reaches the border routers of subnet 1 which has the task to encapsulate it.
In the picture it is shown the external IPv4 header of the tunnel. When packet will be received at router R2 it will be decapsulated and sent to the final destination. During transmission the packet can be readable, manipulated, injected (again, no real security for the end user of the VPN).
IP tunnel has also a problem of performance: fragmentation. If the packet has size equal to the MTU, then encapsulation will only be possible with fragmentation. In this case, the maximum performance loss is equal to 50%, because two packets are generated instead of one, usually this happens in non-interactive applications (e.g. file transfer).
VPN via secure IP tunnel
Also called (S-VPN)
Same problems about performance of VPN via IP Tunnel.
Before encapsulation, packets are protected with:
- MAC (Integrity and authn)
- encryption (confidentiality)
- numbering (to partially avoid replay attacks)
Digital signatures are not used because they are slow, it would be impossible to fit them at current network speed.
If crypto algos are strong, only possible attack DoS.
TAP (Tunnel Access Point) performs encryption/cryptographic protection before entering the network. TAP shouldn’t be mangaed by the external network providers (otherwise this is fake security), it should be managed by the client.
IPsec
Architecture for L3 security IPv4/IPv6 to create S-VPN over untrusted networks and to create end-to-end secure packet flows.
Achieved using two protocols (with respective packet type):
- AH (authentication Header): integrity, authentication, protection against replay attacks
- ESP (Encapsulation Security Payload): nearly same as AH + payload confidentiality.
IPsec also has a dedicated protocol for Key Exchange IKE (Internet Key Exchange), to create keys in IP networks.
Security services:
- IP packets authentication:
- integrity: packet has been manipulated? (does not avoid manipulation)
- sender authentication (formal proof of id of sender) !== IP address (never trust source IP address)
- (Partial) replay-attack protection: work at L3 => packets can be lost and must be retransmitted.
- Confidentiality of IP pacekts: data encryption for payload (not header)
IPsec SA
IPsec security association: unidirection logic between two IPsec systems.
Each SA possesses different security features.
To achieve bi-directional protection between 2 nodes: 2 SA are needed (a->b b->a); in theory it is possible to have different security features/algos for the two directions, not applied normally.
SA are managed through local DBs:
- SPD( security policy database):
- list of security policies to apply to different packet flows.
- a-priori configured (e.g. manually) or conntected to automatic systems (e.g. ISPS (Security Policy System))
- SAD (SA database): contains list of active SA and their characteristics (algorithms, keys, parameters), used to create protected traffic for that specific SA.
In picture: when a packet is ready to be sent, they IPsec module checks what security mechanisms are needed (if any).
IPv4 Header and IPsec
IPsec ignores changing fields for creating hash in a syncronized way (the sender and the receiver must compute the same hash on the same parameters).
Unfortunately, during the transmission some of these parameters change, such as: TTL, checksum. Source IP address typically does not change. Typically, NAT could not be used with IPsec, because by changing the source IP address, the hash changes as well and then the check performed at destination will fail. There are also some options (e.g. source routing i.e. the number of routers that should be traversed) which change.
Transport mode IPsec
used for end-to-end security, that is used by hosts, not gateways (exception: traffic for the gateway itself, e.g. SNMP, ICMP)
pro: low computational load
con: no protection of header variable fields
The original packet is cut in two parts and a new header is put between IPv4 header and TCP/UDP header. Thence, the IPv4 header will assert that it is transporting IPsec (instead of TCP/UDP) and then, inside the IPsec header, there will be another field that will tell what is being actually transported.
Tunnel mode IPsec
Used to create a VPN, usually by gateways (not by routers, by gateways).
Gateway: node at the border of a network, which is assumed to be secure.
Pro: protection of header variable fields.
Con: computationally heavy.
Although not so common, IPsec in tunnel mode can be also used for end-to-end communication, even if it is usually adopted between border elements of the bigger networks: it is also called site-to-site VPN, since the entities are typically entire networks.
AH
Authentication header.
1st version offers these mechanisms: data integrity and sender authentication, compulosry support of keyed-MD5, optional support of keyed-SHA-1.
2nd version offers these mechanisms: data integrity, sender authentication and partial protection from replay attacks; HMAC-MD5-96, HMAC-SHA-1-96.
Header:
- Next header: since this is a pseudo protocol, in the IP header will be written that the packet is transporting AH, then inside the AH there is the real transporting packet field.
- Len: 1 byte to describe len of packet
- SPI (Security Parameters Index):
32 bits for referring in a quick and easy way to all the parameters that are needed to verify the packet;
- Sequence number to avoid replay attacks
- Integrity Check value (ICV): 4 bytes of authentication data
AH authentication process
Once the normalized IP packet is available, it is needed to compute the authentication value (ICV). For that, the Security Parameter Index (SPI) is being used inside the Database of the Security Association (SAD).
If the two values are equal, then the sender is authentic, and the packet is integral. If the two values are not equal, there could be a fake sender and/or manipulated packet.
Authentication is implicit. The authenticated sender is identified by a specific entry in the SAD, that entry negotiated with a specific node. The real authentication comes into play when we create the Security Association: this is the point in which the sender must prove its identity. Then the SA brings on that kind of authentication thanks to the usage of the correct algorithm/parameters.
ESP
(Encapsulating Security Payload)
Provides confidentiality. Base mechanism works on DES-CBC, but others are possible.
V2 provides also authentication (not for IP header), so coverage is not equivalent to AH. Advantage: packet dimension is reduced and one SA is saved.
Pro:
- payload is encrypted
Con:
- payload includes info needed for QoS by service providers, filtering and intrusion detection.
- the header remain in clear
ESP tunnel mode
Pro: hides both the payload and the original header
con: larger packet size
ESP packet format
SPI parameter is needed in clear to get the key to read the encrypted data.
In the exampled about DES-CBC we can see that Payload type field is encrypted, this makes impossible to implement QoS for network managers.
If ESP is used not only for confidentiality but also for authN and integrity then, at the end there is a variable number of 4 bytes words containing the ICV (Integrity Check Value).
IPsec replay protection
In order to know if a packet, which in the sequence is before the last one that is received, is a duplicate the only way is to keep a list of the received packet and check if the packet was already received or not. The receiver cannot have a list of all the received packets, because that would be a huge number.
Fixed window is used to mark received/not received packets.
If packet already received (in window): we discard it, could be replay attack.
If old packet(outside window) is received, there is now way to check it. It’s a risk to accept it (could be a replay attack), if discarded a communication problem could arise.
If traffic is protected by TCP it’s not a big deal if we accept an old packet, cause the TCP will discard it. On the other hand, if L4=UDP the packet should be discarded.
The window slides every time a new packet arrives. It doesn’t wait for not received packets.
IPsec V3 algorithms: integrity and authentication
IPsec V3 algorithms: privacy
MUST- === DISCOURAGED.
IPsec V3 algorithms: authenticated encryption
IPsec V3 algorithms: authentication and integrity
IPsec end-to-end security mode
End nodes create a transport mode SA between them, so that packets will be protected with the right level of sec.
If the LAN/WAN is insecure, there is no problem, in fact with this architecture the only possible attack is DoS.
Security is implemented independently from the rest of the network.
Downsides:
- IPsec must be installed on both machines communicating. Most OSes have an IPsec module, but not all kind of devices have one (e.g. Android, iOS, embedded systems, etc.), most importantly, not all devices have the computational power to support it.
- If we want to protect all devices connected to a big LAN, then a security management system must be put in place.
- If a Secure virtual channel ESP is adopted with non-null encryption algo, the traffic cannot be sniffed (not even from inside the LAN) => how do you implement an intrusion detection system? you have to put the at the node level, not at the LAN level.
IPsec Basic VPN mode
IPsec at gateway level. These will protect the internal network from the outside.
Since the channel must protect all the traffic, the gateway should adopt a tunnel-mode SA, because packets coming from one network and going to another must be encapsulated.
Assumption: internal network is secure and trusted, only worry comes from attacks carried over WAN. This means that if the local network is not really secure and/or trusted, we are screwed. No authentication of the real end-points, just the gateways. (Site-to-Site VPN)
Since gateways will be under some heavy computational load, they would be usually equipped with hardware accelerators.
Management on the other hand is greatly simpliefied w.r.t. end-to-end mode; and there is also a way for inspecting internal traffic.
IPsec end-to-end security with basic VPN mode
Example of Defense in-depth.
In this way it is possible to have two defence lines or also to balance the security: for example the end-to-end connection, that is the transport mode SA, could be used for authentication and integrity only (e.g. to clearly identify who the sender is), while encryption could be activated only between the gateways to protect from sniffing in the WAN and maintain the possibility to inspect the traffic on the LAN.
Problem: management here is even harder than in end-to-end mode.
IPsec Secure Gateway mode
IPsec module is installed on mobile devices, that create a secure virtual channel in tunnel mode SA.
This allows the user to have access to any internal server in the company network.
The gateway will also be able to to authorization and authentication.
IPsec secure remote
Example of defense in-depth.
Virtual secure channle between two end-nodes and tunnel-mode between the gateway and the mobile node.
typically the tunnel mode is used only for authentication and authorization (to give access to the internal network), while the transport mode SA is typically used for end-to- end protection, according to the kind of protection needed.
IPsec relation with IKE
Is defined as the use of ISAKMP with OAKLEY, that is widely adopted, and renamed IKE (Internet Key Exchange).
One of the most complex protocols in security:
- Creation of a SA to protect the ISAKMP exhachange
- The SA created at step 1 is used to protect the negotiation of the SA needed by IPsec traffic
- The same ISAKMP SA could be reused to negotiate different IPsec SAs.
Image contains possible schema of operations.
Initiator: takes initiative to open IPsec channel with aother machine (responder).
Once the SA to protecte ISAKMP is set-up, any of the two nodes can act as initiator.
Smurfing Attack
Type of DoS attack.
The target A is attacked by creating a fake ICMP echo request (ping) with A address as source, this request destination is a broadcast address of a whole network. This will produce a pong by every node in the network (reflector).
To prevent attacks of this kind from outside a network, every echo request is rejected at the border:
- interface serial0
- no ip directed-broadcast
Fraggle attack
Very similar to smurfing, but performed using UDP instead of ICMP.
Instead of ICMP echo request => UDP echo request.
Nowdays these requests are rejected by default.
TCP SYN flooding
TCP opens a connection through a 3-way handshake.
- Sender sends a packet contains a SYN Flag
- Receiver answers with an ACK flag + anther SYN
- Normally the sender closes/open the channel with another ACK
- A malicious actor could send the first message but never the last. After repeating this for sometime, the connection table will be full, preventing real users to connect.
Note: the last packet could be lost due to connection issues, TCP-IP will close connection if there’s no response after 75s. The table will be saturated until half-open connections are closed.
Countermeasures:
- Decrease the timeout
- risk of deleting request of real slow users.
- Increase table size
- attackers can always send more requests :)
- Use a router in front of the server: SYN interceptor
- substitutes server in handshake
- after the handshake, the channel is moved to the server
- Use a router as SYN monitor
- kills the pending connection requests
- SYN cookie
DNS security
Domain Name System: provides translation from names to addresses and viceversa.
It works by means of queries, performed over port 53/UDP, and zone transfers (transfers of information between servers) over port 53/TCP. It has no intrinsic security: DNS-SEC is under development and it has not been implemented yet.
Cache-miss: local dns will interrogate the top level DNS, that won’t probably have answers, it will in turn ask the right nameserver.
DNS mapping should not be stored on the clientside cache, DAMN YOU Microsoft!
DNS shadow server
If attacker is able to intercept and sniff the request to the local DNS, it can possibly provide a fake response.
If the attacker is able to intercept queries from the local DNS server to the Root DNS, it’s also possible to provide fake responses to the local name server that stores them in cache.
The client could be greatly impacted if they had a caching system for DNS (watching you, MSFT)
DNS cache poisoning
A malicious domain is associated with a nameserver. If the address corresponding to the domain is queried by someone, we could add information that are unrelated to the request.
If the victing (DNS server or client) is misconfigured or has flaws, it will accept the additional answers and overwrite available informations in its cache.
The attack is difficult to perform because the victim must explicitly request the address corresponding to the malicious DNS server.
Version 2 is much more effective, since it doesn’t need the victim to visit a specific website, we could poison the DNS cache by asking a DNS server to recursively seach for an address and then suppliying to them the response with an authoritative NS ip address as a src address.
Name address translation architecture
- OS component: name switch
- decides which service is used to switch from a name to the corresponding address.
- eth/hosts file has local data, if someone is able to add a name-address pair in the file, it is possible to force application to connect to a fake server
- typically provides priority between local files and external services (typically the resolver
- decides which service is used to switch from a name to the corresponding address.
- If the name is not found in local data, the resolver will be called to ask an external service (typically a caching server), the server can be eventually recursive (placing resolving queries on its own)
- it will contact the needed servers, according to the nedded zones.
- Each zone is managed by a master name server and a number of secondary name servers which maintain the zone file (name address mapping)
- caching server may contact master or secondary servers.
- Normally the zone master is updated manually by the admin. Microsoft added the possibility to perform dynamic updates directly by the clients. When a MSFT network is joined, an address is assigned, it is possible to inform the DNS master about the received ip address. Dangerous because it permits uncontrolled modifications of DNS data.
Kaminsky DNS attack
Protection from IP spoofing
Impossible to prevent host from not using its address. Limiting the diffusion of IP spoofing it possible though:
- Network address filtering
- Ingress filtering
From the internet it is possible to receive packets from any address, but not from internal networks (132.5.1 and 132.5.2).
By filtering with this rule on all lines
