notebook (WLAN) and desktop (LAN) in local network: how to use SSH? (firewall: internal zone?)

English Network/Internet
#1

Hi,
i have two PCs (one notebook and a desktop pc) in my private network, both have tumbleweed installed.
Both devices are connected to my cable router, which is connected to the internet.
The notebook is connected via WLAN and has the local IP: 192.168.178.30
The deskop PC is connected via LAN and has the local IP: 192.168.178.20
both PCs have access to the internet and also can ping each other.

What i want to do is, access the desktop PC via SSH from the notebook, at first i activated and enabled the sshd service:
systemctl start/enable sshd.service

The service is active (running) at the moment on the desktop pc.
The problem is, i cannot connect from the notebook. Obviously i have to allow ssh in the firewall settings first!

So i noticed that there are 3 zones: internal, external and demilitarized, ideally would be to allow ssh (server) only from within the local network because
i do not want to access the desktop pc from the internet. But i also noticed that in the internal zone (which should be LAN if i got this right)
nothing is blocked by default!

The only explanation would be, that the notebook, or maybe both devices are not in the internal zone. So how can test and change this?

Or is there a better way?

I also noticed that the “interface” section (the second right after “start”) in the firewall configuration section of yast, has my network device listed (desktop pc): enp5s0
but is has no zone assigned!
This is probably correct right? I did not tried to change that because i did not wanted to mess anything up, but maybe this is relevant for
my planed configuration also?

#2

Your Router has also a Firewall inside and if you do not allow any Service from outside, you could disable your Firewall on your PC…

But if you use the SUSE Firewall:
On your PC:
Assign your netcard to external and open a Port for ssh. If you have not changed the Port in the sshd_config, you can do this by selecting Secure Shell Server in the Firewall.
This will open Port 25.

If you have changed the Port in the sshd_config, you have to open the Port by selecting it in extended (or so).

#3

Actually, port 22 by default.

#4

Yes, 25 is SMTP…

Excuse me…

#5

But i do not want the ssh port open for the external zone (internet) i just want it open for the internal zone (LAN) + WLAN i.e. for ips in the range 192.168.178.0/24

#6

Am Sat, 27 Aug 2016 19:06:01 GMT
schrieb sabo007 <sabo007@no-mx.forums.microfocus.com>:

> But i do not want the ssh port open for the external zone (internet) i
> just want it open for the internal zone (LAN) + WLAN i.e. for ips in the
> range 192.168.178.0/24
>
>

Although this does not make a lot of sense if you are behind the router
firewall, you can use

FW_SERVICES_ACCEPT_EXT

in

/etc/sysconfig/SuSEfirewall2

You can read about the correct syntax in the same file, it is very well
documented.

AK

Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

#7

While reading the commends in /etc/sysconfig/SuSEfirewall2 for the FW_SERVICES_ACCEPT_EXT="" option, i suddenly got it.
Of course you all are right, the router blocks any incoming traffic from the internet, this should include the ssh port 22 too, but in the local network the router also
provides nothing should be blocked by default.
So even if i would disable my SuSEfirewall2 this would not had any effect on the internet traffic.

I understand know that i am “save” no matter which solution i take, but again conceptually it feels wrong allowing something in the external zone to have it in the local network.
I think it would be better to disable the firewall on the desktop pc at all (as you suggested) or try a configuration which let the firewall recognize that both pcs are in the internal zone.

#8

Okay, first let’s try to clear up some confusion, here. From what I see, I am guessing your notebook is connected to the same router, but by Wireless Signal (WiFi).

Your desktop PC is connected with a cable.

Is that correct?

If so, your notebook is NOT connected via WLAN, which is a wider LAN than contained in your router.

Please confirm that you are connected to the same router, but the notebook is Wireless and the desktop is wired.

Makes a huge difference in the answer to your quest.

#9

Okay, brain-stutter. You mean (and said) WLAN (Wireless LAN), and I was thinking WAN (Wide Area Network).

But, unless you have a special setting in your router that allows you to isolate the Wireless clients from the Ethernet-connected (wired) clients, the two machines should be in the same LAN.

Repeat the IP addresses that you showed in your first post, but include the netmask, please.

#10

Am Sun, 28 Aug 2016 02:16:01 GMT
schrieb sabo007 <sabo007@no-mx.forums.microfocus.com>:

> I understand know that i am “save” no matter which solution i take, but
> again conceptually it feels wrong allowing something in the external
> zone to have it in the local network.

Don’t get confused by a (more or less) nice name.

If you have the concept of different zones (which SuSEfirewall2 has), you need
to give them names, one might argue if those names cover all the cases in an
easy to understand way.

Let’s make a little “experiment” of the mind.

Replace internal with TRUSTED and external with UNTRUSTED.

Is your home network something you (should) trust?

Most likely yes.

Iif your internal network is not trustworthy, then you most likely don’t trust
yourself (if you are the one who set up that network).

Very often you WANT communication between machines on that LAN, so it makes
sense to consider your network interfaces being part of the internal
(TRUSTED) zone to allow traffic between machines on that LAN.

Now replace your home network with an open WiFi at your local café.

Do you trust that network although it is also a LAN behind a router?

Most likelynot, so for that case it would make sense to consider your wireless
interface being part of the external (UNTRUSTED) zone.

But keep this in mind:

It is much more important to think about secure configuration of services and
to carefully consider WHICH services you really want to offer.

Any service you don’t really need should be turned off, if a service is not
running, it can not be attacked.

Every service you really need should be configured as secure as possible
(or at least as secure as feasible, hint: for SSH always use pubkey
authentication ONLY and do NOT allow root to log in).

Especially for SSH you can configure it in such a way that even if it were
visible to the outside world it would not pose a big security risk.

In that scenario a firewall (packet filter) becomes a sort of “bonus” for some
extra security but is not the “single point of failure” you have to rely on.

AK

Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

#11

Really thorough and easy to understand explanation. If you aren’t already one you should consider a career as a technical writer :slight_smile:

#12

A standartized (works on probably all linux distros) and straightforward alternative to dealing with SuseFirewall is to use iptables.
For instance, if you want to allow ssh only, you can create a script like that:


#!/bin/bash
### BEGIN INIT INFO
# Provides:          nothing
# Required-Start:    $network
# Default-Start:     3 5
# Default-Stop:
# Short-Description: start ip filtering
# Description:       start ip filtering
### END INIT INFO
iptables -P INPUT DROP
#drop all connections by default
iptables -A INPUT -m tcp -p tcp -s 192.168.178.0/255.255.255.0 --dport 22 -j ACCEPT
#accept only connections via port 22 from the specified IP range

Then put this script to /etc/init.d
And then you can run


insserv scriptname

Where scriptname is the name you give to your script.

With this you will allow only ssh via port 22 and only from the desired IP range on your desktop blocking everything else. The thing with init.d makes sure that the script runs on every boot of your system.