When using the -T option to use TCP SYN for probes, (1.)is this how it works: SYN is sent and ACK is received so only a two way handshake occurs so connection with server is made but no confirmation is sent back to server? and it still tracks the server address and data received through traceroute,(2.) is this what keeps the probes from being identified by server firewall/ applications?
Related
I want to be able to receive SYN packets from a client, but not send back a SYNACK response. I have tried a few things. If you use raw sockets, it is possible to receive the full packet but linux kernel seems to automatically send back a FINACK packet. I found out that this was because I did not have a service actually listening to the port I was monitoring. My next step was to bind a socket to the port I was interested in, and use the listen() syscall to listen to that port, along with the raw socket. This approach results in the kernel automatically sending back a SYNACK rather than a FINACK. Is there anyway to receive a raw packet, and not send back an automated response? It seems that raw sockets can only snoop on packets, rather than actually handle them. I have also tried using a UDP server socket to listen to the target port, but I am still sending back an automatic FINACK.
I'm attempting to craft a raw TCP packet to send over Ether in a raw socket on a linux client and server. The special part of the TCP packet is that I'm attempting to use the raw data field of the TCP SYN packet and RST packet to send data back and forth (for a proof of concept about an unused part of the TCP protocol).
I've disabled RST packets from my iptables on the server.
In short, here's my current situation:
Client sends SYN with data is sent to server
Server receives a SYN packet without data
Server responds with a RST packet with data
Client receives a RST packet without data
But, using the same socket, I can successfully do this:
SYN without data sent to server
Server receives a SYN packet
Server responds with a SYN ACK packet with data
Client receives a SYN ACK packet without data
Client receives a PSH ACK packet with data
Can someone explain to me why the packets I send don't seem to make it to the server in the same way I send them?
Why am I receiving two packets (one with SYN ACK and one with PSH ACK) in my successful attempts?
SYN and RST packets seem to lose their data, but SYN ACK packets don't. Is this a firewall issue?
If so, how can I debug what's intercepting my packets?
Thanks!
Turns out the VMWare virtual adapter was modifying the packets in transit. When I did a packet capture on the host operating system, there were no issues transmitting data.
Is there any way to delay the Syn-ACK when the SYN is send by the client to the server and server has reply with SYN-ACK, in the three-way handshake protocol, is there any specific tuning required in sysctl.cnf file or whether it can be done by iptables settings ?
I have 2 linux based systems - a client with 2 interfaces (1 LAN, 1 modem) and a server.
I open 2 UDP sockets, and use setsockopt with SO_BINDTODEVICE to bind each socket to it's interface.
Then I send a message from client to server through each of those sockets.
Both of them reach server. Server socket reads them, and sends a reply to each of them.
Then I try to read server's reply on the client.
BUT, there is only 1 reply.
Also if I run tcpdump, I see that both of the replies are received on their relevant interfaces, on the same port that they left. Yet only one of them reaches socket. The other is lost?
The "lost" packet is not random, it's the "non" default one. If my routing table is empty, the modem one is lost. If I add a route to server ip from modem interface, the lost packet will be the lan one.
Yet, they always reach server, always return back, always seen in tcpdump, but 1 never reaches socket. How can that be?
There is an ipv4 network configuration parameter called rp_filter (reversed path validation filter). Basically, if the reply to a packet wouldn't go out the interface this packet came in, then this is a bogus packet and should be ignored. Which is why while I saw the packet on the tcpdump, it never reached socket. Disabling it did the trick.
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.eth0.rp_filter=0
sysctl -w net.ipv4.conf.ppp0.rp_filter=0
Suppose I have static ip in a subnet that has DHCP server. If i gonna send DHCPINFORM
message to the server, what will happen ?
amit
As per RFC-2131 tropic 4.3.5 for DHCPINFORM message:
"The DHCP server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the 'ciaddr' field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in 'yiaddr'. The server includes
other parameters in the DHCPACK message as defined in section 4.3.1. "
1.
Since a "DHCPAck" message does not mandate to add all requested network configuration parameters, a DHCP server is free to respond to a "DHCPInform" message, with/without requested parameter responses (implementation dependent), provided the client's static ip settings are validated under dhcp server pools.
2.
Also, the dhcp-client may receive "DHCPAck" messages from many DHCP servers in response to its "DHCPInform" message. The client need to filters all of the "DHCPAck" messages received from DHCP servers to extract response parameters.
[ Example: The dhcp-client may searches each received "DHCPAck" message for a predetermined vendor-specific tag. If a "DHCPAck" message includes a predetermined vendor-specific tag, the dhcp-client extracts response parameters from this message. ]
The question:
If I send a DHCPINFORM message to the server, what will happen ?
Good question :) The answer is not quite so clear. There are variances in DHCP server implementations, and the RFCs are a bit ambiguous. Additionally, the DHCPINFORM message (always initiated by the client) has gone through some revisions - or revelations if you prefer, and so the answer may also depend on the vintage of your DHCP server software:
DHCPINFORM was initially defined in RFC2131 in March, 1997. RFC2131 has been updated 4 times by: 3396, 4361, 5494, 6842. Since RFC 2131's publication, DHCPINFORM itself has subsequently been "clarified" 7 times through 2011. A search will highlight some of the confusion sown in the wake of the creation of the DHCPINFORM message; for example.
A bit more recently, RFC 3203 created a FORCERENEW message which forces the client (incl. hosts using the DHCPINFORM message) to the RENEW state. RFC 6704 updates RFC 3203 with details on use of the Nonce Authentication protocol for security. These standards have made the answer to your question still more ambiguous.
Due to variances in DHCP server implementations, perhaps the best way to answer your question is to use nmap (or similar) to discover the contents of the ACK message issued by your server in response to a DHCPINFORM. I chose nmap to illustrate this because of the dhcp-discover script that is part of the nmap scripting engine sends a DHCPINFORM message. Here's how it worked on my system:
$ sudo nmap -sU -p 67 --script=dhcp-discover 192.168.1.1
Starting Nmap 7.70 ( https://nmap.org ) at 2022-05-30 18:37 CDT
Nmap scan report for myprivlan.com (192.168.1.1)
Host is up (0.0013s latency).
PORT STATE SERVICE
67/udp open dhcps
| dhcp-discover:
| DHCP Message Type: DHCPACK
| Server Identifier: 192.168.1.1
| Subnet Mask: 255.255.255.0
| Router: 192.168.1.1
| Domain Name Server: 192.168.1.1
|_ Domain Name: myprivlan.com
MAC Address: 00:25:B0:E0:A9:F5
Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds
And so you can see what information was included in the server's ACK message. AIUI, this information may only be a subset of the complete set of information in the ACK message - a subset defined in the dhcp-discover script; you may analyze the script code to verify that.
As a further experiment, I made some changes to my DHCP server's configuration (the OPNsense firewall), and re-ran the same nmap command. In each case, the change I made on the server was accurately reflected in the nmap output.
Consequently, it seems that DHCPINFORM does meet the original objective - to update clients with static ip configurations. But it is the client's responsibility to request this update periodically.