18 
socat TCP-LISTEN:22,fork TCP:192.168.0.15:5900

How can I tell to socat, that port 22 is only trusted from the remote IP address 8.8.8.8, and it should not accept connections from other IP addresses? This is on a Linux server.

Improve this question
1

4 Answers 4

Reset to default
23

You can add the range option to the socat listening address:

socat TCP-LISTEN:22,fork,range=8.8.8.8/32 TCP:192.168.0.15:5900

Or you can add the tcpwrap=vnc_forward option and define global rules for that vnc_forward service as per hosts_access(5).

That won't stop the connections from reaching socat, but socat will ignore them (with a warning) if they don't come from 8.8.8.8.

Improve this answer
1
  • WOW - that resolves my problem. thanks a lot!!
    – user11085
    Jun 19, 2015 at 7:40
18

Something like this works for me to make socat listen on localhost only.

socat TCP-LISTEN:22,fork,bind=127.0.0.1 TCP:192.168.0.15:5900

So you could try this.

socat TCP-LISTEN:22,fork,bind=8.8.8.8 TCP:192.168.0.15:5900
Improve this answer
2
  • Your 2nd example doesn't answer the question. The OP wants to restrict the client addresses that are allowed to connect to the server. With bind=8888 the socat-server would try to bind to the local interface 8.8.8.8 - which doesn't exist on the server side. Thus, range= as used in the accepted answer is the way to go.
    – maxschlepzig
    Jan 23, 2017 at 21:55
  • 3
    This is because the title of the question is wrong : listen connections from a single IP address does not make sense, you do not listen on a IP address you do not own.
    – Xorax
    Dec 24, 2019 at 10:04
3

Most people use firewalls for that. Have a look at iptables to restrict traffic to port 22 i.e.:

iptables -I INPUT -p tcp '!' -s 8.8.8.8 --dport 22 -j REJECT

Or, if the firewall is already restrictive, allow just one address:

iptables -A INPUT -p tcp -s 8.8.8.8 --dport 22 -j ACCEPT

Please note that this is not a full configuration for an iptables firewall, you first need to setup a proper configuration before using the above.

Improve this answer
3
  • Thank you. if i can use iptables i will use it too. But keep in mind why i mentioned micro-processors they strip all tools such as IPTables, SELinux etc because its micro embedded devices. as a result you have only few tools left such as socat only. But thank you.
    – user11085
    Jun 19, 2015 at 7:41
  • 2
    I understand that not all tools will be available by default on some devices but in that case I would recommend you to configure the border firewall/router instead to avoid DDoS attacks. I like the answer of @Stéfane that it is possible to ignore sessions originating from other sources but that micro-processor of yours still need to do some processing.
    – Lambert
    Jun 19, 2015 at 8:14
  • 1
    @YumYumYum - those aren't tools - those are built-in kernel hooks. If you don't have netfilter in-kernel, and your trouble involves a low-power device and intrusion detection/protection, then you can bet that doing that work in userspace is gonna hurt that little device a lot more than it would do in kernel-space. You should build a kernel which better suits you.
    – mikeserv
    Jun 19, 2015 at 8:45
0

If your primary goal is security and you control the client machine then connecting to your socat server through an SSL tunnel is a safer bet, making the server verify the client cert before accepting connections.

I went through this recently trying to secure a synergy client/server setup.

This tutorial explains the setup clearly

http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html

One deviation from the instructions that I found is your client SSL library should reject the server key by default due to the patch for logjam

Appending the following to the server PEM makes everything work

openssl dhparam 2048 >> "$FILENAME".pem

This key based exchange mechanism is much more authoritative when it comes to validating hosts over IP based auth.

Improve this answer

You must log in to answer this question.