Slashdot Mirror

Don't pay the troll any attention, we all know a real OpenBSD user is too fucking paranoid to let this shit stand and has already installed Debian stable on all their machines while they carefully inspect every commit since y2k on the OpenBSD stack.. again.

Now, seeing as we are in a tinfoil hat zone right now. I am intrigued by his choice of 3.6, there were a LOT of security fixes in that patch.

rev1.33 2000/01/13 versus rev1.34 2000/01/27
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pfkeyv2.c.diff?r1=1.33;r2=1.34;f=h

http://fxr.watson.org/fxr/source/net/pfkeyv2.c?v=OPENBSD;im=3#L776
http://fxr.watson.org/fxr/source/net/pfkeyv2.c?v=OPENBSD;im=3#L787

rev1.33: *alg = satype == SADB_SATYPE_AH ? XF_NEW_AH : XF_OLD_AH; versus rev1.34: *alg = satype = XF_AH; (flawed)
rev1.33: *alg = satype == SADB_SATYPE_ESP ? XF_NEW_ESP : XF_OLD_ESP; versus rev1.34: *alg = satype = XF_ESP; (flawed)

the reason of caring the algorithm to be picked is this uniform structure http://fxr.watson.org/fxr/source/netinet/ip_ipsp.c?v=OPENBSD#L111>http://fxr.watson.org/fxr/source/netinet/ip_ipsp.c?v=OPENBSD#L111

