I have a VPN setup where clients authenticate using pre-shared certificates. I want these clients to use my http api written in flask but I need them to authenticate first to return correct data from database.
Is it safe to use request.remote_addr or request.environ['REMOTE_ADDR'] to identify users given I know IP address of every client from VPN config?
e.g.
user = select_user(request.remote_addr)
where select_user(IP) maps VPN clients to IP addresses.
The REMOTE_ADDR will always be the IP of the TCP connection emitter, there is no way to modify it for a potential attacker (except proxy). But there is a vulnerability if someone can access to one of your user's network (as they will have a valid IP). So if you can really trust your users personal network security, yes it is safe, otherwise no.
Related
I have never used OPC-UA before, but now faced with a task where I have to pull data from a OPC-UA machine to push to a SQL database using python. I can handle the database part, but how to basically connect to the OPCUA server when I have only the following fields available?
IP address 192.168.38.94
Port 8080
Security policy: Basic256
Username: della_client
Password: amorphous##
Some tutorials I saw directly use a url, but is there any way to form the URL from these parameters, or should I ask the machine owners something more specific to be able to connect? I just want to be sure of what I need before I approach him.
Related, how to use the same parameters in the application called UA-Expert to verify the connections as well? Is it possible?
If it is relevant, I am using python 3.10 on Ubuntu 22.04.
You need to know which protocol is used. Then you can create the URLs by using the IP address as domain:
OPC UA binary: opc.tcp://ip:port
https https://ip:port
OPC UA WebSockets opc.wss://ip:port
http http://ip:port (Deprecated in Version 1.03)
In your example this could be opc.tcp://192.168.38.94:8080 or https://192.168.38.94:8080
In most cases, the binary protocol is used. But the port 8080 is a typical http(s) port.
The credential and the securityPolice are needed later in the connection process.
And yes: You can test the URLs with the UaExpert. You can finde a step-by-step tutorial in the documention
How do I change the IP of HTTP requests in python?
My friend built an API for a website, and sometimes it blocks certain IP's and so we need to change the IP of the request... here is an example:
login_req = self.sess.post('https://www.XXX/YYY', params={...}
Now, each request that it sends, is through the computer's IP, and we need it basically to pass through an imaginary VPN.
Thanks for the help. If something isn't clear I will explain.
Short answer: you can't.
Long answer: it seems like you're misunderstanding how IP addresses work. Your IP address is the network address that corresponds to your computer - when you send a request to a server, you attach your IP as a "return address" of sorts, so that the server can send a response back to you.
However, just like a physical address, you don't get to choose what your IP address is – you live on a street, and that's your address, you don't get to change what the street is called or what your house number is. In general, when you send a request from your computer, the message passes through a chain of devices. For example:
Your computer --> Your router --> Your ISP --> The Server
In a lot of cases, each of these assigns a different IP address to whatever's below it. So, when your request passes through your router, your router records your IP address and then forwards the request through your ISP using its own IP address. Hence how several users on the same network can have the same IP address.
There are physical IP addresses, that correspond directly to devices, but there are a limited amount of these. Mostly, each Internet Service Provider has a few blocks of IP addresses that it can attach to things; an ISP can keep a specific IP address pointed to a specific computer all of the time, but they don't have to, and for many of their regular users, they don't.
Your computer has basically no power to determine what its own IP address is, basically. There's nothing python can do about that.
Your Question:
we need [the request] basically to pass through an imaginary VPN.
It'd be easier to actually requisition a real proxy or VPN from somewhere and push your request through it. You'd have to talk with your internet service provider to get them to set something like that up for you specifically, and unless you're representing a reasonably big company they're unlikely to want to put in that effort. Most python libraries that deal with HTTP can easily handle proxy servers, so once you figure it out it shouldn't be a problem.
You can use an IP address from https://www.sslproxies.org/
For example,
import requests
response=requests.get("yourURL", proxies={'https': 'https://219.121.1.93:80', 'http': http://219.121.1.93:80 "})
The IP addresses on that site are pretty crappy and sometimes don't work, so it would be best to find a way to constantly scrape IP addresses from the site so you have a couple to try. Check out this article: https://www.scrapehero.com/how-to-rotate-proxies-and-ip-addresses-using-python-3/
warning: These should not be used for sensitive information as they are not secure. Don't use those IP addresses unless you are ok with anyone in the world knowing what your're doing.
I am hosting a http server on Python using BaseHTTPServer module.
I want to understand why it's required to specify the IP on which you are hosting the http server, like 127.0.0.1/192.168.0.1 or whatever. [might be a general http server concept, and not specific to Python]
Why can't it be like anybody who knows the IP of the machine could connect to the http server?
I face problems in case when my http server is connected to two networks at the same time, and I want to serve the http server on both the networks. And often my IP changes on-the-fly when I switch from hotspot mode on the http server machine, to connecting to another wifi router.
You must specify the IP address of the server, mainly because the underlying system calls for listening on a socket requires it. At a lower level you declare what pair (IP address, port) you want to use, listen on it and accept incoming connexions.
Another reason is that professional grade server often have multiple network interfaces and multiple IP addresses, and some services only need to listen on some interface addresses.
Hopefully, there are special addresses:
localhost or 127.0.0.1 is the loopback address, only accessible from local machine. It is currently used for tests of local services
0.0.0.0 (any) is a special address used to declare that you want to listen to all the local interfaces. I think that it is what you want here.
Try running it on 0.0.0.0, this accepts connections from all interfaces. Explicitly specifying the IP is a good practice in general (load balancing, caching servers, security, internal netwrok-only micro services, etc), but judging by your story this is not a production server, but some internal LAN application.
I successfully setup authentication and user based authorization following the pyramid documentation.
Now I want to disable this authorization if the side is accessed from localhost. How can I make my authorization depending on the client IP address, i.e. localhost?
There are two ways by which you can get the client side IP address.
Using remote_addr or you can use client_addr.
We have a custom built program that needs authenticated/encrypted communication between a client and a server[both in Python].
We are doing an overhaul from custom written Diffie-Hellman+AES to RSA+AES in a non-orthodox way. So I would be very interested in comments about my idea.
Prequisites: Klient has a 128bit RegistrationKey which needs to remain a secret during the authentication - this key is also the only shared secret between the server and client.
Client contacts the server over an insecure channel and asks the servers RSA PubKey
Client then queries the server:
[pseudocode follows]
RegistrationKey = "1dbe665ac7a944beb67f106f779e890b"
clientname = "foobar"
randomkey = random(bits=128)
rsa_cp = RSA(key=pubkey, data=randomkey+clientname)
aes_cp = AES(key=RegistrationKey, data=RegistrationKey+rsa_cp)
send(aes_cp)
3. Server then responds:
[pseudocode follows]
# Server decrypts the data and sees if it has a valid RegistrationKey, if it does...
clientuuid = random(bits=128)
sharedkey = random(bits=128)
rsa_cp = RSA(key=privkey, data=clientuuid+sharedkey)
aes_cp = AES(key=randomkey[got from client], data= rsa_cp)
send(aes_cp)
Now both sides know the "clientuuid", "sharedkey" which the client can use later to authenticate itself. The method above should be secure even when the attacker learns the regkey later since he would have to crack the RSA key AND man-in-the-middle attacks(on RSA) should stop the auth. from completing correctly.
The only possible attack method I see would be the case where the attacker knows the regkey AND can alter the traffic during the authentication. Am i correct?
I really want to hear your ides on what to add/remove from this method and If you know a much better way to do this kind of exchange.
PS! We are currently using Diffie-Hellman(my own lib, so it probably has flaws) and we have tried TLSv1.2 with PreSharedKeys(didn't work for some reason) and we are CONSTRICTED to http protocols since we need to do this in django. And because we are doing this in http we try to keep the request/answer count as low as possible(no sessions would be the best) - 1 would be the best :)
If you have any questions about the specifics, please ask.
So, you crypto/security geeks, please give me a helping hand :)
Don't re-invent the wheal, use HTTPS.
The server can issue certificates to the client and store them in the Database. Clients can be distributed with the server's self-signed certificate for verification. The server can verify clients by using Apache's HTTPS Environment Variables.
No. Use SSL. Reinventing cryptosystems is a bad idea.
What you can easily do is set up a reverse proxy. Run your Django app on a higher port (e.g., 8080) and set it to respond only to connections from the loopback address (127.0.0.1). Run the reverse proxy on port 443 (standard HTTPS port) and proxy all requests to the Django app. But setup the reverse proxy with the site's certificate and have it be an SSL endpoint. The proxied requests going to the Django app would then just be "regular old" HTTP, not HTTPS.
Apache Mod_Proxy
NginX as a Reverse Proxy
I don't think RegistrationKey adds any real security.
It needs more nonces (against replay attacks).
It needs more padding (or else the messages are small and thus easy to decrypt).
An algorithm can be proven to be secure, you may want to do this.
Most flaws in crypto are in the implementation, not in the algorithm (timing attacks, for example).