A seperate forum item for security.

Lamia

Aspiring Daemon

Reaction score: 212
Messages: 772

You're asking that the IEFT "add" or "insert" an additional layer to the OSI layer.

Wise thinking :):)
 

astyle

Daemon

Reaction score: 488
Messages: 1,139

You're asking that the IEFT "add" or "insert" an additional layer to the OSI layer.
For starters, it's IETF - Internet Engineering Task Force.

Second, you'd want someone knowledgeable to organize and moderate that kind of forum. For example, X.org is quite insecure (plenty of tutorials on the Internet about how to attack port 6000, the default IP port for XDM the login screen to listen on). That might belong on the x.org subforum on these forums. Or do we move the firewalls forum to 'Security'?

I always preach this: Make the application behave first, via .conf files. THEN ask the firewall to do the rest of the enforcement. Trying to ask the firewall to do ALL of the enforcement is asking for trouble.

Come to think of it, you really should take advantage of the design of OSI-RM TCP/IP stack - there's a reason that applications like X.org are on top, and hardware like ethernet plugs are on the bottom.
 
OP
Alain De Vos

Alain De Vos

Daemon

Reaction score: 649
Messages: 2,174

Offcourse you could keep the current spread, but tag it with "security" so there is an alternative way of searching.
Security is with a fancy word "transversal", just like "quality".
 

Lamia

Aspiring Daemon

Reaction score: 212
Messages: 772

Offcourse you could keep the current spread, but tag it with "security" so there is an alternative way of searching.
Security is with a fancy word "transversal", just like "quality".
You're on point. That is a good practice. If you are already doing so, please keep it up.

Security is applicable at every level. As you said, it's a fancy word. And so in this forum, each category has security covered to a large extent.
 

Trihexagonal

Son of Beastie

Reaction score: 2,436
Messages: 2,955

Security is applicable at every level.
But most importantly, it begins at ground level.

For Alain De Vos ground level is the person behind that desk in the avatar. Same for me, that's me in my true form.

For example, X.org is quite insecure (plenty of tutorials on the Internet about how to attack port 6000, the default IP port for XDM the login screen to listen on).
I saw somebody had connected to TCP port 6000 on my Win98 box using X-windows and pulled the modem cord from the wall beside me. I never forgot that... It's the hard lessons I remember best.

Code:
### Macro name for external interface
ext_if = "em0"
netbios_tcp = "{ 22, 23, 25, 80, 110, 111, 123, 512, 513, 514, 515, 6000, 6010 }"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"

### Block specific ports
block in quick log on $ext_if proto tcp from any to any port $netbios_tcp
block in quick log on $ext_if proto udp from any to any port $netbios_udp
 
OP
Alain De Vos

Alain De Vos

Daemon

Reaction score: 649
Messages: 2,174

To check if I didn't forgot something,
Code:
sockstat -46 | grep -v 127.0.0.1 | grep -v ::1
 

Trihexagonal

Son of Beastie

Reaction score: 2,436
Messages: 2,955

I already know what services I've got running, what ports are of interest and what ports are blocked by my ruleset.

But for you I will do it:
Code:
jitte@bakemono:~ $ sockstat -46 | grep -v 127.0.0.1 | grep -v ::1
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS     
jitte    firefox    53240 112 tcp4  192.168.1.24:49053    44.241.185.165:443
jitte    firefox    44150 36 tcp4   192.168.1.24:65357    34.107.221.82:80
jitte    firefox    44150 41 tcp4   192.168.1.24:34581    54.192.121.30:443
jitte    firefox    44150 62 tcp4   192.168.1.24:64256    34.107.221.82:80
jitte    firefox    43244 112 tcp4  192.168.1.24:49053    44.241.185.165:443
avahi    avahi-daem 83474 14 udp4   *:5353                *:*
avahi    avahi-daem 83474 15 udp6   *:5353                *:*
avahi    avahi-daem 83474 16 udp4   *:29159               *:*
avahi    avahi-daem 83474 17 udp6   *:27469               *:*
ntpd     ntpd       71059 20 udp6   *:123                 *:*
ntpd     ntpd       71059 21 udp4   *:123                 *:*
ntpd     ntpd       71059 22 udp4   192.168.1.24:123      *:*
jitte@bakemono:~ $

But I get to post my mighty pf ruleset again. :p
Code:
### Macro name for external interface
ext_if = "em0"
netbios_tcp = "{ 22, 23, 25, 80, 110, 111, 123, 512, 513, 514, 515, 6000, 6010 }"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"

### Reassemble fragmented packets
scrub in on $ext_if all fragment reassemble

### Default deny everything
block log all

### Pass loopback
set skip on lo0

### Block spooks
antispoof for lo0
antispoof for $ext_if inet
block in from no-route to any
block in from urpf-failed to any
block in quick on $ext_if from any to 255.255.255.255
block in quick log on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any

### Block all IPv6
block in quick inet6 all
block out quick inet6 all

### Block to and from port 0
block quick proto { tcp, udp } from any port = 0 to any
block quick proto { tcp, udp } from any to any port = 0

