Here's the issue...
I work in a remote area of Alaska where cell service can be... questionable. We do have decent WiFi, however, is not openly available to staff because it has a low enough data limit that we don't want to deal with people streaming Netflix and running out the company data.
The big issue is that we want to use an app like Slack or Discord to communicate more effectively across the business. Because the cell service is spotty and the WiFi is currently off-limits, I was wondering if there was a way for me to create a WiFi network that was whitelisted to only allow Slack, for example. Then we get the benefits of using the WiFi without risking running out of data.
Thoughts? I was thinking about setting up a network proxy, but I wanted to get the internet's take on it before I dive down the rabbit hole.
The best way I can think of to handle something like this is to use a router that you can configure the dns server settings and block all dns entries that aren’t on your allowlist. This doesn’t strictly block traffic to everywhere but it will do a pretty good job.
You could also block all dns traffic that’s not going to the local dns server which would help not allow people around it. To have a hard block on things you would need to block specific options addresses which with services such as slack or discord could change randomly which would be hard to keep up on.
Another option that would work well is use your own self hosted version of mattermost, rocket.chat, or riot/matrix that you would have control over and knowledge of the IP address so that you can allowlist only those up addresses. The other advantage with this is if the business is just localized communication and you don’t need to chat across long distances then you could set this to work completely on a network with no internet access so you wouldn’t have to do any blocking because the wifi is completely separated from the internet.
Things are heavily based on your situation but I hope this gives you a good place to start
I am trying to write a program that scan an ip range and detect if an ip is address of a router or not.
Currently i used traceroute from my computer to all host in the network. However, i believe there must be some way to directly "ask" a host at an ip if it is a router or not?
by the way, do you know any program/ opensource already does this?
Routers are supposed to talk couple of protocols (actually a neat bunch) that regular IP nodes do not, and then there are some which are more common (i.e. even non-router nodes do).
Router-only protocols:
VRRP
IGRP / EIGRP
OSPF
BGP
RIP
You could do active-probing on those, i.e. send a packet (behaving as if you are another router, or an end-node) and checking to see what kind of response the router (if at all) sends.
Alternatively you could do passive-probing, like 'sniffing', i.e. watching out for the kind of IP packets being sent out by various nodes. There are some which are usually sent out by Routers only (again, mostly from the above list).
Common protocol, but that can actually tell you a lot:
SNMP (esply the unsecure one's like v1/v2, are easy to deal with, without having to establish a secure session)
Other ways:
Portscanning (actually can tell you a real lot), for example all routers have some management ports (although, often they are locked down due to security concerns)
What you want to do is often what many 'Network Management' software do, to "discover" capabilities / functionality of other nodes in the network. And, there isn't a single size-fits all solution. They use bunch of different methods, heuristics to finally figure out what the other node is.
Any node which is hopped to and not just an endpoint is a router. However, this doesn't allow you to detect routers with no reachable devices hooked up. (Any input as to whether my answer has merit would be great!)
Here is my situation. I am part of a project creating a P2P charity website, where users connect and can give money to one another. Because of the nature of the site, we know scammers are going to be rampant. We have several preventative measure ideas, and one idea that came up was tying an IP address to the user's account. The reason for this would be to be able to detect when someone from the same IP address creates several accounts.
Would this be reliable? Why, or why not? I have been googling and found many conflicting ideas on the subject. Thanks for any help you can give.
No, it is not reliable. Because:
Residential customers who aren't specifically paying for a static IP address will often see their addresses change frequently. I'm on AT&T DSL and I see my IP address change roughly twice per month on average
People legitimately sharing an internet connection, whether they're using different workstations in the same office with a T1 line, or they're all connected to the same Wi-fi hotspot at Starbucks, will all have the same IP address.
Related to the above, people who are mobile, such as people who use laptops to connect to Wi-fi at coffee shops, airports, hotels, etc, will have a different IP address for each location they visit.
Even people who stay in one place with a static IP address can spoof your system by using a proxy server or a proxy tool like Tor. This makes IP restrictions trivial to bypass.
No.
Many connections are behind NAT (One public gateway IP address for many people), or use DHCP (frequently changed IP addresses).
An IP address is one of the worst ways of identifying a user.
There is a dicussion board I am part of that bans sock puppets ( that is, multiple accounts by the same user ). They have no means of automatically detecting them, becasue there is no means of definitively identifying them. IP addresses are captured, because they can be used to help identify sock puppets, but I know that the process of identifying these is laborious, manual, and error-prone.
This is only undertaken when there is suspicion that someone is using sock puppets for malicious or disruptive purposes. In your case, there is no real answer other than careful and manual monitoring of usage habits, using the information that you gather about users to attempt to identify suspicious habits. But you also have to accept that 80% of sock puppets will go undetected, and do what you can to warn other users of the possibility.
Your bigger issue, incidentally, may be Munchausen by Internet which we were also caught by.
No, not least because:
IP Addresses can change over time, thanks to DHCP leases expiring.
People access websites from many different locations including home, work, coffee shops, etc.
When behind a NAT firewall or a proxy server, many people can share the same IP address.
Will you have many people registering who are entitled to receive money? I'd suggest a manual verification process using real people if at all possible. If nothing else, you can claim to be exercising due diligence if there's a human involved.
No: for example, any company proxy will only have one external IP address, so everyone registering from within the network will appear to have the same IP address.
Recent legal case perhaps worth reading up on : http://yro.slashdot.org/story/11/05/03/2020205/An-IP-Address-Does-Not-Point-To-a-Person-Judge-Rules
Totally unreliable...
Somebody on dial-up will have a different IP address every time they "dial-up".
DSL users will have a different IP address every time they reset or reconnect their account unless they pay for a static IP.
Many users on a particular LAN will be sharing one public IP address.
A particular user can login from home, work, public hotspot and have a different IP from each location.
I do development for an ASP service, and we have recently went through a required 3rd party security audit to obtain status allowing us to host data for a certain government agency. So if I may share some of the information I gleaned turning the trainings, perhaps it would help.
First, IP addresses can be used to assist in what you are trying to accomplish, but they are definately not good by themselves. An example would be the wireless at McDonalds. Everyone at McDonalds is connected to the same wireless and are using the same public IP address through a NAT, which translates from a local address (i.e. 192.168.0.xxx) to a public address for all computers located behind it. The NAT keeps entries so it knows what traffic is allowed to come back into the network, and which computer it is going to.
We found that a good security measure is to use an encrypted session key that is included with all GET/POST submits. That session key contains a GUID which is a lookup to the current session. So even if someone breaks your session encryption, they still need to guess at a GUID in order to find a valid session. On top of that, by tracking IP addresses, if it changes suddenly, we can immediately invalidate the session (we also have whitelisting in case someone is load balancing multiple internet lines, which can cause the IP to change frequently). A cookie can also be used in place of the IP address tracking, as two people behind the same NAT can potentially hijack each other if they can find a way to steal the other person's session key.
Encrypted cookies are also a good way to enforce security. But make sure you are using a framework that is tried and tested, as they have already closed the known vulnerabilities for you. Believe it or not, our security company told us that .NET has emerged as one of the top secure frameworks that they know of. I almost fell out of my chair when I heard that.
Personally I don't think it'll be reliable.
The main reason will be for those using a shared IP. That includes most users connecting from inside a business and home users connecting through the same WIFI hub.
It's more than likely for multiple users to be coming to your site with the same IP address.
Adding to that the fact that IP addresses change over time and you're already losing track of your users.
It's also worth remembering that oftentimes multiple users will be using the same physical computer. Are you wanting to have only one member of a household able to signup etc?
It could be somewhat useful as part of a defense-in-depth approach, but I wouldn't call it "reliable".
If you want to identify users, you can use a cookie. One solution uses a combination of cookies, local storage, flash, and other state information that can be stored in a browser: http://samy.pl/evercookie/
Nothing is 100% reliable. These cookies can be erased by a determined user, or in some browsers with one click. Ultimately, in many countries outside of the USA, a user has the right not to be tracked.
As an alternative for the future: New Intel® Business Processors Deliver Leading Security, Manageability and Performance
As long as the connection between the browser and the CPU isn't interviened which I believe there is more risk of with a browser than a desktop application.
I have a network of computers connected in form of a graph.
I want to ping from one computer(A) to another computer(B). A and B are connected to each other through many different ways, but I want to PING via only a particular edges only. I have the information of the edges to be followed during pinging available at both A and B.
How should I do this?
You could source route the ping but the return would choose its own path.
Furthermore, source-routed packets are often filtered due to security concerns. (Not always, they are useful and sometimes even required at edge routers.)
If the machines are under your local administrative control, then you could ensure that source-routed packets are permitted. As long as you are able to start a daemon on machine B, you could also easily enough design your own ping protocol that generates source-routed echo returns.
Well, this is actually done by routing protocols that are configured on the media in between the computers (routers I expect). I think there isn't a way where you can say "use that specific route". The routers have different protocols (OSPF, EIGRP, RIPv2) and they do the load balancing. The only way you would be sure of one specific route is to use static routing, but this isn't dynamically done where your computer decides the route.
This is normal because :
if you would be able to chose a route, DoS would be quite easy to do to kill one route.
We're implementing a SIP-based solution and have configured the setup to work with RTPProxy. Right now, we're routing everything through RTPProxy as we were having some issues with media transport relying on ICE. If we're not mistaken, a central relay server is necessary for relaying streaming data between two clients if they're behind symmetric NATs. In practice, is this a large percentage of all consumer users? How much bandwidth woudl we save if we implemented proper routing to skip the relay server when not necessary. Are there better solutions we're missing?
In falling order of usefulness:
There is a direct connection between the two endpoints in both directions. You just connect and you are essentially done.
There is a direct connection between the two endpoints in one direction. In that case you just connect via the right direction by trying both.
Both parties are behind NATs of some kind.
Luckily, UPnP works in one end, you can then upgrade the connection to the above scheme
UPnP doesn't work, but STUN does. Use it to punch a hole in the NAT. There are a couple of different protocols but the general trick is to negotiate via a middle man that coordinates the NAT-piercing.
You fall back to let another node on the network act as a relaying proxy.
If you implement the full list above, then you have to give up very few connections and don't have to spend much time on bandwidth utilization at proxies. The BitTorrent protocol, of which I am somewhat familiar, usually stops at UPnP, but provides a built-in test to test for connectivity through the NAT.
One really wonders why IPv6 did not get implemented earlier - this is a waste of programmers time.
Real world NAT types survey (not a huge dataset, though):
http://nattest.net.in.tum.de/results.php
According to Google, about 8% of the traffic has to be relayed: http://code.google.com/apis/talk/libjingle/important_concepts.html
A large percentage (if not the majority) of home users uses NAT, as that is what those xDSL/cable routers use to provide network access to the local network.
You can theoretically use UPnP to open ports and set-up forwarding rules on the router to go through the NAT transparently. Unfortunately (or fortunately, depending on who you are) many users disable UPnP as a matter of course on their router and may not appreciate having to add forwarding rules manually.
What you might be able to do (and what Skype does AFAIK) is to have some of the users that have clear network paths and enough bandwidth act as relay nodes. Apart from the routing and QoS issues, you would at least have to find some way to ensure the privacy of any relayed data from anyone, including the owner of the relay node. In addition, there might be legal issues to settle with this approach, apart from the technical ones.