If my server implements SYN Cookies to avoid DoS attacks, but an attacker knows the server utilizes SYN Cookies, is it possible that they could create half/fully open connection simply by sending an ACK?
I know that SYN Cookies use an algorithm to create the unique initial connection, and if the attackers handshake is incomplete the SYN is dropped and can only be recreated by receiving a valid SYN-ACK.
But could an attacker still somehow manage?
No, it should not be possible for an attacker to know what the SYN initial sequence value is in order to complete the TCP 3 way handshake. Further more it is not possible for any tcp port to be in a half-open state when they are using SYN Cookies. The answer is rooted in cryptography.
An implementation of SYN Cookies could use a Symmetric Cipher to generate sequence id's. For instance, when the machine boots it will generate a random secret key to be used for all TCP sequence id's. When the machine receives and incoming SYN packet to an open port it will generate a sequence id by encrypting the the Server's IP address, the Client's IP address and the port numbers being used. The server doesn't need to keep track of the SYN initial sequence id it sent out, so it doesn't have a per-client state and this idea of a "half-open" tcp socket doesn't really apply (at-least in terms of DoS). Now when the client sends back its SYN-ACK packet it needs to contain the SYN initial sequence ID. When the server gets this initial sequence id back from the client in a SYN-ACK packet it can work backwards, by encrypting the the Server's IP address, the Client's IP address and the port numbers being used.
Related
I have a Wireshark capture where several machines send TCP SYN requests and sometimes RST to the same target machine. All the SYN and RST are sent by different machines.
Is a cyber attack present in this capture? If so, what attack is it and how can I mitigate it?
I think it has something to do with TCP SYN Scan (aka half-open scan).
Introduction
I am currently trying to build up a networking layer for Unity from scratch. Currently I am testing the communication via UDP using Node.js for the server and the client. However I guess the language of the implementation will not matter for what I am asking for.
Current approach
The current approach using Node.js for the server and the client is pretty basic. I simply send a packet from a client to my server while the client and the server are not in the same local network. Both are behind a router and therefore also behind a NAT.
The server then sends back an answer to the IP and port received within the UDP packet that was sent from the client.
Problem
I am curious about the security on the client side regarding to ports being opened on the client machines and routers. So far I assumed that I don't need to do anything to secure the client from attackers or anything else that can do something with the ports that are used by my application. The following assumption shows why I think that I don't need to do anything to secure the clients.
Assumption
Server is setting up callbacks.
Server starts listening to a specific port which is also forwarded to the servers machine within the router.
Server now will call a callback when a UDP message was received. The server then will send a UDP message to the address and the port of the client obtained by the message received.
Client is setting up callbacks.
Client starts listening to port 0 which for Node.js's dgram means:
For UDP sockets, causes the dgram.Socket to listen for datagram messages on a named port and optional address. If port is not specified or is 0, the operating system will attempt to bind to a random port. - https://nodejs.org/api/dgram.html#dgram_socket_bind_port_address_callback
So the operating system now knows that packets sent to this port belong to my application.
Nobody can use this for something malicious.
Client, which knows the servers address and port, starts the process of sending a UDP message to the server.
Clients router receives the UDP message. NAT creates a random port (used on the public side) and maps it to the clients (local) address and port.
So the router now knows that packets sent to the public address and the newly generated port belong to the local address and port.
Nobody can use this for something malicious.
Clients router sends UDP message containing the public address and the NAT generated port to the server.
The worst thing that can happen is that a man-in-the-middle attacker can read the data the client is sending. Due to it is only gamedata like positions and so on that is sent this is not a big problem while developing the basics.
Nobody can use this for something malicious.
Server receives the message and calls the callback described in 3. So the server sends to the public address and the NAT generated port of the client.
The worst thing that can happen is that a man-in-the-middle attacker can read the data the server is sending. Due to it is only gamedata like positions and so on that is sent this is not a big problem while developing the basics.
Nobody can use this for something malicious.
Same as 7. with the servers router and the servers local address and port.
Same as 8. with the servers router.
Client receives the UDP message of the server and calls a callback which processes the message contents.
Due to the local port of the client is bound to my application only nobody can use this for something malicious due to I simply ignore the contents if they are not from the real server.
Question
So is my assumption correct and I really don't need to secure the client from any attacks that will harm the clients in any way?
I too feel that this is a stupid question but I'm unsure if capturing traffic will work if the host is offline? I was actually discussing about Man-in-The-Middle attacks and just thought lets suppose https://example.com is offline (down or blocked on a network) and someone made a request to http://example.com/example-category/example so will an attacker be able to capture this complete GET request in a local network?
I think yes because the request will anyhow be sent from the client to host and there it should be captured. If that is the case then can HTTPS traffic be also captured (talking only GET based) if the host is offline or blocked intentionally on a local network?
If the man in the middle is located in the network before the host is found unreachable (for example in the local network before the router), then yes, the request would go to the MITM.
Yet the MITM might be in a bit of a situation if he finds destination host unreachable from his network, too.
If the router/gateway that is blocking the request is before the MITM, the request will be blocked and not received by the MITM.
If there is no MITM, but just traffic monitoring, there will be no connection made and thus no request transmitted to be monitored.
As to HTTPS: If the MITM cannot provide a valid certificate for the domain name (usually, MITM cannot), the connection would fail on the TLS part.
No. Before the http request itself can be sent, the initial TCP connection has to be established. And if the host is offline, then the TCP connection CANNOT be established.
No connection, no request, therefore nothing to sniff. The only thing that COULD be sniffed/intercepted would therefore be the initial TCP SYN packet, and that by itself is essentially useless.
It's like dialing a phone number that doesn't exist - the attempt to dial can be monitored, but since the call can never be established, there's no voice chatter to intercept.
If it were possible to retrieve the remote IP from a packet received by my Apache2 server (through a custom plugin perhaps), would it always be guaranteed to be accurate? Or is this value as easy to spoof as the referrer header?
My intended use case is to rate-limit unauthenticated API calls.
If it's a TCP packet, then it'll be accurate as to the sending host. IPs in TCP packets cannot be spoofed unless you've got control of the routers involved. With spoofed source packets, only the initial SYN packet will come back, and then the SYN+ACK response from the server will go to the spoofed address, not wherever the forgery came from - e.g. you cannot do the full 3-way handshake unless you can control packet routing from the targetted machine.
UDP packets, on the other hand, can be trivially forged and you cannot trust anything about them.
As well, even simple things like proxy servers and NAT gateways can cloak the 'real' ip from where the packet originated. You'll get an IP, but it'll be the IP of the gateway/proxy, not the original machine.
It is not reliable. Not only because it can be spoofed, but also because a network element can make your server see a different IP address.
For example, it is very typical in a company to access the Internet through a proxy. Depending on the configuration, from your server point of view, all the different users come from the same IP address.
In any case is a filter you can use in many scenarios. For example, show a captcha when you detect too many login requests from the same IP address.
If your intention is to rate-limit invalid API calls you might want to consider using a service like spamhaus. They list IP's that are likely bots and probes. There are other companies and lists as well. But if your intention is to ever ID the 'bad guy' the source IP is very unlikely to be correct.
We are developing a TCP client tool which connects to one of our TCP servers. We send custom packets from the client to the server which the server knows how to intercept. On our server we wanted to know from which client machine the packets are received.
Is it ok to send the Hostname of the client machine in the packet?
The bigger concern is for cases when the client machine is a machine in a corp network?
Thanks in advance
Sending the client name in a clear text over the internet is indeed information disclosure. What is the impact of this depends on how your corpnet is configured and secured. If you want to ensure that you have mitigated any potential threats, you should encrypt the client name in the packet and subsequently sign the packet to ensure integrity. Of course, that has associated cost, so it's up to you to assess whether the perceived threat warrants incurring that cost.
What will you be using the host name for? Can you simply use the IP address, which you have because you have an established TCP connection?
-Brian J. Stinar-