if the algorithm is not picked correctly then it can leak by another kind of algorithm
XF_ESP=3, XF_AH=2, XF_IP4=1 (IP inside of IP, don't confuse with ESP encapsulation).
http://fxr.watson.org/fxr/ident?v=OPENBSD;im=excerpts;i=XF_ESP
satype must not be asigned, it's from switch(satype)

correct should be *alg = XF_AH; and *alg = XF_ESP;

Is this better?

Here you go: The Code.

It looks like you trimmed your link. This goes to the root of the entire CSV. We'd want to see the specific code in the allegation, as it was submitted back in 2000/2001. Got THAT link?

Here you go: The Code.

It seems that link may have been /.ed. They are doing precisely as you say.

Here is a dump of the information, last I had it.

IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate

The etherpad (most detailed and up to date):
OPENBSD IPSEC STACK VERIFICATION

Original Email:

http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

The code:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_input.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_output.c

Misc:

What other software includes the OpenBSD IPSEC implementation?

Not Linux:
Triaging Linux; git clone git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Initial commit 6c55c29fa, Oct 2002, Alexey Kuznetsov
Does not appear to be derived from the above? (checking strings from ipsec_input.c version 1.54.2.3, Oct 2002). Neither copyright information nor comment strings match. Linux's IPSec implementation looks original.
'git log -p --grep=IPSEC' on the above clone shows complete history for the period.

Communications:
IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate
PublicPad (this document); http://piratenpad.de/condition-beige

Press:

http://blogs.forbes.com/taylorbuley/2010/12/14/fbi-accusedipsec-of-decade-old-cryptography-code-conspiracy/
http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backd

We have never allowed US citizens or foreign citizens working in the US
to hack on crypto code (Niels Provos used to make trips to Canada to
develop OpenSSH for this reason), so direct interference in the crypto
code is unlikely. It would also be fairly obvious - the crypto code
works as pretty basic block transform API, and there aren't many places
where one could smuggle key bytes out. We always used arcrandom() for
generating random numbers when we needed them, so deliberate biases of
key material, etc would be quite visible.
oored-OpenBSDs-IPSEC-Stack
http://www.reddit.com/r/programming/comments/elw0x/allegations_regarding_openbsd_ipsec_fbi_backdoors/
http://www.metafilter.com/98547/Subject-Allegations-regarding-OpenBSD-IPSEC

Docs:

http://web.archive.org/web/20000621015208/www.netsec.net/gsa.html
https://www.gsaadvantage.gov/ref_text/GS35F0040K/GS35F0040K_online.htm
http://web.archive.org/web/19980101000000-20040101235959*sh_re_sr_1nr_30/http://www.netsec.net/*
http://web.archive.org/web/20000816024729/www.netsec.net/ltr_doj.html

Source Contributors:
Jason: http://www.linkedin.com/in/jasonwright

Possibility #1: (eldragon)
http://www.openbsd.org/cgi-bin/cvs

It seems that link may have been /.ed. They are doing precisely as you say.

Here is a dump of the information, last I had it.

IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate

The etherpad (most detailed and up to date):
OPENBSD IPSEC STACK VERIFICATION

Original Email:

http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

The code:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_input.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_output.c

Misc:

What other software includes the OpenBSD IPSEC implementation?

Not Linux:
Triaging Linux; git clone git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Initial commit 6c55c29fa, Oct 2002, Alexey Kuznetsov
Does not appear to be derived from the above? (checking strings from ipsec_input.c version 1.54.2.3, Oct 2002). Neither copyright information nor comment strings match. Linux's IPSec implementation looks original.
'git log -p --grep=IPSEC' on the above clone shows complete history for the period.

Communications:
IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate
PublicPad (this document); http://piratenpad.de/condition-beige

Press:

http://blogs.forbes.com/taylorbuley/2010/12/14/fbi-accusedipsec-of-decade-old-cryptography-code-conspiracy/
http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backd

We have never allowed US citizens or foreign citizens working in the US
to hack on crypto code (Niels Provos used to make trips to Canada to
develop OpenSSH for this reason), so direct interference in the crypto
code is unlikely. It would also be fairly obvious - the crypto code
works as pretty basic block transform API, and there aren't many places
where one could smuggle key bytes out. We always used arcrandom() for
generating random numbers when we needed them, so deliberate biases of
key material, etc would be quite visible.
oored-OpenBSDs-IPSEC-Stack
http://www.reddit.com/r/programming/comments/elw0x/allegations_regarding_openbsd_ipsec_fbi_backdoors/
http://www.metafilter.com/98547/Subject-Allegations-regarding-OpenBSD-IPSEC

Docs:

http://web.archive.org/web/20000621015208/www.netsec.net/gsa.html
https://www.gsaadvantage.gov/ref_text/GS35F0040K/GS35F0040K_online.htm
http://web.archive.org/web/19980101000000-20040101235959*sh_re_sr_1nr_30/http://www.netsec.net/*
http://web.archive.org/web/20000816024729/www.netsec.net/ltr_doj.html

Source Contributors:
Jason: http://www.linkedin.com/in/jasonwright

Possibility #1: (eldragon)
http://www.openbsd.org/cgi-bin/cvs

It seems that link may have been /.ed. They are doing precisely as you say.

Here is a dump of the information, last I had it.

IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate

The etherpad (most detailed and up to date):
OPENBSD IPSEC STACK VERIFICATION

Original Email:

http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

The code:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_input.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_output.c

Misc:

What other software includes the OpenBSD IPSEC implementation?

Not Linux:
Triaging Linux; git clone git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Initial commit 6c55c29fa, Oct 2002, Alexey Kuznetsov
Does not appear to be derived from the above? (checking strings from ipsec_input.c version 1.54.2.3, Oct 2002). Neither copyright information nor comment strings match. Linux's IPSec implementation looks original.
'git log -p --grep=IPSEC' on the above clone shows complete history for the period.

Communications:
IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate
PublicPad (this document); http://piratenpad.de/condition-beige

Press:

http://blogs.forbes.com/taylorbuley/2010/12/14/fbi-accusedipsec-of-decade-old-cryptography-code-conspiracy/
http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backd

We have never allowed US citizens or foreign citizens working in the US
to hack on crypto code (Niels Provos used to make trips to Canada to
develop OpenSSH for this reason), so direct interference in the crypto
code is unlikely. It would also be fairly obvious - the crypto code
works as pretty basic block transform API, and there aren't many places
where one could smuggle key bytes out. We always used arcrandom() for
generating random numbers when we needed them, so deliberate biases of
key material, etc would be quite visible.
oored-OpenBSDs-IPSEC-Stack
http://www.reddit.com/r/programming/comments/elw0x/allegations_regarding_openbsd_ipsec_fbi_backdoors/
http://www.metafilter.com/98547/Subject-Allegations-regarding-OpenBSD-IPSEC

Docs:

http://web.archive.org/web/20000621015208/www.netsec.net/gsa.html
https://www.gsaadvantage.gov/ref_text/GS35F0040K/GS35F0040K_online.htm
http://web.archive.org/web/19980101000000-20040101235959*sh_re_sr_1nr_30/http://www.netsec.net/*
http://web.archive.org/web/20000816024729/www.netsec.net/ltr_doj.html

Source Contributors:
Jason: http://www.linkedin.com/in/jasonwright

Possibility #1: (eldragon)
http://www.openbsd.org/cgi-bin/cvs

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_esp.c
Question: What kind of encryption uses it in the kernel?
Answer: only symmetric encryption, none is of kind asymmetric encryption.

Question: Why not asymmetric coding for encryption and certification in the KERNEL? It's for exchanging certified keys and for creating tunnels.
Answer: F.B.I. concerns.

IPSec = F.B.I.

1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)?
2. Why is "#if NPF > 0 ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?

It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41

"triggers decapsulation"? what is it?

