For the first connection my proxy server direct user to server1 and then I want to redirect him to server2 but firstly I have to kill connection. If I use tcpkill it kills all further connections from this ip, and user can't get response from the server. How can I kill during connection and be able to create new after next user's request?
Related
perhaps a silly question!!
in real networks, do servers send requests to each other? for example do a web server send request to another web server to fetch some data (for example .jpg and so on) ? or can a DNS server send request to another DNS server to ask an ip address?
i want to implement an algorithm for worm detection. i know servers often listen to a port and answer to the requests. so i think if a server initiate a connection , it is infected. but if in normal condition servers send requests to each other so servers can initiate connection in normal condition and so we can not say a server is infected when it initiate a connection.
thanks.
I have a service which will listen on port 8443 after it is launched.
I have xinetd configured to start my service when a connection is made on port 8443.
So Xinetd should launch my application and then let my application handle any more incoming connections.
I'm getting repeated "warning: can't get client address: Transport endpoint is not connected" and then Xinetd disables my service for 10 seconds.
This only happens when I set wait = yes.
Stopping my application from listening to port 8443 doesn't make a difference.
Is my understanding of xinetd wait flag correct or am I doing something wrong with the xinetd configuration?
I've looked at man pages, wait=yes is usually associated with UDP but nothing in there says you can't use it with TCP.
I searched on SO and everything I found has tcp working with wait=no.
I am getting the following errors when connection to xinetd.
5786]: warning: can't get client address: Transport endpoint is not connected
5564]: EXIT: MyApplication status=1 pid=5786 duration=0(sec)
5564]: START: MyApplication pid=5787 from=<no address>
5787]: warning: can't get client address: Transport endpoint is not connected
5564]: EXIT: MyApplication status=1 pid=5787 duration=0(sec)
5564]: Deactivating service MyApplication due to excessive incoming connections. Restarting in 10 seconds.
5564]: FAIL: MyApplication connections per second from=<no address>
5564]: Activating service MyApplication
My configuration is:
disable = no
socket_type = stream
protocol = tcp
wait = yes
user = user
server = /usr/bin/MyApplication
port = 8443
type = UNLISTED
flags = IPv4
Just incase anyone else comes across this, I was looking for the same thing. From this comment by one of the maintainers Steve Grubb here, he says
A wait service is one that accepts the
connection. telnet does not accept the connection - it expects the connection to
be accepted and the socket dup'ed to the stdin/out descriptors.
There is also no way for xinetd to check to see if a child has accepted the
connection. Therefore, when you have a program that's configured as a wait
service and it doesn't accept the connection, the socket is still readable when
xinetd goes back to the select loop. Around and around it goes.
The child server is launched from when xinetd forks then calls exec_server. When wait=true, as mentioend above the child process must accept the connection on the socket. To get the socket the file descriptor with value 0 can be used with accept. I am using python with the following,
import socket
s = socket.fromfd(0, socket.AF_INET, socket.SOCK_STREAM)
print(s.accept())
which returns (conn, address) where conn is a new socket object usable to send and receive data on the connection.
From the man pages
wait This attribute determines if the service is single-threaded or multi-threaded and whether or not xinetd accepts the connection or the server program accepts the
connection. If its value is yes, the service is single-threaded; this means that xinetd will start the server and then it will stop handling requests for the
service until the server dies and that the server software will accept the connection. If the attribute value is no, the service is multi-threaded and xinetd
will keep handling new service requests and xinetd will accept the connection. It should be noted that udp/dgram services normally expect the value to be yes
since udp is not connection oriented, while tcp/stream servers normally expect the value to be no.
So if you have wait=yes you are single threaded. Once there is a connection nothing else is is able to connect till your current sessions disconnects or the script ends.
So, a Client connects to Server A, which then creates an iframe pointed at Server B. The Client submits a request through the iframe to Server B. Does Server B see the request as coming from the Client or from Server A?
Application: I have two services running on one machine, let's say one on port 443 and one on port 9090. Port 9090 is closed at the firewall, but it can be accessed from other services on the host machine. If I host a page on 443 with an iframe directed at port 9090, will that service see that request as coming from the host machine and send the data, or from the external client and drop the connection?
Server B will see the request coming from the client browser not from server A.
Generally Iframes are requesting its URL from the client browser.
I am trying to write Connect calls via a NTLM authenticating proxy server. I open a socket to the proxy server and send it a “CONNECT x.x.x.49:80 HTTP/1.1\r\n\r\n”. I expect this to fail as it is an authenticating proxy server but it fails and also closes my connection to the proxy server. I am using Wireshark to check packet values. I can see “Proxy-Connection: close\r\n”. If I do a GET it does not close the connection.
My question is if it is correct for a failed Connect call to close my socket connection?
I'm not 100% clear about your question - I would not expect the first CONNECT to fail with an NTLM proxy server, as it should have sent a Proxy-Authenticate: NTLM header back.
In any case, proxy server has the full right to close the client-side connection in a case of failure, so the answer to your question is "yes". It is odd that it does not do the same for GET, however proxies are more limited with what they can do as a response to CONNECT, and this one may decide that it can't support HTTPS for your request.
What do i need to send to a proxy server (http or socks) that will tell me if it is connected to the host i specified it to connect to.
Neither proxy protocol provides that functionality. There is no way to query a proxy to see what server it is connected to, or whether it is a still connected to a server. If you tell it to connect to a server, then you have to assume it is always connected to that server as long as you have a valid connection with the proxy. If the proxy loses its connection to the server, then it needs to close the connection with your client.