# how to use sshd on lan interfaces only ?



## isso2095 (Oct 26, 2021)

hello,

i want to use ssh but only on lan interfaces which are em0 and ue0 and i want to turn off from wan side (tun0) pppoe


----------



## gpw928 (Oct 26, 2021)

The sshd_config(5) item you seek is "ListenAddress".


----------



## gpw928 (Oct 26, 2021)

By way of example (192.168.1.254 is the default route for the internal network which can move to another host for maintenance of the firewall, so 192.168.1.252 permanently correlates to the hostname):
	
	



```
[pi4.677] $ cd /etc/ssh
[pi4.678] $ diff sshd_config.orig sshd_config
121a122,133
>
> # We don't listen on the Internet...
> ListenAddress 192.168.1.252
> ListenAddress 192.168.1.254
> # We need to allow root login for rsnapshot backup server
> PermitRootLogin prohibit-password
> # We want login via ssh with keys only...
> PubkeyAuthentication yes
> PasswordAuthentication no
> ChallengeResponseAuthentication no
```


----------



## Phishfry (Oct 26, 2021)

I am setting up a box to take over for OPNSense. I am using Pf firewall rules to isolate ssh.

```
### SSH Access to firewall is permitted only from internal network ###
pass in   quick inet proto tcp  from 192.168.1.0/24  to self port { 53, 22 } keep state
```


----------



## zirias@ (Oct 26, 2021)

Most sane network services can be configured how they listen. Still you will need a firewall most of the time. You might have other boxes on your LAN with just a single interface and still want to filter packets from the internet to them. Or you might just have too many services to be sure about their individual configurations.

Once you have a firewall in place, it's much easier to configure all your policies there.


----------



## Phishfry (Oct 26, 2021)

I considered adding this rule instead but I am still learning.

```
block in quick on igb0 proto tcp to port 22
```
Which is the best approach?
Blocking the WAN or restricting port22 to LAN.


----------



## Phishfry (Oct 26, 2021)

The Book of Pf is showing this for interal SSH.

```
pass quick on $int_if inet proto { tcp, udp } to $int_if port ssh
```


----------



## SirDice (Oct 26, 2021)

Phishfry said:


> Blocking the WAN or restricting port22 to LAN.


I'd do both. Just to be sure. It's always possible to make a mistake in the firewall that would allow the traffic again. Or a mistake in sshd_config that would make it listen on all IP addresses. By setting both you reduce that risk.


----------



## Phishfry (Oct 26, 2021)

Since I am not proficient in the use of Pf I have also enabled security/sshguard.
That gives me a backstop in case I mess up.
Once I am satisfied with my rule set I can disable it.

One consideration for the OP is how are you going to use your two LAN interfaces.
Bridged or routed. In a bridged topology all interfaces would use the same IP subnet whereas a routed network you will have several subnets. So your Pf rules might look different depending on interface assignments.


----------



## astyle (Oct 26, 2021)

I would suggest first looking at /etc/sshd.conf and see what you can button up there. Stuff like what ports and interfaces the daemon even listens on - that belongs in /etc/sshd.conf. 

Only afterwards, look at `pf` and see who you want to keep out, period. If you also try to ask the firewall to pay attention to specific ports and services, outbound packets as well as in - that creates difficult-to-troubleshoot complexity.


----------



## gpw928 (Oct 26, 2021)

The original question of listening for "ssh but only on lan interfaces" is a different issue to how you configure your Internet firewall.

My firewall has never allowed ssh logins directly from the Internet, regardless of where sshd might be listening.

On any firewall you need a clearly articulated policy, stated as simply as possible.  Everything should be denied except for what is _*explicitly*_ permitted. And ssh is certainly not on that (very small) "permitted list".

When I was away from home a lot, I used to forward port 32022 on the firewall to port 22 on an internal host, which was a small VM with a strong security profile.  So once you got onto the VM with one ssh key, you still needed another to escape onto the LAN, or back into the firewall.


----------



## ralphbsz (Oct 27, 2021)

Security is always a compromise. With an infinitely large team of administrators and infinite time, you can make a system perfectly secure. Consider the price you'll pay for that though: Not only the salaries of all those people, and the long wait times while they work on securing things. But also their constant intrusiveness (security is usually done at the cost of convenience), and the downtime (like all systems, security isn't perfectly reliable).