The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"

ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);

ipsec_output.c rev1.30 vs rev1.31
then it does udpencap_enable = 1; /* enabled by default */

http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."

Assumption is unsafety.

ipsec_output.c rev1.40 vs rev 1.41
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) { /* m->m_pkthdr.pf.statekey = NULL; */ }

http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.

3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD
if the intruder's UDP header is removed then the intruder's information is removed :)
so that OpenBSD removed the intruder's auditory

it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).

1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!

2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.

ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD

ipcomps_minlen comment
u_int32_t ipcomps_minlen; /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */

http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++

1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)?
2. Why is "#if NPF > 0 ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?

It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41

"triggers decapsulation"? what is it?

The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"

ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);

ipsec_output.c rev1.30 vs rev1.31
then it does udpencap_enable = 1; /* enabled by default */

http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."

Assumption is unsafety.

ipsec_output.c rev1.40 vs rev 1.41
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) { /* m->m_pkthdr.pf.statekey = NULL; */ }

http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.

3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD
if the intruder's UDP header is removed then the intruder's information is removed :)
so that OpenBSD removed the intruder's auditory

it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).

1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!

2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.

ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD

ipcomps_minlen comment
u_int32_t ipcomps_minlen; /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */

http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++

1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)?
2. Why is "#if NPF > 0 ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?

It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41

"triggers decapsulation"? what is it?

The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"

ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);

ipsec_output.c rev1.30 vs rev1.31
then it does udpencap_enable = 1; /* enabled by default */

http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."

Assumption is unsafety.

ipsec_output.c rev1.40 vs rev 1.41
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) { /* m->m_pkthdr.pf.statekey = NULL; */ }

http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.

3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD
if the intruder's UDP header is removed then the intruder's information is removed :)
so that OpenBSD removed the intruder's auditory

it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).

1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!

2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.

ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD

ipcomps_minlen comment
u_int32_t ipcomps_minlen; /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */

http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++

1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)?
2. Why is "#if NPF > 0 ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?

It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41

"triggers decapsulation"? what is it?

The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"

ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);

ipsec_output.c rev1.30 vs rev1.31
then it does udpencap_enable = 1; /* enabled by default */

http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."

Assumption is unsafety.

ipsec_output.c rev1.40 vs rev 1.41
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) { /* m->m_pkthdr.pf.statekey = NULL; */ }

http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.

3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD
if the intruder's UDP header is removed then the intruder's information is removed :)
so that OpenBSD removed the intruder's auditory

it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).

1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!

2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.

ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD

ipcomps_minlen comment
u_int32_t ipcomps_minlen; /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */

http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++

1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)?
2. Why is "#if NPF > 0 ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?

It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41

"triggers decapsulation"? what is it?

The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"

ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);

ipsec_output.c rev1.30 vs rev1.31
then it does udpencap_enable = 1; /* enabled by default */

http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."

Assumption is unsafety.

ipsec_output.c rev1.40 vs rev 1.41
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) { /* m->m_pkthdr.pf.statekey = NULL; */ }

http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.

3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD
if the intruder's UDP header is removed then the intruder's information is removed :)
so that OpenBSD removed the intruder's auditory

it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).

1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!

2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.

ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD

ipcomps_minlen comment
u_int32_t ipcomps_minlen; /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */

http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++

http://www.openbsd.org/reprints/article_20000419.html

"The recent incident of "backdoors" in Microsoft software is indicative of a fundamental problem that electronic commerce will need to address very soon," Jerry Harold, president & co-founder of NetSec [...] Even if Microsoft has stringent internal requirements for software assurance, it's very difficult to catch a backdoor that may be hidden by a single coder deep inside hundreds of thousands of lines of code," said Harold
"This is why NetSec builds its products on an operating system (OpenBSD) that has made security its number one goal," Harold told SOURCES. "The source for the operating system was re-built from the ground up for security and is publicly available. As a result, it is continuously subjected to rigorous security review by independent software engineers around the world. This has additional benefits because secure code often tends to be well designed, stable, and efficient."

rm -P .... kplox

But it's almost certainly true. Just look at OpenBSD's record. They went for a full decade without any vulnerabilities in the base system before one was eventually found.

Ouch! How did THIS get modded Insightful?

The truth is that OpenBSD has had several vulnerabilities in pretty much every release: just check out the errata. OpenBSD 4.7, for example, had two security fixes applied to it; 4.6 and 4.5 had three each; 4.4 had four; 4.3 had eight; 4.2 had nine; 4.1 had ten; 4.0 had eleven; and so on. And that's not counting reliability fixes.

