Presently I am doing a project on designing and implementing a firewall. Everything is working fine. Here I am filtering all packets going through a TCP port. But I need to send a custom page if a page is being blocked. Like "Your page is blocked by admin". I don't have any idea how to do it. Can I do it using raw sockets? If so please tell me, how to? But as I know raw socket does not work for sending on Windows XP SP2 and later, is there any other solution?
EDIT: I used C++ to create a DLL for an IP address filter. Then I imported it in my C++ program. IP addresses are blocking fine. But my customer needs the custom message when a browser is not finding its page.
If you're selectively allowing access to certain web pages, you're essentially acting like a proxy. And you'll need to act more like one if you want to respond to clients with an error page.
A browser making an HTTP request will expect the response on the same connection it opened. In order to return a "blocked" page, you'll need to determine whether the connection is to someplace you don't want the user to go, and if not, return a valid HTTP response (even if that response is an HTTP error like "403 Forbidden" or something more appropriate to a proxy) on that same connection.
If you're blocking the connection before it's even opened, ie: blocking access to certain IP addresses, then you're kind of stuck. The most you could do is return an ICMP message saying the host isn't available. You need to at least accept the connection if you can, accept the incoming request, and reply with your error message. Anything less, and a browser typically won't know what to do with it.
Hey, Since you're working on that low level
Can't you redirect the request by modifying its HTTP header?
Related
I'm not a network expert, but for one of my projects, I need to ensure that the website I'm sending the request to is alive. Some websites do not respond to ping; basically, their configuration prevents response to ping requests.
I was trying to Arping instead of pinging websites, but Arping only works on the local network and will not go beyond the network segment (this).
I can download the whole or part of the webpage and confirm if the content is the same as the previous state, but I rather have one more level of confirmation before downloading Html.
Is there any other method that enables the app to get a response back from non-pingable websites outside the network?
Based on common practices you may use ping, telnet and tracert as a client to the requested server (at this point the website or the service you want to connect) and make sure the 3 command are enable to your side. You may also try to access it to your browser.
If its API you may also try to use POSTMAN and call the service.
Goodluck and happy coding :)
I want to write a little c# tool for a web application (which runs inside a browser). Unfortunately, I have no idea how to hang into the HTTP communication.
There are a lot of tools that listen to network traffic and extracting relevant data out of it so I guess there must be a solution. My current approach is to catch the responses by listening on the corresponding port. But:
HTTPListener seems to be a server-side class that accepts HTTP requests
HTTPRequest is just the message object and has to be received before
I don't think TCPListener would be applicable because I don't want to create a connection
Is there another solution how to just get the server response without sending a request? Or might another approach be more reasonable?
I don't want to write a proxy because I simply don't want a server, just a lightweight, easy-to-use tool.
I was not able to find any hints on this topic since all results of my searches were about receiving responses to own requests or similar.
Thanks in advance for any solutions or suggestions!
Phil
If you don't got the idea of the tool, here is an example:
A user has firefox running and navigates to the target web application
He does anything and the web application sends the corresponding data to the web server
The web server processes the request and sends back a response
The web application updates itself inside the browser to display the received data
My tool (C# application) should do the following:
Catch the response of step 3 and evaluate the response to also update its own state
OR: do anything else (suggestions?) to keep its state up-to-date
Hi is it possible to check if the Remote webdriver server is running or not using C#. Pinging the server did not help , Can you tell what type of call should be done and what will be the feedback that we can expect from the server
You should really define what you mean by 'running'.
You can get the general status of the server by chucking a JSON request at it.
You see the server will implement the Wire Protocol, so it means that it will, or at least should, respond to the following list of REST url's:
http://code.google.com/p/selenium/wiki/JsonWireProtocol
Specifically:
http://code.google.com/p/selenium/wiki/JsonWireProtocol#/status
and possibly
http://code.google.com/p/selenium/wiki/JsonWireProtocol#GET_/sessions
The status supposedly, will:
The server should respond with a general "HTTP 200 OK" response if it is alive and accepting commands
If this is what you mean by 'running', that it is alive and kicking and willing to accept commands, then you will need to send off a request to /status and check for the response you get back.
I have an app that makes a request to a server and gets authenticated.
I'm wondering if it is a possible to write a listener that listens for requests and if any request matches that particular request the listener sends back a message, without it actually getting to the server.
In essence I want to make the app. think it has been authenticated when it actually hasn't.
This is what the tcp stream looks like on WireShack. The highlighted response is exactly what I want my code to respond to.
Is this possible?
Yes. It's called a "proxy", and you can do that in C# by using System.Net.Sockets namespace. Or you can use Fiddler and forget about programming at all. :) (Btw - AFAIK Fiddler is written in C# too)
I have created a WCF server in a PC named PC1. I access the URI http://PC1:8000/ServiceModelSamples/Service using internet explorer from another PC named PC2.
When I debug the messages in Wireshark, I am confused that why there is no HTTP message, even though I specify "http://" in my URI. It only shows TCP protocol, there is no HTTP message or header.
Please advice
To wireshark, any browser request is just another TCP connection. As far as showing the HTTP protocol details is concerned, it might be guessing that traffic on a specific port (80) would be http. Since you are using a non-standard http port, it might not be able to do so.
To confirm this, try loading some other website/webpage (e.g. www.google.com) and see if it is able to show you http details. If it works, then next thing would be try and find some setting/configuration by which you can tell wireshark that it should treat traffic from another port (8000 in your case) as http traffic.
EDIT:
See this question as a guide to configure wireshark for http ports.
HTTP is an application layer protocol that sits on top of TCP, the transport layer protocol.
See http://en.wikipedia.org/wiki/TCP/IP_model for more information.
When you access the service using a browser, a "friendly" service responds to generate a web form to your browser. If you get a web page back in your browser, it is HTTP. That's not part of the "SOAP" spec, but it is part of the MS WCF stack supporting HTTP.
Then, if you fill it out, you might be POSTing or GETing the form, but POST is the default. That's also HTTP. GET is often disabled in WCF.
Then, you get back XMLish stuff in your browser, that also came by HTTP.
So you might just be missing an HTTP protocol decode in wireshark.
EDIT: I didn't see your URL included :8000. Wireshark won't decode that as HTTP unless you force it to, because it's not on the HTTP port. You can right-click on a port 8000 packet and say "follow conversation", and you'll see all the http goodness. You can also force wireshark to decode that stream as HTTP, which will let you "drill into" the packets past the TCP layer.