### Block specific ports
block in quick log on $ext_if proto tcp from any to any port $netbios_tcp
block in quick log on $ext_if proto udp from any to any port $netbios_udp

### Keep and modulate state of outbound tcp, udp and icmp traffic
pass out on $ext_if proto { tcp, udp, icmp } from any to any modulate state

And how it works:
Code:
root@bakemono:/ # pfctl -s all
FILTER RULES:
scrub in on em0 all fragment reassemble
block drop log all
block drop in on ! lo0 inet from 127.0.0.0/8 to any
block drop in on ! em0 inet from 192.168.1.0/24 to any
block drop in inet from 192.168.1.24 to any
block drop in on ! lo0 inet6 from ::1 to any
block drop in from no-route to any
block drop in from urpf-failed to any
block drop in quick on em0 inet from any to 255.255.255.255
block drop in log quick on em0 inet from 10.0.0.0/8 to any
block drop in log quick on em0 inet from 172.16.0.0/12 to any
block drop in log quick on em0 inet from 192.168.0.0/16 to any
block drop in log quick on em0 inet from 255.255.255.255 to any
block drop in quick inet6 all
block drop out quick inet6 all
block drop quick proto tcp from any port = 0 to any
block drop quick proto tcp from any to any port = 0
block drop quick proto udp from any port = 0 to any
block drop quick proto udp from any to any port = 0
block drop in log quick on em0 proto tcp from any to any port = ssh
block drop in log quick on em0 proto tcp from any to any port = telnet
block drop in log quick on em0 proto tcp from any to any port = smtp
block drop in log quick on em0 proto tcp from any to any port = http
block drop in log quick on em0 proto tcp from any to any port = pop3
block drop in log quick on em0 proto tcp from any to any port = sunrpc
block drop in log quick on em0 proto tcp from any to any port = ntp
block drop in log quick on em0 proto tcp from any to any port = exec
block drop in log quick on em0 proto tcp from any to any port = login
block drop in log quick on em0 proto tcp from any to any port = shell
block drop in log quick on em0 proto tcp from any to any port = printer
block drop in log quick on em0 proto tcp from any to any port = x11
block drop in log quick on em0 proto tcp from any to any port = x11-ssh
block drop in log quick on em0 proto udp from any to any port = ntp
block drop in log quick on em0 proto udp from any to any port = biff
block drop in log quick on em0 proto udp from any to any port = who
block drop in log quick on em0 proto udp from any to any port = syslog
block drop in log quick on em0 proto udp from any to any port = printer
block drop in log quick on em0 proto udp from any to any port = mdns
block drop in log quick on em0 proto udp from any to any port = x11
block drop in log quick on em0 proto udp from any to any port = x11-ssh
pass out on em0 proto tcp all flags S/SA modulate state
pass out on em0 proto udp all keep state
pass out on em0 proto icmp all keep state

STATES:
all tcp 192.168.1.24:49053 -> 44.241.185.165:443       ESTABLISHED:ESTABLISHED
all tcp 192.168.1.24:14650 -> 204.109.59.195:443       TIME_WAIT:TIME_WAIT
all tcp 192.168.1.24:15428 -> 204.109.59.195:443       TIME_WAIT:TIME_WAIT

INFO:
Status: Enabled for 25 days 02:12:52          Debug: Urgent

State Table                          Total             Rate
  current entries                        3              
  searches                        31827026           14.7/s
  inserts                            70758            0.0/s
  removals                           70755            0.0/s
Counters
  match                             156186            0.1/s
  bad-offset                             0            0.0/s
  fragment                               0            0.0/s
  short                                  0            0.0/s
  normalize                              0            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                              0            0.0/s
  proto-cksum                            0            0.0/s
  state-mismatch                         0            0.0/s
  state-insert                           0            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s
  map-failed                             0            0.0/s

TIMEOUTS:
tcp.first                   120s
tcp.opening                  30s
tcp.established           86400s
tcp.closing                 900s
tcp.finwait                  45s
tcp.closed                   90s
tcp.tsdiff                   30s
udp.first                    60s
udp.single                   30s
udp.multiple                 60s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         30s
interval                     10s
adaptive.start            60000 states
adaptive.end             120000 states
src.track                     0s

LIMITS:
states        hard limit   100000
src-nodes     hard limit    10000
frags         hard limit     5000
table-entries hard limit   200000

OS FINGERPRINTS:
762 fingerprints loaded
root@bakemono:/ #
 

mer

Aspiring Daemon

Reaction score: 339
Messages: 552

The security in Trihexagonal ruleset starts at the "block log all" line. Nothing in, nothing out all interfaces. Good use of skip and quick and scrub keeps it clean and simple.
One could also start with default deny all, then add a list of "allowed in on internal interface" and have a pass in $int_if rule with appropriate NAT/pass out $ext_if rules.
That way one could control exactly what is allowed to transit the box and leave to the external network.
It's more work, because you break a lot of things up front, but then you turn them on one by one until you have what you need.
The "default paradigm" of a lot of commercial systems has become "if it's on my internal interface I'm not going to worry about it I'll just send to the external interface". It means things should just work when you plug in a new netgear router, but it may not be the best.
 