That said, these holes are either local, or limited in their impact; the two holes that were eventually found in OpenBSD were *remote root* holes. (On a side note, it did not take "a full decade" for one of these to be found: it was about 5 years.)

Now, none of this is intended to rag on OpenBSD, BTW; the developers are doing a great job, and their diligence in actually responding to vulnerabilities and promptly issuing fixes is laudable. If anything, it shows that even when you're very diligent and extremely focussed on security, vulnerabilities will STILL happen: not just the rare huge ones but also many run-of-the-mill smaller ones.

For example, if you need to build a web server, you might pick OpenBSD because of its "secure-by-default" mantra. But what does that really buy you? You still need to run web server software, which is going to be the vector for any attack.

A security audited version of Apache, inside a chroot jail, is part of the standard install.

Please check your facts before posting. You'll avoid sounding like a trolling fanboi.

For example, if you need to build a web server, you might pick OpenBSD because of its "secure-by-default" mantra. But what does that really buy you? You still need to run web server software, which is going to be the vector for any attack.

A security audited version of Apache, inside a chroot jail, is part of the standard install.

Please check your facts before posting. You'll avoid sounding like a trolling fanboi.

That is the battle you're discussing.
SELinux vs Integrated Cryptography.

I'm pretty sure they are both going to have trade offs.

Are those decimal (1,000,000) or binary (1,048,576) megabytes?

The real kind that computers use.

Upgrade to OpenBSD 4.7 to 4.8 is as simple as booting the machine on the CD, and selecting (U)pgrade instead of (I)nstall.

Make sure you make a backup of your /etc/ directory beforehand and you are good to go. The upgrade process should keep your configuration intact, but it never hurts to be a bit cautious.

I'll note that i have been upgrading the same machine from OpenBSD 3.9 all the way to 4.8 without major problems.

Unless you have a very good reason to, do not use ports: use (pre-compiled) packages. Upgrading packages is as simple as typing: 'pkg_add' with the correct options. See here for more details: http://openbsd.org/faq/faq15.html#PkgUpdate

That's all there is to it. OpenBSD is a very simple operating system to use, and one that is a pleasure to upgrade and maintain.

The release song doesn't even have lyrics :-(
How good can the release be then, I ask!

Better than Kenny G, but a little worse than anti-lock brakes.

I'm curious. Having never used a BSD-based system, how are upgrades managed? I understand that instead of installing packages, one uses ports. My impression of that is that you run a file in a ports directory and it compiles the software and installs it. Correct me if I'm wrong.

Ports are meant for building packages. Users should only use packages normally. You can update your packages after you upgraded your base system with "pkg_add -ui -D update -D updatedepends"

But how does one upgrade from, say, OpenBSD 4.7 to 4.8?

OpenBSD has excellent docs and FAQ's: http://openbsd.org/faq/upgrade48.html

The release song doesn't even have lyrics :-(
How good can the release be then, I ask!

Someone forgot the infamous song release for 4.8 to be included in article details: El Puffiachi

Security needs to be designed in from the ground up.

Well OpenBSD it practically is. Some articles claim it is written ground up for security, but in reality they audited the entire BSD codebase many years ago, rewriting large parts and all new code is ground-up secure. In practice it is extremely secure, many of the bugs that occur in other BSDs or linux turn out to have been fixed months or years before in openBSD

But I'd just start with Android or Linux,

Better yet, OpenBSD. It's already audited.

I see your iptables and raise you pf, because my god iptables is cryptic.

http://tinyurl.com/linuxbad. Reason for http://openbsd.org/ and http://freebsd.org./

Openbsd proudly lists their commercial spin-offs: http://www.openbsd.org/products.html, RTMX, syscall, Genua, vantronix, Fox-IT, LegatoCRM, MyRestaurant, are essentially derivative distros of openbsd. How many of those companies contribute back to the kernel?

I will stop there.

there are three different kernels and userlands between major BSD families. Where BSD's share userlands, it is likely because they use large GPL code bases like gnome or KDE. You do not see regular exchanges of code among the BSD's and Mac OS-X for example. Do you see patches coming in from NetAPP? no? The filers use NetApp's proprietary operating system called Data ONTAP which includes code borrowed from Berkeley Net/2 BSD Unix and other operating systems.[7] D http://en.wikipedia.org/wiki/NetApp

The point is that there is a great deal of usage of BSD, but they are very often parallel, independent forks, and do little to make the OS family, as a whole, mature.

In contrast, There is a single linux kernel. Distros take snapshots at different times, but patches invariably make their way back to the main tree, so it is fundamentally shared. In contrast, Each BSD has their own kernel, and exchange of drivers and features is a laborious affair involving porting the program. All the linuxes get their drivers from basically the same tree (albeit often different versions.) The same goes for the userland, where substantially the same packages are used.