So the art of doing security is (like all of engineering) is the art of compromise: What can I do that has low cost, low complexity, and is pretty good? How many of these things can I layer together? Of all the possible approaches, which has the best cost/benefit? Given that no approach is ever 100% reliable and safe, how many layers do I need to implement, until I feel comfortable?

In that spirit: Editing /etc/ssh/sshd.conf to turn off unwanted sources of ssh connections is relatively easy. The cost is that one has to sit down (for a minute or an hour, depending on experience) to read and understand the sshd_config(5) man pages. Decent security for low cost. Problem is: Now there are explicit addresses in that config file, and if the network is reconfigured, things will go pear-shaped. The opportunity is that one should also think through many of the other options in that config file (for example: Should root login be allowed? Should passwords or keys or both or neither be allowed?), and think about ssh security holistically.

On the other side, editing /etc/pf.conf is also an excellent idea. But the effective way to do it is (as gpw928 said above) is not to open or close on port, but to think about the host's whole security posture: what services does it need to provide? Which of those services are actually really worth the cost of making them secure enough? Who is likely to be attacking, and what might they be after? Is it even worth it to secure certain things, while other things need to be (unfortunately by their nature) wide open? For example, for a machine that is strictly on an internal network that is secure, blocking things by default is just creating a hairball for no benefit. And consider that pf.conf also depends on network configuration (it tends to have both interface names and address ranges explicitly written in it).

And finally, consider other layers. For example, I really like the proposal that gpw928 also mentioned: Move ssh to a different port. It is not secure against determined attackers, but it means that the dumb script kiddies that only probe port 22 have no chance.


----------



## Phishfry (Oct 27, 2021)

Everybody seems to be getting the config file wrong. The SSH server settings file is /etc/ssh/sshd_config

I threw my 2 cents in because I am currently working on the same situation. Freeing myself of a pre-built firewall.
When I found that OPNSense NanoBSD-Version was using RW on the disk and using delicately dedicated disk scheme it really made me wonder.
My main reason for using the NanoBSD version was to preserve SSD write cycles.
Sure using /var on memdisk helps, but why the disk is RW is baffling.
It took me years to realize they weren't doing it right. It is no wonder that I had to re-write my image so many times.
Every bad flickering power outage the disk would get wrecked.
They make it so easy to restore with the XML settings file I never investigated.
So OPNSense (NanoBSD version) is using RW on a disk that is wrongly partitioned.
That is what you get when you don't pay attention to what you are using in intimate detail.
It is also why using a crutch like *Sense is not good. You become ignorant of the inner workings.


----------



## Phishfry (Oct 27, 2021)

gpw928 said:


> The original question of listening for "ssh but only on lan interfaces" is a different issue to how you configure your Internet firewall.


I agree and did not want to stomp on your correct answer.
My feeling is that this user only has 4 posts and it is essential to shield from the outside completely before worrying about SSH.
I had to assume the worst case scenario. (This user is on the inet with an open box).
So what if I was wrong. I put it out there so he can secure his whole machine. Not just one component.


----------



## gpw928 (Oct 27, 2021)

Phishfry said:


> Everybody seems to be getting the config file wrong. The SSH server settings file is /etc/ssh/sshd_config


That's my fault.  My firewall runs on Debian Linux, and I just cut'n'pasted the ssh config diffs.


Phishfry said:


> My main reason for using the NanoBSD version was to preserve SSD write cycles.


My firewall runs on a Raspberry Pi and boots from an SD card.  SD cards have poor durability.  I always mount writable file systems (especially /var/log) on a USB stick (which is fast enough for my situation).  So we have a similar issue with write cycles, if some orders of magnitude different in the speed department.

I too had chronic issues with power fluctuations, but no longer since I got the 900W UPS for the office .


Phishfry said:


> Freeing myself of a pre-built firewall.


I have been writing and perfecting my own firewall for the last 10 years.  It's illuminating, and fun.  But I would never recommend that sort of insanity to anyone else...


----------



## Phishfry (Oct 28, 2021)

gpw928 said:


> that sort of insanity


I agree. I tried the crutch approach here too.
security/fwbuilder.
pf rules via wizzard. What could go wrong!!
(Except there is no template for what I want so you have to learn Pf rule ordering anyway).

