One of my stand-alone java applications (no sources available) picks random-available port to listen on.
At this stage I assume it uses getaddrinfo system call to obtain addresses to bind against.
Since I'm maintaining hundreds of various servers with assigned ports, the black app sometimes kicks in and pick one of 'the assigned' ports, which cause my small servers to fail on startup...
I'm wondering is there a way to restrict number of ports proposed by the OS?
Would be mostly interested in system config solutions,
but if there are no other solutions I'm also able to hack bind()/getaddrinfo (this would require some hits as well ... )
thanks
You must be able to control it from proc entries - For example, here is a system wide setting :
/proc/sys/net/ipv4/ip_local_port_range
You can modify them. Or there may be utilities available for the same purpose.
If OS-wide change is not what you had in mind, configure the JVM's Java Security Manager so that SecurityManager.CheckListen(NNN) throws SecurityException for any of the port numbers you want to reserve.
Take a look on:
http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec70.html
It's the solution for my problem, than I could limit port ranges
Related
I am using libcurl with pthreads to do some POST requests to a single website. This website may change over time. I want this program to be as fast as possible. So one thing came to my mind was to first find the website IP address, then pass this IP instead of the website URLs to threads.
At first, do you think this is a good thing to do? As it removes the DNS lookup time in each connection (thread).
And how can I do this in libcurl? Is there any function to just find the IP of a hostname? Or is there any other simple way to do this in C language?
This is the problem that the DNS query system in your OS is supposed to solve.
The performance improvement you want by not doing an additional lookup is countered by the fact that the IP can change over time. Any queries should be cached presumably respecting some record timeout rules set by the DNS entry. Windows and OS X cache requests automatically out of the box as far as I can tell. On my debian box I found I had to enable the systemd-resolved service for this feature. Not knowing your needs, is probably the most sane general solution to what you're describing.
Doing this with getaddrinfo() and caching it yourself for some period of time within the bounds of your program (even to disk) is a valid solution if you want absolute control and don't want to hardcode it somewhere (in the app or something like the hosts file).
I'm trying to come up with a way to sync a sqlite database between two computers.
If this were on a machine with a public IP this would not be difficult but I'm trying to find a way to make this work for ANY two devices, and most computers don't have a static IP.
What are some of the ways I can tackle this problem?
Assuming you just need to find the peers IP address...
Broadcast a Udp packet onto Lan, if machines are same lan segment. You can also try using admin scoped multicast, but mileage will vary according to the network setup and gear in use.
If trying to find two machines across the internet (assuming you can solve the NAT address translation issue), you need to bounce off a node that will hold info for you. Eg write a packet to dweet.io or sparkfun or other website that will hold store and forward data. You can also read twitter feeds etc, basically you need a known reference point to both talk too. Look into how malware create command and control networks for some ideas. Or search for rendezvous servers and protocols.
If the address range is small, probe all possible addresses. But be careful as you might trigger anti virus or ISP action
If wanting more browser based, look at webrtc, not quite what you are after but some of the techniques for discovery might be interesting.
If you have access, you can play with your DNS records. Essentially this is a variation of (2).
There are more options too, but that get more special purpose or become a bit too stelthy for general use. Also see how mesh networks are formed.
I am using 80(http) and 443(https) default ports for my webserver.
What ther ports other than this can i use for my webserver.
I need this basically to start my webserver using non-default ports.
Any. Look at these for the ones to not use:
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
You can use whatever ports you want to use, provided no other server on your box is also trying to use it.
This is, of course, subject to any OS-specific issues like needing to run with elevated privileges for binding to ports below 1024.
The IANA (naming authority) and ICANN (assigned names and numbers) is responsible for assigning ports to specific applications but there's nothing requiring you to follow those "rules" at all.
If you use (for example) port 23 for your HTTP server, that will work. It's likely to confuse any telnet programs attempting to connect to that box but, as stated, the box is under your jurisdiction, not that of the IANA. Provided your browsers hook up to the specific port 23, they'll work just fine.
By way of example, many IBM mainframe systems will use port 23 for their 3270-protocol terminal programs and bump "real" telnet up to port 1023.
And, in any case, why should you not use a port because it's "allocated" to the Quake game server, or Dropbox, or Symantec bloatware? :-)
I have a server that binds to a specific IP address (In a linux system). We are considering the option to bind(0), ie to bind to ANY interface. Are there any problems with this?
Depends. You may
want to have different processes binding to different IPs. In this
case you don't want any to bind to all.
want the server to be
accessible only from internal network (for instance, when the other
interface is accessible from the outer world).
want something that I can't think of at the moment.
basically, it's not the binding that has disadvantages, but the effect thereof and it all depends if this is what you want.
The most obvious issue would be that if you depend on network topology to provide access control and safety (firewalls etc) then the presence of multiple interfaces might mean that not all access to the server is being protected at the same degree. This could especially be a problem if interfaces are added or changed in the future.
Also, if your server has a notion of "its own IP" for its own purposes and it is not programmed for the eventuality that different client connections will be established to different "local" IPs then that might present a problem -- of course, you 'd need to read the source to weigh in on this.
Let's suppose you deploy a network-attached appliances (small form factor PCs) in the field. You want to allow these to call home after being powered on, then be identified and activated by end users.
Our current plan involves the user entering the MAC address into an activation page on our web site. Later our software (running on the box) will read the address from the interface and transmit this in a "call home" packet. If it matches, the server response with customer information and the box is activated.
We like this approach because it's easy to access, and usually printed on external labels (FCC requirement?).
Any problems to watch out for? (The hardware in use is small form factor so all NICs, etc are embedded and would be very hard to change. Customers don't normally have direct acccess to the OS in any way).
I know Microsoft does some crazy fuzzy-hashing function for Windows activation using PCI device IDs, memory size, etc. But that seems overkill for our needs.
--
#Neall Basically, calling into our server, for purposes of this discussion you could call us the manufacturer.
Neall is correct, we're just using the address as a constant. We will read it and transmit it within another packet (let's say HTTP POST), not depending on getting it somehow from Ethernet frames.
I don't think that the well-known spoofability of MAC addresses is an issue in this case. I think tweakt is just wanting to use them for initial identification. The device can read its own MAC address, and the installer can (as long as it's printed on a label) read the same number and know, "OK - this is the box that I put at location A."
tweakt - would these boxes be calling into the manufacturer's server, or the server of the company/person using them (or are those the same thing in this case)?
I don't think there's anything magic about what you're doing here - couldn't what you're doing be described as:
"At production we burn a unique number into each of our devices which is both readable by the end user (it's on the label) and accessible to the internal processor. Our users have to enter this number into our website along with their credit-card details, and the box subsequently contacts to the website for permission to operate"
"Coincidentally we also use this number as the MAC address for network packets as we have to uniquely assign that during production anyway, so it saved us duplicating this bit of work"
I would say the two obvious hazards are:
People hack around with your device and change this address to one which someone else has already activated. Whether this is likely to happen depends on some relationship between how hard it is and how expensive whatever they get to steal is. You might want to think about how easily they can take a firmware upgrade file and get the code out of it.
Someone uses a combination of firewall/router rules and a bit of custom software to generate a server which replicates the operation of your 'auth server' and grants permission to the device to proceed. You could make this harder with some combination of hashing/PKE as part of the protocol.
As ever, some tedious, expensive one-off hack is largely irrelevant, what you don't want is a class-break which can be distributed over the internet to every thieving dweep.
The MAC address is as unique as a serial number printed on a manual/sticker.
Microsoft does hashing to prevent MAC address spoofing, and to allow a bit more privacy.
With the only MAC approach, you can easily match a device to a customer by only being in the same subnet. The hash prevents that, by being opaque to what criteria are used and no way to reverse engineer individual parts.
(see password hashing)
From a security perspective, I know that it is possible to spoof a MAC, though I am not entirely sure how difficult it is or what it entails.
Otherwise, if the customers don't have easy access to the hardware or the OS, you should be fairly safe doing this... probably best to put a warning sticker on saying that messing with anything will disrupt communication to the server.