While there are occasional competing implementations, there aren't several kernels and basic libs being developed in parallel for the heck of it. There are not private companies taking the whole OS, extending it for their particular use, and then selling the result without contributing the extensions back to the main tree. (hello, netapp, apple, MS (tcp stack), and many other documented cases.)

GPL is about being greedy in your freedom, wanting companies and people that have the freedom to build businesses on the software have to help build the ecosystem and foundation for those who come after to do the same.

In our polytheism world we can have multiple gods, so we have a secure OS that can run QMail and DJBDNS

Are they hosting the website on an A500?

That I don't know.

But if they where (not on an A500 I suppose ...), what OS would they had used?

http://en.wikipedia.org/wiki/Amiga_Unix
http://www.amigaunix.com/tiki-index.php

But of course it would had worked with more common stuff aswell:
http://www.debian.org/ports/m68k/
http://www.netbsd.org/ports/amiga/
http://www.openbsd.org/amiga.html

Oh, and this Google hit reminds of the days of doom:
http://www.amigahistory.co.uk/linuxchoice.html

And what if you want to stop China, Russia or Google from "spying on your stuff"?

http://www.openbsd.org/
http://www.sun.com/software/solaris/trustedsolaris/index.xml

It is never a happy occasion to realize that a not-for-profit group, no matter how destitute or successful, is undeserving of charitable donations. And just last week I had such an unhappy realization. I wanted to donate a sizable sum of money to the OpenBSD Foundation for development of the OpeBSD operating system and other related projects.

My uncle, an old Unix graybeard from the Seventies, devoted his retirement and considerable savings to teaching inner-city youth about computers and programming. He recently passed away and left instructions in his will that I donate money, in the amount of US $100,000, to the most meritorious Free, Unix-like operating system as according to my own research into the matter.

I immediately looked at OpenBSD and began to review its technical merits, of which there are many. Despite lacking serious symmetric multi-processing support and drivers for recent graphics hardware, OpenBSD security and code-auditing are second to none. One only has to take a look at the bevy of routers that ship with OpenBSD to know how many people successfully depend on it everyday.

The OpenBSD Foundation is also behind several software packages widely adopted in other operating systems, such as OpenBGPD, OpenCVS, OpenNTPD, and OpenSSH. OpenSSH, for instance, is what allows clueless Mac users to remotely log into their systems safely, blissfully unaware of hackers.

After looking at the technical merits of OpenBSD and related projects, I owed it to the memory of my uncle to check out the history of the people behind it all. But that's when I ran into some interesting decisions regarding OpenBSD advocacy and funding made my OpenBSD's lead developer, Theo de Raadt.

In 2003, Mr. de Raadt trash-talked the United States military and its various aid projects for the Iraqi people. But at the time, OpenBSD was receiving a multi-million dollar grant from the United States Department of Defense. After the interview was published the DOD cancelled funding, which left several OpenBSD projects in limbo for quite some time thereafter.

This is just one of the more public instances of Mr. de Raadt sharing unpopular personal opinions while acting as OpenBSD's public advocate and costing the project considerable time and money. And, unfortunately, there are others.

Another time, Mr. de Raadt visited his native South Africa to receive a donation from a wealthy politician but unexpectedly refused it at the podium, instead making a speech in which he equated the use of non-Free graphics drivers with Apartheid. Mr. de Raadt left without the check but later claimed to have won an important moral victory.

Mr. de Raadt himself is at the root of the problem, but here I can't really separate the man from the project; Theo de Raadt is OpenBSD. So donating toward OpenBSD's goals means handing over money to this crackpot activist, if he would even accept it. That's too bad because OpenBSD would be further ahead without these sorts of megalomaniacal antics.

Digging even further back in time, it's clear that this pattern of behavior is nothing new. Theo de Raadt was one of the incipient developers of NetBSD, but harass[ed] and abuse[d] both users and developers of NetBSD. His colleagues subsequently locked him out of the project, de Raadt forked OpenBSD, and the rest is history.

After reviewing these facts, it is clear that I will fail to honor my uncle's memory and all of the hard work he did in life by donating to OpenBSD. If I wanted to dishonor him, maybe. And I find it highly likely that Theo de Raadt

I was a long-time OpenBSD user since the 3.1 days, and cut my teeth on Unix development there. I was attracted by its focus on security and conscientious coding practices. I was happy through the early 4.x days, but the more I got involved in developing for OpenBSD the more I was dissuaded from doing so.

Part of the issue was this focus on security. After I began to use OpenBSD at home and at work in earnest, I realized that it was limited in hardware support compared to other operating systems. I purchased a new workstation and portable within a year of each other, and both times came to some unhappy realizations about OpenBSD support.

