A seperate forum item for security.

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.
My point was that just because an application is listening on port n, that doesn't mean that a firewall is THE solution for securing port n. You may need to think not about securing port n, or port n+1, but telling the application to behave, which is done via .conf files. It's a bit like having a lock on your door, but also telling your kid/application to behave smartly and not let strangers in.
 
You may need to think not about securing port n, or port n+1, but telling the application to behave
Yep, this is important. The other day I found out that there is no way to turn off a number of Windows "share" related services listening on ports. When you toggle the "off" button what it actually does is add a firewall rule denying that port! How naff is that?

sockstat -l as demonstrated earlier in the thread really is satisfying to see a silent FreeBSD install. Only SSH is allowed for the majority of my machines.
 
For who is interested my ipfw ruleset,
Code:
cmd="/sbin/ipfw -q add"   # Set rules command prefix
pif="em0"
/sbin/ipfw -q -f flush    # Flush out the list before we begin.

# No restrictions on Loopback Interface
$cmd 01000 allow ip        from any to any via lo0

### ICMP
$cmd 01110 allow icmp      from any to any
$cmd 01120 allow ipv6-icmp from any to any
$cmd 01121 allow ipv6      from any to any

# The next rule allows the packet through if it matches an existing entry in the dynamic rules table
$cmd 02000 check-state

### OUTGOING
# Allow access to outside
$cmd 03010 allow tcp  from any to any out via $pif setup keep-state
$cmd 03020 allow udp  from any to any out via $pif keep-state

### INCOMING
# Deny all inbound traffic from non-routable reserved address spaces
$cmd 04010 deny all from 192.168.0.0/16  to any in via $pif #RFC 1918 private IP
$cmd 04020 deny all from 172.16.0.0/12   to any in via $pif #RFC 1918 private IP
$cmd 04030 deny all from 10.0.0.0/8      to any in via $pif #RFC 1918 private IP
$cmd 04040 deny all from 127.0.0.0/8     to any in via $pif #loopback
$cmd 04050 deny all from 0.0.0.0/8       to any in via $pif #loopback
$cmd 04060 deny all from 169.254.0.0/16  to any in via $pif #DHCP auto-config
$cmd 04070 deny all from 192.0.2.0/24    to any in via $pif #reserved for docs
$cmd 04080 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect
$cmd 04090 deny all from 224.0.0.0/3     to any in via $pif #Class D & E multicast

$cmd 05010 deny ip  from any to ::1 in via $pif
$cmd 05020 deny ip  from ::1 to any in via $pif

#ICMP
$cmd 06010 allow ipv6-icmp from :: to  ff02::/16
$cmd 06020 allow ipv6-icmp from fe80::/10 to fe80::/10
$cmd 06030 allow ipv6-icmp from fe80::/10 to ff02::/16
$cmd 06040 allow ipv6-icmp from any to any icmp6types 1,2,135,136

# Deny fragments
$cmd 07010 deny all from any        to any frag in via $pif
# Deny ACK packets that did not match the dynamic rule table
$cmd 07020 deny tcp from any to any established in via $pif

# Allow incoming access from localnet
#$cmd X allow tcp from 192.168.1.0/24 to any in via $pif setup keep-state
#$cmd X allow udp from 192.168.1.0/24 to any in via $pif keep-state

$cmd 08010 reject log all from any to any
$cmd 08020 deny   log all from any to any
/sbin/ipfw list
 
Last edited:
I read the catalyst for OpenBSD began because of differing philosophies where later on a secure by design philosophy began to where eventually OpenBSD diverged from the NetBSD ecosystem.

So where did the foundations of security at FreeBSD come from. And where does HardenedBSD and the other BSD’s belong as far as security in the BSD ecosystem.

I see a firewalls subcategory. But no security category or subcategory
 
Most people would start a new thread in the appropriate Forums section. Since your topic involves jails, I think that Emulation and Virtualization is a good section of the Forums to start a thread like that.

The video is broader than just jails. They identified 40+ kernel vulnerabilities. They then used a couple together to create a proof of concept to break out of a jail. They then call out how easy the exploit was, and how there is lots of work needed to improve the security of FreeBSD. It was actually the guys first ever exploit creation.
 
Back
Top