In the redis.conf the normal setting is
bind 127.0.0.1
I want redis to listen to another ip too (say my local development address)
I tried
bind 127.0.0.1, 123.33.xx.xx
but this does not work. I cannot find any relevant in the document or by googling. Hope someone can help.
Binding to multiple IPs is indeed possible since Redis 2.8. Just separate each IP by whitespace (not commas).
bind 127.0.0.1 123.33.xx.xx
Source: Official default config
This answer is not outdated and will work for both older and newer versions
The problem in understanding is that Redis binding doesn't show the client machine's address, but shows the interface through which connection should be established. In your example, if your local development (client) address is 123.33.xx.xx, it doesn't mean that you have to put exactly the same address as a binding, otherwise Redis service will not start.
So if ifconfig on your Redis server machine shows that you have some network interface similar to this:
eth0 Link encap:Ethernet HWaddr 00:0c:...
inet addr:192.168.1.110 Bcast:192.168.1.255 Mask:255.255.255.0
you can put the interface's address 192.168.1.110 as a binding and every request to Redis, which pass through this interface, should succeed.
Since:
--[ Redis 2.8 Release Candidate 1 (2.7.101) ] Release date: 18 Jul 2013
you can:
[NEW] Ability to bind multiple IP addresses.
Cheers!!
Edit: it seems that the correct way is, still, only one line and one or more IPs separated by space
This way:
bind 127.0.0.1 10.150.220.121
EDIT: This is an outdated answer. Please check newer answers for solution.
You cannot set redis to listen on specific multiple interfaces. If multiple interfaces are required just remove the bind line.
As #taro pointed out use firewall to restrict access.
I tried finding that answer too, as it stands, it's not possible to do this, I found this while searching for the answer on multiple (but not all interfaces). This is what turned up http://code.google.com/p/redis/issues/detail?id=497 stating it will not be supported by redis itself.
In conjunction with haproxy that makes it impossible to put it in front of redis in one go. You need to use a different port, or the other or choose to bind on 1 IP.
The only way this worked for me, was by adding separate lines:
bind 111.222.33.44
bind 127.0.0.1 ::1
bind 127.0.0.1 192.168.152.2
Note, I have to put the 127.0.0.1 first otherwise the 192.x will not be bound at system boot. However another systemctl restart redis will suffice -- might be a bug? (Debian 10 and Redis 5.0.3)
For macOS Homebrew installation, make sure you are editing /usr/local/etc/redis.conf instead of the template file: /usr/local/Cellar/redis/6.2.6/.bottle/etc/redis.conf
Related
I am trying to set up a STUN/TURN server on my local computer for a webrtc application of me. I decided to use coturn. Note that my server is running behind a NAT.
So i fired up my Ubuntu VM and installed it. After reading through the wiki I got it working, atleast on my local network. For testing purposes, i use this site. Therefore, when i try it there with 192.168.178.25:3478, it works. When i try it with "public-ip":3478, it doesnt.
This told me, it is working locally and it should be a port/NAT issue. What i did:
1) I set the VM to Bridging
2) I opened the port 3478 on my router. To test if this is really working, i used telnet on a remote machine and it worked. Another test was that i set up a quick apache server on my local machine on port 3478 and it could be accessed from the outside. This told me that there is, or should be, not port/NAT issue and my turn server should be working.
Any ideas?
I am running my server with the following command:
"sudo turnserver -X "public-ip" -listening-port=3478 -v
The turnserver.conf looks something like this:
fingerprint
realm="myRealm"
lt-cred-mech
user=test:test
As telnet and apache server are both working, i am pretty sure i have a configuration issue. I basically spent the weekend trying and im really lost on what could be wrong.
Thanks for any help!
From the documentation of turnserver
-X, --external-ip <public-ip>[/private-ip] TURN Server public/private address mapping, if the server is behind NAT. In that situation, if a -X is used in form "-X " then that ip will be reported as relay IP address of all allocations. This scenario works only in a simple case when one single relay address is to be used, and no CHANGE_REQUEST STUN functionality is required. That single relay address must be mapped by NAT to the 'external' IP. The "external-ip" value, if not empty, is returned in XOR-RELAYED-ADDRESS field. For that 'external' IP, NAT must forward ports directly (relayed port 12345 must be always mapped to the same 'external' port 12345). In more complex case when more than one IP address is involved, that option must be used several times, each entry must have form "-X ", to map all involved addresses. CHANGE_REQUEST NAT discovery STUN functionality will work correctly, if the addresses are mapped properly, even when the TURN server itself is behind A NAT. By default, this value is empty, and no address mapping is used.
So, it is not enough that you expose only the listening port from the inside LAN to the public network but all ports that you are going to use to relay. Please, note what is said in the same documentation:
--min-port <port> Lower bound of the UDP port range for relay endpoints allocation. Default value is 49152, according to RFC 5766.
--max-port <port> Upper bound of the UDP port range for relay endpoints allocation. Default value is 65535, according to RFC 5766.
You should choose a range of ports in the server, configure with them the options --min-port and --max-port and create a NAT rule to expose those ports to the public side of the router without change.
I have attempted everything recommended by the following error message:
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
My /etc/redis/sentinel.conf:
daemonize yes
sentinel myid XXX
sentinel monitor master XXX 6379 2
sentinel down-after-milliseconds master 60000
sentinel config-epoch master 0
protected-mode no
bind 0.0.0.0
port 26379
EDIT: My /etc/redis/redis.conf:
port 6379
bind 0.0.0.0
protected-mode no
I've also tried adding sentinel auth-pass master XXX.
My entire backend is on private subnets. I'm VPN'd into my datacenter behind the firewall, coming from the same private network, and I can still only connect locally without getting that frustrating error message.
Server Environment: Debian 8, Redis 3.2.6
Client Environment: Ubuntu 16.10, redis-cli 3.2.1
Redis instances: 3
Sentinel instances: 3
I've done not just one, but 3/4 of the things suggested (didn't set the command-line flags). Does anyone have any guidance or ideas? I'm clearly missing something that I've been unable to figure out from the error message, documentation, Stackoverflow, Google, and trial & error. I figured I'd post a question here first, before diving into the source code.
Any help is appreciated. Thanks!
... and, yes, I've restarted the daemons after configuration changes. :)
https://www.reddit.com/r/redis/comments/3zv85m/new_security_feature_redis_protected_mode/
As you know we got several problems from unprotected Redis instances exposed to the internet. I covered the reason why a restrictive binding to 127.0.0.1 by default may be an usability concern and, even worse, may not fix the problem (hey just comment the "bind" statement and restart!) in my blog post.
The same blog post introduced an attack that was heavily used by script kiddies to break into Redis instances (serious security researchers where already able to do this, I guess).
So I finally decided to do something before Redis 3.2 official release: Protected mode is the result and will be merged into 3.2 RC2.
The feature is already available in the unstable branch, introduced by this commit. This is how it works.
If and only if:
Protected mode is enabled (this is the default both in the configuration file and in the configless default).
AND IF No AUTH password is configured.
AND IF No "bind" directive is used in order to restrict Redis to certain interfaces.
Then Redis only accepts connections from the loopback IPv4 and IPv6 addresses. External connections are accepted just for the time to send the client an error that makes the user aware of what is happening:
> PING
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients.
In this mode connections are only accepted from the lookback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:
Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent.
Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server.
If you started the server manually just for testing, restart it with the --protected-mode no option.
Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
This should protect errors in a reasonable way while providing users with a clue instead of a connection refused. Please share your feedbacks so that we can make changes to this feature if needed, before it will get merged into Redis 3.2 RC2. Thanks.
log:Creating Server TCP listening socket （myip:port）: bind: Cannot assign requested address
my redis.conf
bind 10.114.234.11
when i cofig like this
bind 127.0.0.1
it works well
You likely do not currently have any interfaces set up for the 10.x.x.x subnet. If you're on any flavor of Linux, ifconfig should be able to tell you which interfaces are currently set up. For example, I'm running Mint 17:
$ ifconfig | grep "inet addr"
inet addr:127.0.0.1 Mask:255.0.0.0
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
So I (like you) would not be able to bind Redis (or most any other service requesting a TCP socket) to 10.x.x.x. If you are really trying to listen for connections on that subnet, you will need to change your network setup (how exactly that would be done depends largely on your operating system).
I also faced same issue while setting up redis for remote access. I was using google cloud platform and we created Google compute engine VM instance where we installed our Redis server. Redis doesn't ship with by default with security configured. You have to perform some steps to secure it. By updating IP address in redis.conf in bind will allow access only from that IP addresses. When we were doing it, we were getting same error.
To solve this issue we haven't added IP addresses in redis.conf file instead in Google cloud firewall rules when we add port open record in network -> IP ranges you can specify IP address which you want allow to access redis. In redis.conf file update from bind 127.0.0.1 to bind 0.0.0.0. So basically we will restrict it from Google cloud firewall rules dashboard.
Below are steps to add IP address restrictions:
Login to your google cloud console
Navigate to VPC Network -> Firewall Rules
Click on CREATE FIREWALL RULE or edit existing one if it's already there
In Source IP ranges add your IP address to allow access only - See below screenshot
Once you create this rule add this source tags under your VM instances network type and you are done.
I have faced the same issue when I changed the default redis.conf to custom Redis conf and after changing the bind as below then it started working, Please be aware that the below conf will open the Redis connection from all sources.
bind 127.0.0.1 -::1 to bind 0.0.0.0 -::1
At /etc/redis/redis.conf
Please change
bind 127.0.0.1 ::1
to
bind 0.0.0.0
then restart
/etc/init.d/redis-server restart
It's work to me
Okay so I have been on Google for about an hour or so trying to figure this one out.
I have a L2TP/IPSec vpn setup. When clients connect a new interface is created for that client the issue is durning boot and most of the time these interfaces do not exist. My vpn range starts at 10.24.1.1 I want sshd to listen on 10.24.1.1 but when there is no client connected it failes to bind address
/var/log/secure:
Apr 15 01:38:26 arija sshd[28068]: error: Bind to port 22 on 10.24.1.1 failed: Cannot assign requested address.
which makes sense. My Question is. Is there a way to create some sort of dummy interface or just assign 10.24.1.1 so sshd will listen on it? Thanks for the help!!
Also Server is CentOs 6 64bit
you can just add the ip address you need to the interface during startup
the configuration depends on which linux flavor you're using, as an example for ubuntu it's located in /etc/network/interfaces.d/eth0.cfg.
Make sure you're excluding this address from the address pool you are using to provision IP Addresses to the L2tP clients
First of all, you need to understand, that in common situation service can listen only on 'up-and-running' interface with assigned IP. The reason of this is Linux core limitations. You can change this behavior at runtime with:
sysctl net.ipv4.ip_nonlocal_bind=1
or at boot time by setting same parameter in /etc/sysctl.conf:
...
net.ipv4.ip_nonlocal_bind=1
...
But there is simpler way for you: you can bind sshd to 0.0.0.0 in their config /etc/ssh/sshd_config:
...
ListenAddress 0.0.0.0
...
My question may be a little confusing, but anyway. My school is going to open up WiFi DMZ on separate IP for students, but they said port 80 will be the only port open.
What do I want? Well I want to tunnel my traffic thru my home server, which is running Apache2 on 80 and SSH on 21. It's just a regular setup. As it is a production machine and I want clients to be able to connect on port 80, but I want to connect to port 80 to make a tunnel. The question is: How to do that?
The possible sollution: Abandon possibility of connecting to websites running on the server from the school IP and use IPTABLES. If source ip == $school_ip && port == 80: Redirect to port 21. Done. But I think there must another, elegant sollution... Isn't it possible to actually use the HTTP transfer for SSH transit? I mean create a host named for example ssh.mydomain.tld and use some apache module to do a server-side redirection to port 21 but only on that particular hostname? What can I do?
Box is running Debian GNU/Linux
Thanks for any help...
Off topic: They think they will block any sort of illegal operation. In fact HTTP is probably the second most-vulnerable protocol after BitTorrent. Why don't lock it down too? It'll be absolutely safe if there's no open ports, wouldn't it? I don't personally think blocking ports for POP, IMAP, Jabber, etc is any good. I think they'll probably seriously piss someone off if they even can't open mail teacher sent them. Oh, there's a webmail? No no no! SSL/TLS goes on port 443, remember? I don't think blocking all the traffic will be any good. IMO they should block unencrypted BitTorrent and apply low-priority QoS for unclassified transfers.
You could try the instructions found here:
http://dag.wieers.com/howto/ssh-http-tunneling/
proxytunnel is available in the stable repo:
http://packages.debian.org/search?keywords=proxytunnel&searchon=names&suite=stable§ion=all
A simple and working solution is sslh.
It is exactly the tool to solve that problem.
BTW ssh is usually set on port 22.