I began to seriously look at Linux and FreeBSD at this point, knowing hardware support was much more robust. (I had also looked at NetBSD, but even though it booted on nearly everything, driver support was anemic.) I started to dual-boot FreeBSD on my workstation, and spent more and more time there. But it wasn't only hardware support that pushed me away from OpenBSD.

The FreeBSD development model is, to say the least, more sensible. Like I said, the more I got involved with OpenBSD development the more I was turned away, and that was mostly due to the project leader's attitude. During the run-up to OpenBSD 4.2, Theo de Raadt had been in a couple highly-publicized arguments with Linux developers, rubbing a ton of people the wrong way.

What many don't understand is that this was not an isolated incident. Try being an OpenBSD developer! These kind of scathing verbal assaults happened all of the time on the mailing lists. I wasand still am, actuallyunsure whether Theo doesn't give a shit due to some philosophical stance, or can't help it due to something like Asperger syndrome. In either case, he typically drags anyone he disagrees with over the coals, all while telling them to stop taking it personally.

I wish Theo had taken some of his own advice. I believe he has hurt the OpenBSD platform more than he has helped it, and I also firmly believe that hardware support in OpenBSD sucks not because of code auditing practices or security focus, but because Theo has either scared or purposefully chased away developers.

Long-time OpenBSD developers might migrate to FreeBSD or Darwin; newbies might try for Linux instead. Those who taste the de Raadt wrath, however, always run in the end. One time, a friend of mine incurred his ire by asking the wrong question at the wrong time, and Theo de Raadt hacked his router and remotely remapped his keyboard!

This is abuse, plain and simple, and Theo's relationship with his developers is abusive. I feel bad for anyone who has to engage him in real life, and fear something Reiser-like happening in the future. This controlling, manipulative attitude coupled with periodic violent outbursts indicates a deep-seated mental health issue that has gone unchecked for far too long. If you are an OpenBSD developer, watch your back!

After all this mess, I switched to FreeBSD 7.2 and never looked back. I upgraded to FreeBSD 7.3 and started using FreeBSD 8 as soon as it was in pre-release, and I am eagerly working on FreeBSD 8.1. I feel spoiled now, too, because of the throng of developers devoted to professionally working the FreeBSD platform into something spectacular instead of naggling over trivial matters or admonishing one another.

The thriving FreeBSD ecosystem contrasts sharply with the Jonestown-like atmosphere of OpenBSD. There is also the fact that no one person looms so largely over any other; ego is checked at the door in FreeBSD since the goal is to make a great operating system, not lord over others like David Karesh and a harem of 14-year-old girls.

Feel free to disagree with me or point out counter-examples; I would love to read them now that I have left OpenBSD. I will always have a soft spot in my heart for the little secure operating system even though it leaves me with chills. I sometimes fondly load www.openbsd.org and read the latest release notes and smile wistfully.

It's okay to smile, now that I'm free from OpenBSD.

I was a long-time OpenBSD user since the 3.1 days, and cut my teeth on Unix development there. I was attracted by its focus on security and conscientious coding practices. I was happy through the early 4.x days, but the more I got involved in developing for OpenBSD the more I was dissuaded from doing so.

Part of the issue was this focus on security. After I began to use OpenBSD at home and at work in earnest, I realized that it was limited in hardware support compared to other operating systems. I purchased a new workstation and portable within a year of each other, and both times came to some unhappy realizations about OpenBSD support.

I began to seriously look at Linux and FreeBSD at this point, knowing hardware support was much more robust. (I had also looked at NetBSD, but even though it booted on nearly everything, driver support was anemic.) I started to dual-boot FreeBSD on my workstation, and spent more and more time there. But it wasn't only hardware support that pushed me away from OpenBSD.

The FreeBSD development model is, to say the least, more sensible. Like I said, the more I got involved with OpenBSD development the more I was turned away, and that was mostly due to the project leader's attitude. During the run-up to OpenBSD 4.2, Theo de Raadt had been in a couple highly-publicized arguments with Linux developers, rubbing a ton of people the wrong way.

What many don't understand is that this was not an isolated incident. Try being an OpenBSD developer! These kind of scathing verbal assaults happened all of the time on the mailing lists. I wasand still am, actuallyunsure whether Theo doesn't give a shit due to some philosophical stance, or can't help it due to something like Asperger syndrome. In either case, he typically drags anyone he disagrees with over the coals, all while telling them to stop taking it personally.

I wish Theo had taken some of his own advice. I believe he has hurt the OpenBSD platform more than he has helped it, and I also firmly believe that hardware support in OpenBSD sucks not because of code auditing practices or security focus, but because Theo has either scared or purposefully chased away developers.

