Is there a way to automatically match users to different ports when accessing www.***.com?
Is it possible to change :80 to :10001 when connecting, and if someone is matched, change it to :10002?
No, there's likely not a way to do this automatically. Because it's rare to want to do something like this on a Web server.
Related
We've developed a server software and for ease of use for end-users, we are using the localtunnel-server app on one of our linux servers to get around the need for port forwarding and messing around with firewalls.
The problem is that it seems to tunnel "all" traffic on the port 80. However, we are afraid of this being abused. We would like to restrict traffic somehow and I wanted to know if that was even possible.
For example, let's say our app uses the "/myapp" virtual directory on the localhost website. So if a request is supposed to go to http://localhost/myapp/index.html then the traffic gets tunneled to http://mytunnel.myserver.com/myapp/index.html
The problem is, if there are other sites running on localhost, http://localhost/someotherapp also gets through. We'd like to block urls that don't match a format or contain keywords such as "/myapp"
Is that even possible? And if so, any guidance on how to achieve this, would be greatly appreciated.
This is likely a misunderstanding of the fundamentals on my part so any criticism is welcome.
I want to have a button that will check to see if one of our servers is up/down then display the result in a label.
Would it be possible to use ping for this then somehow assign 'true' in a label if there are packets received?
A literal ICMP Ping is probably not what you want here. Servers are often configured to not respond to ping, and what you likely really want is to check if a certain service on the server is running. (If the system is booted, but your service is crashed, you probably don't want to report 'good'.)
I would suggest that you make a connection to the service you're interested in. Best would be if you can make a true connection and talk the proper protocol, but if all you can do is to open a TCP connection, that will at least tell you that the service is running.
I want to restrict the daemons from opening certain ports, and i wish to achieve it at kernel level.
I came across an idea, i.e to write my own bind function and then redirect to the original bind function. But the user can bypass this by invoking the system call. Any suggestions?
Just a thought:
there's a chance that 'iptables' could do the work for you.
Using 'iptables' you can define a rule which will deny outgoing traffic from a port.
This solution may work for you if you can identify the deamon's traffic according to iptables options. It will not work for you if you can only identify the deamon's traffic according to its process id.
i dont want to do something illegal with it(e.g. vote continuously, in fact, somebody is doing it), but i only feel curious about it. For i have learned TCP/IP, and i found there are many software such like "IP changer",using which you can submit a website with different IP. WOW it is really magic! so i analysed some possible mechanism about it. But every possible way was denied by me.
i thought that they might connect and disconnect the internet continuously. because each time they connect the Internet, the ISP will dispatch a new IP address, and the hacker can make use of the new IP to submit the website, and disconnected after submitting successfully, and then connect for the next time...But it is impossible to some extent, for if do like this, every submitting will last a long time, and it doesn't work in some areas.
Modify TCP/IP data packets.For some time i did think it might be all right. but then i denied it. Assuming that i would submit a website, and i changed the IP address of the data packet which i will submit to the web site. it seems that everything is OK, but the web server will send message to the fake IP, so i wont get any information from the website. but in some circumstances where we only needn't reply it should work. Right? netfilter and iptables in linux may realize it, but i am not sure because i dont know the tools very well.
Using proxy server. i also think it is impossible to some extent.is there any method to get lots of free proxy servers? and most free proxy servers is very unstabitily, for there is a possible circumstance that you cannot use the proxy server in one day.Of course, paid proxy server may be permanent. but with these money you can do something better.
IMO the three methods all have disadvantages. and the realization may be none of them. Can anybody tell me the real mechanism of the technique?
Use lots of proxy servers. That will do the trick and since they can be harvested quite easily that's not very hard. Proxy's can be installed on hacked websites for example.
The added question:
Using proxy server. i also think it is impossible to some extent.is there any method to get lots of free proxy servers?
By simply hacking lots of webservers, totally automated, this is possible. For example searching for bad Joomla installs could allow you to install software at each webserver. Also normal computers can be used off course. Like a botnet.
and most free proxy servers is very unstabitily, for there is a possible circumstance that you cannot use the proxy server in one day. Of course, paid proxy server may be permanent. but with these money you can do something better.
Stability is off course important but in this case not really actually. You just send out lots and lots and lots of requests. Don't care which one succeeds and which one doesn't. It doesn't matter for your target.
1. ISP reconnect
This will not work for some (most?) ISPs which will reassign the same IP on a reconnect (as my provider does). Even if it works, you are likely to get the same IP address after some reconnects.
2. IP spoofing
That's the term describing your second method. You change the src-address of the outgoing IP packet. There are two problems with that:
Most ISP's routers don't allow it. They detect that the src address can't come from inside their network, so they simply drop it.
If you have a machine that is allowed to do this (maybe a dedicated server), you can only fake exactly one IP frame. This allows you to, e.g. spoof a DNS request but as you said, you will never get the response. Especially you cannot establish a connection within a stateful protocol like TCP, because this requires a bidirectional handshake. So you can't, e.g., fake a HTTP request using this (even if you don't need the answer)
Proxying
This is the only method that works. You have several options here:
Use open proxy servers (can be found using a search engine, although some will identify themselves as proxies and provide the original IP in the X-Forwarded-For HTTP header, which makes them basically useless for this use case)
Use hacked servers/desktop machines as proxies (maybe from a botnet)
Use free networks like JAP or TOR (the latter of which is probably your best bet, because you can change the exit nodes using some trickery)
If you are going to do something illegal, you might as well go all the way in. There ARE people who run "botnets" which are basically just armies of a few hundred to a few thousand indfected computers (that's what most viruses do). The people who run these armies, actually can charge people a certain amount of money for their "slaves" to visit a website for you (and rate/vote whatever) so you get a few hundred or a few thousand more ratings...
I can't exactly tell where or how much these services cost, since I haven't done it myself, but I know for sure that people over at "H#ckf0rums.net" will do it for you.
Currently we use DNS polling for four web servers.
The problem we met is that: When the user refreshes, he might go to other web servers. This feels very bad when a user has already logged in. Because we use a session to remember login status, but when refreshing to other web servers, the session is lost.
So the best solution should be to make the user still be on the same web server when he refreshes. Is there a way out?
Ok, I believe you mean "Round Robin DNS". Well, what you describe is a very common problem and there is no "right" solution for it, since the possible answers depend on many variables: are you trying to provide automatic failover or just load balancing? Are you willing to spend time and/or money in a load balancer? What technologies are you using? Java EE? PHP? Apache? IIS?
Having said that, if you're just after load balancing and failover is not much of an issue you may want to use different names for each server (www1,www2,www3 and so on) and redirect to them from your "main" web server (www) upon first access. It's simple (and simplistic) but practical in a few settings.
Can the web servers use a common database server to store the session information?
I know that certain hardware based load balancers will create a "sticky" relationship between a user and a server to avoid this type of problem.
You have quite a few options.
You can store sessions in a key:value storage, f.e. memcached (my personal favorite)
You can store sessions in a database
You can put reverse-proxy loadbalancers like in DNS and Your servers in the back. Then set it to make all requests from the same IPs go to the same servers, regardless of which loadbalancer they go through. In HAProxy this option is called balance source. Beware: if the number of node changes, the sessions can be lost. You can use the cookie or url_param features to avoid this.
See the HAProxy documentation. It's worth reading, really.
Are the four web servers all on the same site and network, or are they distributed?
If the former, you can include a server ID somewhere in the HTTP response, such that a reverse proxy in front of the real servers can identify which server is responsible for the session.
A DNS server that can respond based on the location of client could solve this problem. PowerDNS with the geoip module or GeoIPdns are some examples. You would need to make sure that the IP address sets were non-overlapping so a client always got the same response.
This would not provide any sort of fail over on its own.