Trihexagonal

Son of Beastie

Reaction score: 2,436
Messages: 2,955

I have a newly written version with rules added for people who want to use cupsd, too.

That the upper port for avahi-daemon isn't covered like 5353 is because it changes, but the block in all rule saves the day.

The 255.255.255.255/32 entry seemed like finishing a line of syntax poetry to me so I just added it in, but it works. Just like everything else. :p

{ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 }

block drop in quick on em0 inet from any to 255.255.255.255

The port 0 rule is one I made and carried over from Win98 and my first packet filter rule-based firewall. I loved them after that and everybody else liked application based firewalls like Zone Alarm. 💩
 
OP
Alain De Vos

Alain De Vos

Daemon

Reaction score: 649
Messages: 2,174

Avahi is normally a layer 2 protocol. It will pass a hub but not a router. Totally unroutable over the internet.
I have no avahi proces running, yet my IP-Printer was auto-detected. Weird.
 

astyle

Daemon

Reaction score: 488
Messages: 1,139

Avahi is normally a layer 2 protocol. It will pass a hub but not a router. Totally unroutable over the internet.
I have no avahi proces running, yet my IP-Printer was auto-detected. Weird.
There's AirPrint, Bonjour, and IPP (Port 9100) - Avahi is mDNSresponder. And, Avahi is not layer 2, it's Layer 4.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,367
Messages: 38,901

Avahi, mDNSresponder, Bonjour, etc. use multicast. Multicast is certainly routable.
 
  • Like
Reactions: mer

Sevendogsbsd

Daemon

Reaction score: 683
Messages: 1,132

"Security" is a huge field. I have been an analyst and penetration tester (web) for 15 years and there are aspects of the field I am only just familiar with. Some folks in previous posts hit the nail on the head when they say it should start at the ground level: be it for an operating system, network infrastructure, web server, software development, etc. If you start building the foundation on secure principles, it makes it easier to add to that later.
 

kpedersen

Son of Beastie

Reaction score: 2,097
Messages: 2,956

For example, X.org is quite insecure (plenty of tutorials on the Internet about how to attack port 6000, the default IP port for XDM the login screen to listen on).
Compared to VNC vulns, it is actually quite secure these days. Possibly due to its age and also some of the less tested, fragmented VNC implementations written by smaller projects rather than a central authority. Amusingly, I believe Gnome's Vino has had more security issues found in 2019 than Xorg has for the last 10 years.

And that is only if you need remote desktop, modern X11 doesn't even listen on the network.

Edit: Found quite a useful list. Slightly concerning that libVNC is on here so often. This underpins almost everything these days :(
 

msplsh

Aspiring Daemon

Reaction score: 200
Messages: 587

Security can be anything. Currently issues are spread over the forum ?
1. If there's an actual security problem, there's specific security channels that don't have chitchat on them to get people the information they need without potentially uninformed commentary.

2. If you want to chitchat about the specifics, the specific forum is probably better suited because "security can be anything" and only people who need more details about it are those using the specific software. Bugtraq is too noisy without filters.

3. If you just want to follow along for amusement, there's the security tag.
 

astyle

Daemon

Reaction score: 488
Messages: 1,139

Big and unwieldy topic as it is, security can probably be organized into coherent topics. Sometimes, you have to turn an idea on its head, around, or even inside out... There's no such thing as a perfectly secure system, but you can have badly designed security, like a Level 3 utility like pf(3)() being asked to enforce rules for Level 7 applications like Xorg(8)(). And everybody's gonna say, "Do it my way, the other guy is doing it insecurely".

For example, XDM listens on port 6000. You can edit Xorg.conf to tell XDM to listen on port 6001 or to not listen on any port whatsoever, or to not use XDM (and use GDM, for example) at all. That's easier than trying to come up with a PF rule. Or, you can still have a big security hole by having something else listen on port 6000, like Apache or MySQL. You gotta bake in sensible access from get-go at application level (.conf files), and then let gatekeepers do their job (PF).
 
OP
Alain De Vos

Alain De Vos

Daemon

Reaction score: 649
Messages: 2,174

Note, I never install a package I can not bind to a certain interface. One exception is ntp
 

kpedersen

Son of Beastie

Reaction score: 2,097
Messages: 2,956

For example, XDM listens on port 6000. You can edit Xorg.conf to tell XDM to listen on port 6001 or to not listen on any port whatsoever, or to not use XDM (and use GDM, for example) at all.
Hmm, not sure I follow. XDM, KDM, GDM all listen on port 177. This is for Xdmcp requests. Luckily it is disabled by default on all of them. (It is not controlled by xorg.conf but xdm-config, kdmrc and gdm.conf respectively)

Port 6000 is what a remote Xorg traditionally used. This is no longer enabled by default (i.e since 2007).
Port 5900 is what a remote GNOME or Sway running Wayland-style uses. This is also not enabled by default.
 
Top