Long-time OpenBSD developers might migrate to FreeBSD or Darwin; newbies might try for Linux instead. Those who taste the de Raadt wrath, however, always run in the end. One time, a friend of mine incurred his ire by asking the wrong question at the wrong time, and Theo de Raadt hacked his router and remotely remapped his keyboard!

This is abuse, plain and simple, and Theo's relationship with his developers is abusive. I feel bad for anyone who has to engage him in real life, and fear something Reiser-like happening in the future. This controlling, manipulative attitude coupled with periodic violent outbursts indicates a deep-seated mental health issue that has gone unchecked for far too long. If you are an OpenBSD developer, watch your back!

After all this mess, I switched to FreeBSD 7.2 and never looked back. I upgraded to FreeBSD 7.3 and started using FreeBSD 8 as soon as it was in pre-release, and I am eagerly working on FreeBSD 8.1. I feel spoiled now, too, because of the throng of developers devoted to professionally working the FreeBSD platform into something spectacular instead of naggling over trivial matters or admonishing one another.

The thriving FreeBSD ecosystem contrasts sharply with the Jonestown-like atmosphere of OpenBSD. There is also the fact that no one person looms so largely over any other; ego is checked at the door in FreeBSD since the goal is to make a great operating system, not lord over others like David Karesh and a harem of 14-year-old girls.

Feel free to disagree with me or point out counter-examples; I would love to read them now that I have left OpenBSD. I will always have a soft spot in my heart for the little secure operating system even though it leaves me with chills. I sometimes fondly load www.openbsd.org and read the latest release notes and smile wistfully.

It's okay to smile, now that I'm free from OpenBSD.

I was a long-time OpenBSD user since the 3.1 days, and cut my teeth on Unix development there. I was attracted by its focus on security and conscientious coding practices. I was happy through the early 4.x days, but the more I got involved in developing for OpenBSD the more I was dissuaded from doing so.

Part of the issue was this focus on security. After I began to use OpenBSD at home and at work in earnest, I realized that it was limited in hardware support compared to other operating systems. I purchased a new workstation and portable within a year of each other, and both times came to some unhappy realizations about OpenBSD support.

I began to seriously look at Linux and FreeBSD at this point, knowing hardware support was much more robust. (I had also looked at NetBSD, but even though it booted on nearly everything, driver support was anemic.) I started to dual-boot FreeBSD on my workstation, and spent more and more time there. But it wasn't only hardware support that pushed me away from OpenBSD.

The FreeBSD development model is, to say the least, more sensible. Like I said, the more I got involved with OpenBSD development the more I was turned away, and that was mostly due to the project leader's attitude. During the run-up to OpenBSD 4.2, Theo de Raadt had been in a couple highly-publicized arguments with Linux developers, rubbing a ton of people the wrong way.

What many don't understand is that this was not an isolated incident. Try being an OpenBSD developer! These kind of scathing verbal assaults happened all of the time on the mailing lists. I wasand still am, actuallyunsure whether Theo doesn't give a shit due to some philosophical stance, or can't help it due to something like Asperger syndrome. In either case, he typically drags anyone he disagrees with over the coals, all while telling them to stop taking it personally.

I wish Theo had taken some of his own advice. I believe he has hurt the OpenBSD platform more than he has helped it, and I also firmly believe that hardware support in OpenBSD sucks not because of code auditing practices or security focus, but because Theo has either scared or purposefully chased away developers.

Long-time OpenBSD developers might migrate to FreeBSD or Darwin; newbies might try for Linux instead. Those who taste the de Raadt wrath, however, always run in the end. One time, a friend of mine incurred his ire by asking the wrong question at the wrong time, and Theo de Raadt hacked his router and remotely remapped his keyboard!

This is abuse, plain and simple, and Theo's relationship with his developers is abusive. I feel bad for anyone who has to engage him in real life, and fear something Reiser-like happening in the future. This controlling, manipulative attitude coupled with periodic violent outbursts indicates a deep-seated mental health issue that has gone unchecked for far too long. If you are an OpenBSD developer, watch your back!

After all this mess, I switched to FreeBSD 7.2 and never looked back. I upgraded to FreeBSD 7.3 and started using FreeBSD 8 as soon as it was in pre-release, and I am eagerly working on FreeBSD 8.1. I feel spoiled now, too, because of the throng of developers devoted to professionally working the FreeBSD platform into something spectacular instead of naggling over trivial matters or admonishing one another.

The thriving FreeBSD ecosystem contrasts sharply with the Jonestown-like atmosphere of OpenBSD. There is also the fact that no one person looms so largely over any other; ego is checked at the door in FreeBSD since the goal is to make a great operating system, not lord over others like David Karesh and a harem of 14-year-old girls.

