freebsd-ports/security/fwknop/Makefile

31 lines
637 B
Makefile
Raw Normal View History

# Created by: Sean Greven <sean.greven@gmail.com>
New port: security/fwknop fwknop,"FireWall KNock OPerator", implements Single Packet Authorization (SPA). fwknop stands for the "FireWall KNock OPerator", and implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based around a default-drop packet filter (fwknop supports both iptables on Linux systems and ipfw on FreeBSD and Mac OS X systems) and libpcap. SPA requires only a single encrypted packet in order to communicate various pieces of information including desired access through an iptables policy and/or complete commands to execute on the target system. By using iptables to maintain a "default drop" stance, the main application of this program is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. With fwknop deployed, anyone using nmap to look for sshd can't even tell that it is listening; it makes no difference if they have a 0-day exploit or not. The authorization server passively monitors authorization packets via libcap and hence there is no "server" to which to connect in the traditional sense. Access to a protected service is only granted after a valid encrypted and non-replayed packet is monitored from an fwknop client (see the following network diagram; the SSH session can only take place after the SPA packet is monitored): PR: ports/118229 Submitted by: Sean Greven <sean.greven@gmail.com>
2008-06-12 23:43:51 -04:00
# $FreeBSD$
PORTNAME= fwknop
PORTVERSION= 2.0.4
New port: security/fwknop fwknop,"FireWall KNock OPerator", implements Single Packet Authorization (SPA). fwknop stands for the "FireWall KNock OPerator", and implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based around a default-drop packet filter (fwknop supports both iptables on Linux systems and ipfw on FreeBSD and Mac OS X systems) and libpcap. SPA requires only a single encrypted packet in order to communicate various pieces of information including desired access through an iptables policy and/or complete commands to execute on the target system. By using iptables to maintain a "default drop" stance, the main application of this program is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. With fwknop deployed, anyone using nmap to look for sshd can't even tell that it is listening; it makes no difference if they have a 0-day exploit or not. The authorization server passively monitors authorization packets via libcap and hence there is no "server" to which to connect in the traditional sense. Access to a protected service is only granted after a valid encrypted and non-replayed packet is monitored from an fwknop client (see the following network diagram; the SSH session can only take place after the SPA packet is monitored): PR: ports/118229 Submitted by: Sean Greven <sean.greven@gmail.com>
2008-06-12 23:43:51 -04:00
CATEGORIES= security
MASTER_SITES= http://www.cipherdyne.org/fwknop/download/
MAINTAINER= sean.greven@gmail.com
2012-07-25 07:24:09 -04:00
COMMENT= SPA implementation for Linux and FreeBSD
New port: security/fwknop fwknop,"FireWall KNock OPerator", implements Single Packet Authorization (SPA). fwknop stands for the "FireWall KNock OPerator", and implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based around a default-drop packet filter (fwknop supports both iptables on Linux systems and ipfw on FreeBSD and Mac OS X systems) and libpcap. SPA requires only a single encrypted packet in order to communicate various pieces of information including desired access through an iptables policy and/or complete commands to execute on the target system. By using iptables to maintain a "default drop" stance, the main application of this program is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. With fwknop deployed, anyone using nmap to look for sshd can't even tell that it is listening; it makes no difference if they have a 0-day exploit or not. The authorization server passively monitors authorization packets via libcap and hence there is no "server" to which to connect in the traditional sense. Access to a protected service is only granted after a valid encrypted and non-replayed packet is monitored from an fwknop client (see the following network diagram; the SSH session can only take place after the SPA packet is monitored): PR: ports/118229 Submitted by: Sean Greven <sean.greven@gmail.com>
2008-06-12 23:43:51 -04:00
OPTIONS_DEFINE= GPGME
OPTIONS_DEFAULT= GPGME
GPGME_DESC= Build support for gpgme
MAN8= fwknop.8 fwknopd.8
INFO= libfko
MANCOMPRESSED= no
GNU_CONFIGURE= yes
USE_RC_SUBR= fwknopd
USE_LDCONFIG= yes
.include <bsd.port.options.mk>
.if ${PORT_OPTIONS:MGPGME}
LIB_DEPENDS+= gpgme:${PORTSDIR}/security/gpgme
.else
CONFIGURE_ARGS+=--without-gpgme
.endif
New port: security/fwknop fwknop,"FireWall KNock OPerator", implements Single Packet Authorization (SPA). fwknop stands for the "FireWall KNock OPerator", and implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based around a default-drop packet filter (fwknop supports both iptables on Linux systems and ipfw on FreeBSD and Mac OS X systems) and libpcap. SPA requires only a single encrypted packet in order to communicate various pieces of information including desired access through an iptables policy and/or complete commands to execute on the target system. By using iptables to maintain a "default drop" stance, the main application of this program is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. With fwknop deployed, anyone using nmap to look for sshd can't even tell that it is listening; it makes no difference if they have a 0-day exploit or not. The authorization server passively monitors authorization packets via libcap and hence there is no "server" to which to connect in the traditional sense. Access to a protected service is only granted after a valid encrypted and non-replayed packet is monitored from an fwknop client (see the following network diagram; the SSH session can only take place after the SPA packet is monitored): PR: ports/118229 Submitted by: Sean Greven <sean.greven@gmail.com>
2008-06-12 23:43:51 -04:00
.include <bsd.port.mk>