I have a PUSH/PULL set up, but there is nothing stopping someone who know the IP address and port where the PULL socket is binding and sending garbage to it. What is the correct way to prevent this and only allow client I have authorized to connect to it?
If this isn't possible can I just tell the socket to only accept one (the first) connection and ignore any subsequent ones?
Are you using ZeroMQ >= 4.0? If so then you can take advantage of the new security features. Pieter Hintjens gives the overview on his blog: http://hintjens.com/blog:48
The PLAIN authentication method allows simple username / password authentication. See the documentation here: http://api.zeromq.org/4-1:zmq-plain
Related
Gooday to All, Im writing down a very sensitive web application that functions like a file browser, Instead of using sftp/ftp or ssh. It uses purely http/https. Im using request.remote_addr to determine the client's IP address. and reject if the ip isn't on the list.
good_ips = ['127.0.0.1','192.168.1.10','192.168.1.1']
if request.remote_addr in good_ips:
pass
else:
sys.exit()
It works fine, but I just would like to ask how reliable and safe this is :).
This would be the result if the ip is not on the list. other wise the site would run fine :D.
Thank you and good day!
No, that's not sufficient to build a "sensitive" service as you are using it.
See https://en.wikipedia.org/wiki/IP_address_spoofing for just a start on what could go wrong.
You should use authentication, such as with a public key (which SSH supports), or a password. Kerberos is also a possibility.
Whether source IP filtering is an adequate measure for you depends on your exact scenario, your threat model. #JohnZwinck is right in that it usually is not enough by itself, but for some applications, it can be.
While it is easy to fake source IP in individual IP packets, http goes over tcp, and a modern implementation of tcp is protected against address spoofing. Older implementations of TCP (in older operating systems) are vulnerable though. So if your server has a recent OS, it is not at all straightforward to spoof a source IP. It's probably easier to compromise a client with an address in the allowed list.
Another thing that can go wrong is related to network address translation (nat). Suppose you restrict access in your application to internal IP addresses (192.168.0.0/24). All works well, but your security department decides there need to be reverse proxies for all web applications. A proxy is deployed and all works fine. However, now your application receives all requests from the proxy wuth an internal address, so the restriction in the application doesn't make much sense anymore. Something simlar can also happen with clients, in some scenarios, clients may be behind nat, meaning they will all have the same apparent client IP address - which can be good or bad.
The best practice is of course to have proper authentication (via passwords, client certificates, or multi-factor, etc., however secure you want it to be), with IP restriction being an additional layer to provide more security.
How can I check if a FTP server allows for TLS when I connect using ftplib? I Found easy documentation on how to use TLS, but no solution on how to check for it. My script is supposed to connect either way, but use TLS if possible.
So do I just connect using TLS and if it fails I do it without? I am sure there must be a better way.
Thank you for your help.
Note that trying an encryption only, is as bad as not using any encryption at all. And maybe even worse, as it gives an impression of security, while there's none.
When you are under an MITM attack, an attacker will divert a TCP traffic to him/her and simulate encryption rejection, making you send your credentials plain-text straight to the attacker.
Anyway:
Call FTP_TLS.auth, check if it throws or not.
Call FTP_TLS.login with secure=False.
If the server supports TLS, the FTP_TLS.auth will enable encryption and the FTP_TLS.login (even with secure=False) will continue using it. If the server does not support encryption, the FTP_TLS.login (with secure=False) continues unencrypted.
Note that FTP_TLS.login (with its secure parameter) is an undocumented method - If you do not want to use it, you can fallback to creating a plain FTP, when FTP_TLS.auth throws.
To check explicitly, you can also use FTP.voidcmd('FEAT') and look for AUTH TLS (or AUTH SSL) in the response.
But there's nothing wrong about trying AUTH TLS/AUTH SSL (what the FTP_TLS.auth does) straight away.
I'm writing a Socket Server in Python, and also a Socket Client to connect to the Server.
The Client interacts with the Server in a way that the Client sends information when an action is invoked, and the Server processes the information.
The problem I'm having, is that I am able to connect to my Server with Telnet, and probably other things that I haven't tried yet. I want to disable connection from these other Clients, and only allow connections from Python Clients. (Preferably my custom-made client, as it sends information to communicate)
Is there a way I could set up authentication on connection to differentiate Python Clients from others?
Currently there is no code, as this is a problem I want to be able to solve before getting my hands dirty.
When a new connection is made to your server, your protocol will have to specify some way for the client to authenticate. Ultimately there is nothing that the network infrastructure can do to determine what sort of process initiated the connection, so you will have to specify some exchange that allows the server to be sure that it really is talking to a valid client process.
#holdenweb has already given a good answer with basic info.
If a (terminal) software sends the bytes that your application expects as a valid identification, your app will never know whether it talks to an original client or anything else.
A possible way to test for valid clients could be, that your server sends an encrypted and authenticated question (should be different at each test!), e.g. something like "what is 18:37:12 (current date and time) plus 2 (random) hours?"
Encryption/Authentication would be another issue then.
If you keep this algorithm secret, only your clients can answer it and validate themselves successfully. It can be hacked/reverse engineered, but it is safe against basic attackers.
I'm looking to create a Twisted Conch Server/Client SSH application similar to the below:
Client <---Key1---> Server/Client <---Key2---> Server
I guess it's like an SSH MITM or command proxier.
I have read the answers to similar Twisted related questions, such as:
Twisted server-client data sharing
and I understand the theory behind passing client/server data.
The part I am unsure of is the user authentication. I want to pass the login details from the first client, through my twisted conch application to the endpoint server.
Is there a way to do this?
Also, would it be possible to do separate SSH key negotiations but then pass all data, including credentials and any commands typed, between server and client?
Unfortunately, this is a little more complicated than it seems. SSH goes through some pains to try and avoid this kind of MITM. If you don't use the same key negotiation, the publickey authentication won't succeed because string you're signing is different on both sides of the connection (see the RFC section 7 for more).
Password authentication should still work okay, though. The easiest way to do that would be to create a twisted.conch.ssh.session.SSHSession subclass which listens for packets on the packetReceived method and forwards them to the corresponding transport.sendPacket.
When using telnetlib I noticed some interesting variables:
AUTHENTICATION = chr(37) # Authenticate
XAUTH = chr(41) # XAUTH
PRAGMA_LOGON = chr(138) # TELOPT PRAGMA LOGON
SSPI_LOGON = chr(139) # TELOPT SSPI LOGON
Also, this page lists some RFCs which describe AUTHENTICATION option in detail.
If I understand correctly, if a telnet server supports authentication I should be receiving IAC DO AUTHENTICATION when connecting to it. However, when trying to connect to telnetd on a Linux machine I do not receive this option and so I can't send IAC WILL AUTHENTICATION.
Is my understandng correct? Is there a way I can ask the server to perform authentication? Is it even possible to authenticate telnet session automatically? (without listening to "Login:", "Username:", "Password:" and similar prompts)
Yes, you are understanding RFC 1416 correctly. The server should send DO first, if it supports authentication. You can try sending WILL anyway but that'll be against the spec and probably won't work anyway.
By Linux telnetd, you probably mean the netkit telnetd. And as far as I can see on its manpage:
-a authmode This option may be used for specifying what mode should be used for
authentication. Note that this option is only useful if telnetd has
been compiled with support for authentication, which is not available
in the current version. [...]
So I'd simply say it can't do that. I'm using the OpenBSD telnetd (telnet-bsd package in Gentoo); it seems to have some auth bits but I wasn't able to get it to work at all. I suspect it only supports Kerberos-based auth.
Looking at the authentication types list in RFC 2941, it seems that most authentication types were never even specified. Looking at those which are, DSS/DSA is mostly interesting (it is used in SSH as well) but I guess it will be really hard to find a compliant server and client. Sadly, it seems that there were no proposals for simple (plaintext) authentications there.
So, to sum up: yes, it would be possible if someone implemented it. But since telnet is practically dead, I doubt you'll find server implementations for that. And even if you did, you'd have to write the client-side yourself which won't be that easy with the supported schemes. So I doubt it's worth the effort.