in this scenario, you have a router/modem combo with dhcp enabled. no control over dhcp, but this router seems to always assign the same ip address to the same devices. lets say the router assigns 192.168.0.27 to a local machine. you, in turn, set a static ip address on said local machine as 192.168.0.27. in this scenario, and, well my situation, you still have access to the network.
i understand that the router will expect the local machine to operate under that name until the timer runs out and then its open game. will it stop accepting traffic from the local machine under that address when the timer runs out? if no device ever receives that ip address, would it ever really be an issue?
Well, the answer is - as usual - "it depends", but in most cases it will just work fine.
Being DHCP-enabled does not mean "DHCP only" and most home routers I know about will just let those statically addresses work.
There might be some which don't let them work because the address is in the pool the have "authority over" - but these should be the minority.
Related
My company is currently developping an embedded device running uClinux.
Those devices are supposed to be deployed in both un-managed and managed networks.
We are looking for the best strategy to assign static IP addresses (and subnet masks) to those devices (from a Windows computer on the network) when no DHCP (or BOOTP) server is available and save those values to a configuration file in the device.
This strategy shall avoid the usage of ssh, telnet or any similar interface.
The device would be set with a factory default IP address and netmask (i.e. something like 192.168.1.1). Ideally, the strategy woudl also enable us to activate or de-activate DHCP support in those devices. The MAC addresses of the devices would be known information available that could be used in any kind of tool running on a Windows computer.
Does anyone know if any standard way of doing such a thing does exists? Any recommendation ensuring possible future portability on other platform than uClinux is welcome. A combination of standard Busybox tools or uCLinux available tools would be ideal.
Thanks in advance,
Francois
I think the best strategy is to use Zeroconf, which in embedded linux can be achieved with Avahi. The idea is that the device automatically assigns an IPv4 or IPv6 address to itself and resolves conflicts of addresses if necessary.
Devices can be discovered on the network and you can access them even if you have services running on the board. The best strategy is to have an IP alias on the network card with the zeroconf address and on the main interface you put the address you prefer
Does anyone know of a host that would allow this kind of code to run (any language):
socket.open(
"69.128.34.54", //any ip address basically
5555); // also any port
//write to socket...
//get response...
socket.close();
I am looking for pretty much any outbound IP, and pretty much any standard port (1024-65535). Note: these are for outbound only, no incoming other than ofc your standard port 80.
For your standard shared hosting:
Ugh, I doubt you'll find one that openly allows that, seeing it's wide open, and from a security point of view, dangerous.
However, is there any way you can limit the ports (UDP/TCP) to a smaller range? Doing so would alleviate the stress a web host will feel when they get this request.
For semi dedicated / private / dedicated hosts
If you're willing to pump out the dough, I believe WebHost4Life might, Arvixe might, but you'd have to trim down the ports.
Again, spreading a firewalls outgoing ports wide open is bad for a web server.
Is there any way to identify a users machine through a browser without previously putting cookies in? Probably no access to Mac Address through the web right? Just thought I'd ask...
There is no such identity element, and even if there were, the nature of the HTTP protocol would not prevent it from being spoofed.
In short: No.
This was partly why Intel tried to have unique processor IDs a few years back, but that didn't ever take off. (Which is good as now we have multi-core machines.)
Just install a cookie on the box. IP address is no good because of Natting. Someday we'll have IPv6 to do this correctly.
You could retrieve an IP address, but it frequently wouldn't mean much (if anything). If you retrieve the IP address the client is using, you'll get a whole lot of them that are 192.168.*. If you retrieve the address your server sees, it won't match that, and you might easily see several (possibly hundreds or even thousands) of machines with the 'same' IP address.
If you put those two together, you'll get something that's unique for the moment, but is subject to change at any time. The client's local IP address may change when their DHCP lease expires and their global IP address may change anytime they reboot their router (unless they have a static IP address, which you mostly don't have any way of knowing).
My bank website has a security feature that let me register the machines that are allowed to make banking transactions. If someone steals my password, he won't be able to transfer my money from his computer. Only my personal computers are allowed to make transcations from my account. So...
What are the approaches to restrict the access to a group of machines in a web system?
In other words, how to identify the computer who made the http request in the web server?
Why not using a clients certificate inside the certificate store of an authorized host or inside a cryptographic token such as smartcard that can be plugged into any desired computer?
Update: You should take into account that uniquely identifying a computer means obtaining something that is at a relative low level, unaccessable to code embeded in an html page (Javascript, not signed applet or activeX), unless you install something in the desired computer (or executing something signed such as an applet or activeX).
One thing that is unique per computer is the MAC address of the Ethernet card, that is almost ubiquitous on every rather modern (and not so modern) computer. However that couldn't be secure enough since many cards allow changing its MAC address.
Pentium III used to have an unique serial number inside CPU, that could fit perfect for your use. The downside is that no newer CPUs come with such a thing due to privacy concerns from most users.
You could also combine many elements of the computer such as CPU id (model, speed, etc.), motherboard model, hard disk space, memory installed and so on. I think Windows XP used to gather such type of information to feed a hash to uniquely identify a computer for activation purposes.
Update 2: Hard disks also come with serial numbers that can be retrieved by software. Here is an example of how to get it for activation purposes (your case). However it will work if sb takes the HD to another computer. Nonetheless you can still combine it with more unique data from computer (such as MAC address as I said before). I would also add a unique key generated for a user and kept in a database of your own would (that could be retrieved online from a server) along with the rest to feed a hash function that identifies the system.
Did you actually install something?
Over and above what Mark Brittingham mentions about IP addresses, I suppose some kind of hash code that is known only to your bank's computer and your computer(s) would work, provided you installed something. However, if you don't have a very strong password to begin with, what would stop someone from "registering" their computer to steal money from you?
I would guess your bank was doing it by using a trusted applet - my bank used to have a similar approach (honestly I thought it was a bit of a hassle - now they're using a calculator-like code generator instead). The trusted applet has access to your file system, so it can write some sort of identifier to a file on your system and retrieve this later.
A tutorial on using trusted applets.
I'm thinking about using Gears to store locally a hash-something to flag that the computer is registered.
If you are looking for the IP address of the computer that makes an account-creation request, you can easily pull that from the Request. In ASP.NET, you'd use:
string IPAddress = Request.UserHostAddress;
You could then store that with the account record and only accept logins for that account from that IP address. The problem, of course, is that this will not work for a public site at all. Most people come through an ISP that assigns IP addresses dynamically. Even with an always-on internet connection, the ISP will occasionally drop and re-open the connection, resulting in a change of IP address.
Anyway, is this what you are looking for?
Update: if you are looking to register a specific computer, have you considered using cookies? The drawback, of course, is that someone may clear their cookies and thus "unregister" their computer. The problem is, the web only has so much access to your computer (not much) so there is no fool-proof way to "register" a computer. Even if you install an ActiveX control, they could uninstall or delete it (although this is more persistent than a cookie). In the end, you'll always have to provide the end-user with some method for re-registering. And, if you do that, then you might as well have then log in anyway.
Problem:
I need to design a networking application that can handle network failures and switch to another network in case of failure.
Suppose I am using three ethernet connections and one wireless also . At a particular moment only one connection is being used.
How should I design my system so that it can switch to another network in case of failure.
I know this is very broad question but any pointers will help!
I'd typically make sure that there's routing on the network and run one (or more) routing protocol instances on the host. That way network failure is (mostly) transparent to the application, as the host OS takes care of sending packets the right way.
On the open-source side, I have good experiences with zebra and quagga, at least on linux machines.
Create a domain model for this, describing the network elements, the kind of failures you want to be able to detect and handle, and demonstrate that it works. Then plug in the network code.
have one class polling for the connection. If poll timeout fires switch the ethernet settings. For wireless, set the wifi settings to autoconnect and then just enable/disable the wificard.
(But I dont know how you switch the ethernet connection)
First thing I would do is look for APIs that will give me network disconnection events.
I'd also find a way to check the state of the network connections.
These would vary depending on the OS and the Language used so you might want to have this abstracted in your application.
Example:
RegisterDisconnectionEvent(DisconnectionHandler);
function DisconnectionHandler()
{
FindActiveNetworkConnection();
// do something else...
}
A primitive way to do it would be to look out for network disconnection events. Your sequence would be:
Register/poll for network connections status changes. Maintain a list of all active network connections.
Use the first available network connection (Alternately you could sort it based on interface bandwidths, and use the one with highest bandwidth).
When you detect a down connection, use the next active one.
However, if there are implications to the functionality of your application, based on which network connection you use, you are much better off, having either a routing protocol do the job for you, or have a tracking application within your application. This tracking application would track network paths (through various methods like ping, traceroute, etc) across all your available interfaces to see which one can reach the ultimate destination, and use the appropriate network interface.
Also, you could monitor your network interfaces for not just status changes, but also for input/output errors, and change your selection accordingly. This would help you use the most efficient network at any given point of time. But this would need to be balanced with the churn caused by switching a network connection.
If you control all of the involved hosts, Multipath TCP will probe all of your connections and automatically choose the one that works; if multiple connections are working, it will load balance across them.
If you don't control the endpoints, there's no choice but doing the probing in the application. Mosh is an example of an application that does that quite elegantly.
You didn't mention what your application does; perhaps it would be possible to redesign your protocol so that it uses all available connections simultaneously, the way BitTorrent does, and therefore doesn't care about some links being down at any given time?