Feel free to disagree with me or point out counter-examples; I would love to read them now that I have left OpenBSD. I will always have a soft spot in my heart for the little secure operating system even though it leaves me with chills. I sometimes fondly load www.openbsd.org and read the latest release notes and smile wistfully.

It's okay to smile, now that I'm free from OpenBSD.

Hmm. Replying to myself, I see I may have spoken a little too hastily:

http://www.netbsd.org/ports/#ports-by-cpu

http://www.openbsd.org/armish.html

I don't really have time to answer your other points, but systrace is in the base system, and to my knowledge it has never been in ports. So yes if you do a fresh install of OpenBSD 3.2 or later you will get systrace.

See eg http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/systrace.c

This sounds a lot like what securelevel(7) already does.

Nope. Not at all similar in terms of capabilites. Securelevels are a pale imitation of what you can do with MAC, not even close.
If you really think securelevls are at all close to MAC, then you really don't understand MAC.

There is absolutely no reason to put up walls so the sysadmin can't do anything, rather than fix the bugs that let an attacker gain root in the first place.

It's not putting up walls, it's enforcing secure policy and good practice, and sometimes the law.

Sepeartion of duty, read up on it.

The mailserver is just an example. There is plenty of insecure software running as root.

FTFY

MAC cannot prevent the exploit as such, but it can make the attacker completely limitless. You can take away execute permission, write permission (allowing just append), no file creation, absolutely nothing except the very minimal that the program actually needs.

This sounds a lot like what securelevel(7) already does.

There is absolutely no reason to have a user with absolute power when we have the technology to segregate power and duties, there by significantly reducing the attack surface.

There is absolutely no reason to put up walls so the sysadmin can't do anything, rather than fix the bugs that let an attacker gain root in the first place.

openBSD used to have the beastie until 2.x, I think.

I've got a shirt with him and "openBSD" on it :-)

I still think the "greasy cop" mascot from 2.5 was the best though. picture

OpenBSD doesn't want to take over the world, see the project goals. This doesn't stop their work becoming used on a large scale, but this happens because of the software's features and technical superiority.

On the other hand, many Linux advocates seem to be obsessed with the idea of world domination. I've seen these people choose Ubuntu for reinstall/upgrade jobs when their friends and family would genuinely be more comfortable, and better off, with Windows or OS X.

Decide for yourself which is the more noble goal.

Are you trying to point out that the FSF is run by hypocrites?

Sorry, you are late:

http://openbsd.org/lyrics.html#43

What about tying a firewall into an authentication system so that when jdoe logs in, only then are the firewalls opened to pass her traffic?

OpenBSD has had this for a while now. It's called authpf, and it can dynamically load NAT or redirection rules in addition to simply opening ports.

You won't find a better firewall than pf. It's secure, extremely capable, and has a logical and refined syntax for defining rulesets.

What about tying a firewall into an authentication system so that when jdoe logs in, only then are the firewalls opened to pass her traffic?

OpenBSD has had this for a while now. It's called authpf, and it can dynamically load NAT or redirection rules in addition to simply opening ports.

You won't find a better firewall than pf. It's secure, extremely capable, and has a logical and refined syntax for defining rulesets.

spamd with tarpitting: reduce any bandwidth/power costs to next to nothing.

I wouldn't characterize it as a "mess", but I do notice there are some changes to to pf rules syntax, so some rewriting of your firewall rules might be required.

I've been using OpenBSD since around 2.7. I've come to really trust the judgment of the developers in general, and the pf developers in particular. I've yet to see them break backwards compatibility without good reason.

See the upgrade guide for upgrading 4.5 to 4.6... it's a 280 line upgrade guide:
http://www.openbsd.org/faq/upgrade46.html ...on RedHat and CentOS, to go from RHEL 5.3 to RHEL 5.4 I did "yum -y update". That's it.

You can just do the OpenBSD upgrade without reading those instructions... as you did with RHEL.

If you'd actually started to read those instructions, you'd have seen they outline basically all feature changes between the previous and current release. See:

scrub in all no-df max-mss 1440

can be replaced with a rule using the new "match" action:

        match in all scrub (no-df max-mss 1440)

Did the yum upgrade automatically make all necessary syntax changes in all corner cases in your config files to adapt them for the newest versions of the software? Obviously not... You're left to figure those out yourself. If the new version of iptables uses different options for some obscure option, you're screwed. Oh well, guess you should have read the RHEL 5.4 errata, which happens to be SEVERAL THOUSAND LINES http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Release_Notes/index.html