I did'nt think I would need to use tables for my simple setup but I drifted there anyway.

I do feel like a labotomy is in order and I am still not live with my setup.


----------



## astyle (Oct 28, 2021)

Phishfry said:


> I agree. I tried the crutch approach here too.
> security/fwbuilder.
> pf rules via wizzard. What could go wrong!!
> (Except there is no template for what I want so you have to learn Pf rule ordering anyway).
> ...


Instead of having a pratfall, you can study up on Pratt parsing, very useful for firewalls


----------



## Phishfry (Oct 28, 2021)

There is a website for that.


			https://imaprettykitty.com/wof/
		

Pick your firewall at the bottom


----------



## Beastie7 (Oct 28, 2021)

ralphbsz said:


> Security is always a compromise. With an infinitely large team of administrators and infinite time, you can make a system perfectly secure. Consider the price you'll pay for that though: Not only the salaries of all those people, and the long wait times while they work on securing things. But also their constant intrusiveness (security is usually done at the cost of convenience), and the downtime (like all systems, security isn't perfectly reliable).
> 
> So the art of doing security is (like all of engineering) is the art of compromise: What can I do that has low cost, low complexity, and is pretty good? How many of these things can I layer together? Of all the possible approaches, which has the best cost/benefit? Given that no approach is ever 100% reliable and safe, how many layers do I need to implement, until I feel comfortable?
> 
> ...



you're always writing essays, why?


----------



## mark_j (Oct 28, 2021)

Beastie7 said:


> you're always writing essays, why?


LOTOHH?


----------



## astyle (Oct 28, 2021)

ralphbsz  the professor.


----------



## ralphbsz (Oct 28, 2021)

Beastie7 said:


> you're always writing essays, why?


In the hope that people read them.


----------



## gotnull (Oct 30, 2021)

Phishfry said:


> There is a website for that.
> 
> 
> https://imaprettykitty.com/wof/
> ...






*WOW IT BLOW MY MIND !!!*​
I encounter most of the time some difficulties with network things (essentially because I never took the time to understand it correctly I think, I take some notes about few things I learn but that does not change the fact that I really suck at network understanding ^^), so of course configuring firewalls is always a lot of time and pain spent to figure out the logic AND/OR the syntax, but THAT "*wofgen"* is a fantastic tool I am just soooooo frustrated to discover it only today (thank you Phishfry  ), never heard of it before  I really hope the dev won't let it die. 
The syntax used for the rules are so simple that I can almost understand them right the way, it still amaze me !!


----------



## Phishfry (Nov 1, 2021)

Well you can marked this thread solved for me. I am using pf and it feels good to know whats going on.
I finally used just the Book of Pf and finally got  some acceptable results.
At this point I am an expert at locking myself out of ssh.

I did learn quite a bit.
I have an motherboard port configured on em1 for a managment port.
Static IP of 192.168.2.1 serving dhcp leases via dnsmasq at a range 192.168.2.10 to 192.168.2.20
Without an ethernet cable attached to em1 I can login via ssh at 192.168.2.1
(Via LAN/lagg0 192.168.1.0/24 addresses)
That really surprised me. I would have thought that ssh request would need to come in via em1 to use its address.
I disabled that interface until I can write some rules for it. Not a DMZ but I am calling it OPT.


----------



## Phishfry (Nov 1, 2021)

I decided to get my rules right by taking OPNSense off line and using the book. It took 2 days but I got there.

One resource that is severely lacking is the examples for pf at /usr/share/examples/pf
I would expect this directory to contain some useful examples like a Client/Workstation and Basic Gateway config.
Instead it seems to concentrate on ATLQ and other advanced topics.
Basic examples beyond dated OpenBSD docs would be nice.


----------



## SirDice (Nov 3, 2021)

Phishfry said:


> At this point I am an expert at locking myself out of ssh.


Been there, done that. Simple tip, put your new ruleset in /etc/pf.conf.new for example. Then if you do this remotely, `pfctl -f /etc/pf.conf.new && sleep 60 && pfctl -f /etc/pf.conf`
That will load your new ruleset, sleep for 60 seconds, then load the original again. If you've made a mistake and locked yourself out just wait 60 seconds for the original (working) ruleset to be loaded again.


----------

