Linked by Thom Holwerda on Mon 24th Sep 2007 21:52 UTC, submitted by Oliver
PC-BSD "The PC-BSD team is pleased to announce the availability of PC-BSD 1.4 (da Vinci edition)! This release is made available via the efforts of many developers and testers, who have spent the past months refining and improving upon the core PC-BSD experience." This release comes with Xorg 7.2, KDE 3.5.7, Compiz-Fusion 0.5.2, support for Flash7, and much more. There are release notes, a changelog, and downloads.
Thread beginning with comment 274252
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: The future of PC-BSD
by Doc Pain on Tue 25th Sep 2007 15:32 UTC in reply to "RE[5]: The future of PC-BSD"
Doc Pain
Member since:
2006-10-08

"To be frankly i think the firewall GUI in PCBSD is such a "budenzauber". I would like to see pf blocking all incoming connections by default. Yet tcp{22,445, 139} ports are open. I expected to see all ports to be filtered. "

Filtered? No. Closed, please. There's a RFC (cannot remember which) that requires closed ports to reply with a RST packet if closed, or ACK if open, but replying nothing is not recommended. Instead, having all ports closed for incomming connections (sending RST on request) would be good. If someone needs (!) to enable a certain connection (e. g. to run a web server, a mail server or allow SSH connections), he should be smart enough to do it on his own. As far as I know, OpenBSD has all ports closed by default and needs enabling by the user afterwards, if intended.

SSH functionality enabled by default is not that bad because it cannot be used without knowledge of a valid user account (name + password). Port 139/tcp is "netbios-ssn" and 445/tcp is "microsoft-ds", what are these needed for? I wondered in PC-BSD versions prior to 1.4...

A frontend to form pf rulesets could be a good idea, allthough I'd like to mention that I've formed my few firewall rules many years ago and never needed to change them.

Reply Parent Score: 5

RE[7]: The future of PC-BSD
by netpython on Wed 26th Sep 2007 05:32 in reply to "RE[6]: The future of PC-BSD"
netpython Member since:
2005-07-06

Filtered? No. Closed, please. There's a RFC (cannot remember which) that requires closed ports to reply with a RST packet if closed, or ACK if open, but replying nothing is not recommended.

I prefer to return instead of doing anything. to prevent portscans before they are actually happening. To prevent information leakage so to speak.

linux kernel source:

# grep -n -A 12 "void.*send_reset" /usr/src/linux/net/ipv4/tcp_ipv4.c
1161:static void tcp_v4_send_reset(struct sk_buff *skb)
1162-{
1163- struct tcphdr *th = skb->h.th;
1164- struct tcphdr rth;
1165- struct ip_reply_arg arg;
1166-
1167- return; // Modification: Never send RST, always return.
1168-
1169- /* Never send a reset in response to a reset. */
1170- if (th->rst)
1171- return;
1172-
1173- if (((struct rtable*)skb->dst)->rt_type != RTN_LOCAL)

Reply Parent Score: 2

RE[7]: The future of PC-BSD
by Soulbender on Wed 26th Sep 2007 07:50 in reply to "RE[6]: The future of PC-BSD"
Soulbender Member since:
2005-08-18

Filtered? No. Closed, please.


While closed is nicer to the connecting party it has the slight drawback that it doesn't punish the bad guys. Why would someone connect to a random port on your machine anyway? It's pretty safe to assume that those connections arent coming from people who wishes you well.
As long as you don't do something amazingly retarded like carpet block ICMP or echo requests you should be fine. People who block echo requests should be beaten.

There's a RFC (cannot remember which) that requires closed ports to reply with a RST packet if closed, or ACK if open, but replying nothing is not recommended.


Probably written back in the day when the Internet wasn't plagued with botnets and other bad guys. Those days are long gone.

As far as I know, OpenBSD has all ports closed by default and needs enabling by the user afterwards, if intended.


I don't have a pristine system available but AFAIK identd, daytime and time services are running in the default install.

SSH functionality enabled by default is not that bad because it cannot be used without knowledge of a valid user account (name + password)


I dont know about PC-BSD but the default OpenSSH config have password login disabled so you'd have to both know an account name (but everyone knows "root") and somehow get a public key onto the system for that account before you could log in.

Port 139/tcp is "netbios-ssn" and 445/tcp is "microsoft-ds", what are these needed for?


Windows Networking, aka SMB.

A frontend to form pf rulesets could be a good idea


Hmmm, I dunno. How complicated ruleset will a workstation need? I'd say a default of passing everything statefully would be just fine. Either you run a service that you want to be public or you run it on loopback or you dont run it at all.
You could do some really neat stuff with pf,tables, anchors and user rules if you wanted though.

Edited 2007-09-26 07:54

Reply Parent Score: 2

RE[8]: The future of PC-BSD
by Soulbender on Wed 26th Sep 2007 11:04 in reply to "RE[7]: The future of PC-BSD"
Soulbender Member since:
2005-08-18

default OpenSSH config have password login disabled


Self-correction: tunneled password logins are enabled, it's login with empty password that is disabled.

Reply Parent Score: 1