Captive portal with OpenBSD as a hostap
Hi all, I have installed an openbsd vm to works as a hostap for tablets and smartphones (android and iOS). All it is working ok: pf, hostapd and dhcpd server. All tablets and smartphones that I have tested works ok, connects and surfs Internet. But now I am thinking to use some type of auth (user/pass using a SSL/TLS channel) instead to use wpa/wpa2 keys. Sometime ago exists this project: Chillispot (http://www.chillispot.org/) but it seems discontinued. Someone knows any type of project/software to accomplish?? I would like to keep simple as much as I can. Thanks.
Re: Captive portal with OpenBSD as a hostap
On 10/05/2015 12:29 PM, Kapetanakis Giannis wrote: On 05/10/15 14:35, David Coppa wrote: On Mon, Oct 5, 2015 at 1:18 PM, C.L. Martinez wrote: Hi all, I have installed an openbsd vm to works as a hostap for tablets and smartphones (android and iOS). All it is working ok: pf, hostapd and dhcpd server. All tablets and smartphones that I have tested works ok, connects and surfs Internet. But now I am thinking to use some type of auth (user/pass using a SSL/TLS channel) instead to use wpa/wpa2 keys. Sometime ago exists this project: Chillispot (http://www.chillispot.org/) but it seems discontinued. Someone knows any type of project/software to accomplish?? I would like to keep simple as much as I can. Thanks. You could try CoovaChilli. https://github.com/sevan/coova-chilli/ http://coova.github.io/ Ciao David Another option you could look is authpf(8) which is in base. Not web based captive portal, but similar setup with ssh. G Thanks to both ... Previously, I am thinking to use authpf, but there is a problem: I need to install a ssh client in these tablets and smartphones .. If I could find any front-end to use with authpf, it will be the perfect solution. About coova-chilli: well, maybe it is the only solution if I can't use something similar to authpf. But it seems "too heavy" to maintain ...
Your opinion about using rdomain or mpath
Hi all, I am using an OpenBSD vm to act as a firewall for my laptop and as openVPN client to connect to several openvpn/ipsec servers. Sometimes I need to stay connected to two or more openvpn/ipsec gateways. And at the same time, I need to stay connected to other networks in my company (which are reached via default gateway). As you can imagine, this scenario present some problems about how to setup pf rules and manage different default gateways. I see two possible solutions: rdomains or mpath. On the other side, I can't make changes on openvpn/ipsec servers due to they are out of my control. In your opinion, what is the best option: rdomains or mpath? In both cases I see one problem: I have only one external interface. How to deal with this? Thanks.
Re: Your opinion about using rdomain or mpath
On 10/14/2015 01:17 PM, Giancarlo Razzolini wrote:
Em 14-10-2015 09:28, C.L. Martinez escreveu:
I am using an OpenBSD vm to act as a firewall for my laptop and as
openVPN client to connect to several openvpn/ipsec servers.
Your laptop is also running OpenBSD?
Nop. It is a CentOS 7.x
In your opinion, what is the best option: rdomains or mpath? In both
cases I see one problem: I have only one external interface. How to
deal with this?
You really, really need multiple default gateways?
Yes because sometimes I will need two or more tunX interfaces up
(created by openvpn or openconnect) or enc interface.
Because if you only
need to access some networks behind the OpenVPN/IPsec servers, wouldn't
it be easier if you got the routes to these networks and their
respective gateways from the OpenBSD firewall? If you are using dhcpd,
then it can send custom routes to your machine. There is one caveat
though, it should also send a default route. Something like this should do:
host laptop {
option classless-static-routes , ,
0.0.0.0/0 ;
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address x.x.x.x; #optional
}
In the case of openconnect and openvpn, IP's are served by the gateways
(out of my control). With IPSec tunnels, I use fixed ips in
configuration files.
With this you only need to deal with pass rules on your pf.conf, and you
can selectively send the routes you want only to specific clients. Now,
about mpath or rdomain, mpath is for configuring multiple default
gateways for connections originating from the OpenBSD firewall itself.
All tunnels will be generated by this OpenBSD vm, not from my CentOS
host os.
For connections coming from the machines behind it, you only need
route-to rules on your pf.conf, no need for configuring the multiple
default gateways on the OpenBSD machine, unless you want to keep ntpd
running,
Well, due to this is a vm, I need to keep OpenBSD synced. Yes, I run
ntpd in this vm.
In this case I find that using mpath along side with ifstated, it's
easier than use rdomain. Specially if your network layout is simple.
But, ifstated is not need it in this scenario. If some of the tunnels
goes down, I will loose some connections, but other connections will
keep alive, for example DNS requests to our internal servers. Meanwhile
I don't loose default gateway in the primary routing table, I can live
with it.
Re: Your opinion about using rdomain or mpath
On 10/14/2015 02:20 PM, Giancarlo Razzolini wrote: Em 14-10-2015 10:31, C.L. Martinez escreveu: Yes because sometimes I will need two or more tunX interfaces up (created by openvpn or openconnect) or enc interface. I think you are confusing gateways with default gateways. No, but maybe I am explainning wrong ... In the case of openconnect and openvpn, IP's are served by the gateways (out of my control). With IPSec tunnels, I use fixed ips in configuration files. Either way, the VPN servers, normally, will be gateways for specific networks, not the entire internet. So they are not "default" gateways. Correct, but some of our customers had configured their openvpn servers to route all traffic over their servers .. All tunnels will be generated by this OpenBSD vm, not from my CentOS host os. From the point of view of the CentOS machine, your OpenBSD vm can "reach" the internet and also the networks behind the VPN's. There is one thing to remember though, if your VPN servers do not know how to get back to your LAN network (the one your CentOS is), you'll need to use nat on the OpenBSD firewall. Exactly. I need to use NAT in this OpenBSD fw. Well, due to this is a vm, I need to keep OpenBSD synced. Yes, I run ntpd in this vm. Well, you should always use ntpd. Not just because it's a vm. But, ifstated is not need it in this scenario. If some of the tunnels goes down, I will loose some connections, but other connections will keep alive, for example DNS requests to our internal servers. Meanwhile I don't loose default gateway in the primary routing table, I can live with it. Exactly why I said you're mixing gateways with default gateways. You would use mpath if you have, lets say, two ISP's and you want your OpenBSD machine to use both, for connections originating from it. Of course mpath aren't used just for default gateways (0.0.0.0/0 routes). Belive me: I am not confusing gateways with default gateways. For example, using a free VPN connection, like vpnbook: root@dundee:/var/log# netstat -rn -f inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 0/110.9.3.1 UGS01 - 8 tun0 default172.30.77.1UGS5 214405 - 8 vio1 10.9.0.1/3210.9.3.1 UGS00 - 8 tun0 10.9.3.1 10.9.3.2 UH 30 - 4 tun0 10.9.3.2 10.9.3.2 UHl00 - 1 lo0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHl3 1956 32768 1 lo0 128/1 10.9.3.1 UGS0 10 - 8 tun0 172.22.54.0/29 link#3 UC 00 - 4 vio2 172.22.54.652:54:00:78:64:85 UHLl 00 - 1 lo0 172.22.54.7link#3 UHLb 00 - 1 vio2 172.22.55.0/28 link#1 UC 20 - 4 vio0 172.22.55.1f2:d6:fa:0d:f3:4c UHLc 2 173062 - 4 vio0 172.22.55.252:54:00:1f:03:34 UHLc 0 2914 - 4 vio0 172.22.55.11 52:54:00:bf:1a:b6 UHLl 00 - 1 lo0 172.22.55.14 52:54:00:bf:1a:b6 UHLl 00 - 1 lo0 172.22.55.15 link#1 UHLb 00 - 1 vio0 172.22.56.0/29 link#4 UC 10 - 4 vio3 172.22.56.352:54:00:f5:51:26 UHLc 02 - 4 vio3 172.22.56.652:54:00:ba:da:27 UHLl 00 - 1 lo0 172.22.56.7link#4 UHLb 00 - 1 vio3 172.22.57.0/29 link#5 UC 10 - 4 vio4 172.22.57.352:54:00:13:57:5f UHLc 0 7543 - 4 vio4 172.22.57.652:54:00:a2:86:ab UHLl 00 - 1 lo0 172.22.57.7link#5 UHLb 00 - 1 vio4 172.22.58.0/29 link#6 UC 10 - 4 vio5 172.22.58.152:54:00:4b:fd:a4 UHLl 00 - 1 lo0 172.22.58.260:be:b5:30:5b:d2 UHLc 2 5414 - 4 vio5 172.22.58.7link#6 UHLb 00 - 1 vio5 172.30.77.0/29 link#2 UC 10 - 4 vio1 172.30.77.1fe:54:00:16:db:3c UHLc 20 - 4 vio1 172.30.77.652:54:00:16:db:3c UHLl 00 - 1 lo0 172.30.77.7link#2 UHLb 00 - 1 vio1 176.126.237.217/32 172.30.77.1UGS122518 - 8 vio1 224/4 127.0.0.1 URS00 32768 8 lo0 ALL traffic is routed over tun0 interfac
Re: Remove "flags S/SA keep state" for tcp packets
On 12/15/2015 07:29 PM, Stuart Henderson wrote: On 2015-12-15, C. L. Martinez wrote: On Tue, Dec 15, 2015 at 9:56 AM, David Dahlberg wrote: Am Dienstag, den 15.12.2015, 09:24 + schrieb C. L. Martinez: I am trying to remove "flags S/SA keep state" for tcp packets inside pf.conf and use "keep state" only, as it can do with udp and icmp. According to pf.conf man page, this is possible inserting "no state" in tcp rule, but I can't use keep state. "keep state" is addressed in pf.conf(5) (e.g. "Stateful Tracking Options"), but it is not mentioned as often as it is the default. IOW: If you have not changed the default options, you you may simply remove "flags S/SA keep state" string without changing mutch (except that it might now also match UDP/ICMP). Thanks David. I have not changed any default options but I can't see how can I remove these flags ... I have tried with "flags any keep state" without result. If I use "no state", packets are rejected ... "flags any no state" does remove the "flags s/sa" from the rule. If that doesn't help then perhaps that's not what the problem is. Ok, I have done more tests and maybe exists some type of incompatibility between how OpenBSD manage divert sockets and suricata. Has anyone tried to use Snort with OpenBSD divert sockets?
Re: Remove "flags S/SA keep state" for tcp packets (SOLVED)
On 12/16/2015 08:19 AM, C.L. Martinez wrote: On 12/15/2015 07:29 PM, Stuart Henderson wrote: On 2015-12-15, C. L. Martinez wrote: On Tue, Dec 15, 2015 at 9:56 AM, David Dahlberg wrote: Am Dienstag, den 15.12.2015, 09:24 + schrieb C. L. Martinez: I am trying to remove "flags S/SA keep state" for tcp packets inside pf.conf and use "keep state" only, as it can do with udp and icmp. According to pf.conf man page, this is possible inserting "no state" in tcp rule, but I can't use keep state. "keep state" is addressed in pf.conf(5) (e.g. "Stateful Tracking Options"), but it is not mentioned as often as it is the default. IOW: If you have not changed the default options, you you may simply remove "flags S/SA keep state" string without changing mutch (except that it might now also match UDP/ICMP). Thanks David. I have not changed any default options but I can't see how can I remove these flags ... I have tried with "flags any keep state" without result. If I use "no state", packets are rejected ... "flags any no state" does remove the "flags s/sa" from the rule. If that doesn't help then perhaps that's not what the problem is. Ok, I have done more tests and maybe exists some type of incompatibility between how OpenBSD manage divert sockets and suricata. Has anyone tried to use Snort with OpenBSD divert sockets? Ok, I have done some tests using Snort and it works!! ... Problem seems to be with Suricata. Many thanks to all for your help.
Doing NAT after divert-packet rule
Hi all,
This post is related to this one:
http://marc.info/?l=openbsd-misc&m=145017155902016&w=2. After doing a
lot of tests, I have arrived to a satisfactory situation.
At this moment, my divert-packet rules works (for all protocols
without modifying state options) to redirect traffic to an IDS (I am
doing these tests using Snort and Suricata).
BUt, I have a problem with NAT rules. If I am not wrong, a NAT rule
acts before a packet is diverted to specified socket.
I have done some tests using example program from divert(4) man page.
Here is the result:
root@dundee:/nsm/2015-12-18# test_divert
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
10.5.10.177:54967 -> 216.58.208.228:80
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
216.58.208.228:80 -> 172.22.55.4:58816
216.58.208.228:80 -> 172.22.55.4:58816
10.5.10.177:54967 -> 216.58.208.228:80
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
As you can see here, there are two private IP's: 10.5.10.177 and
172.22.55.4.
IP 10.5.10.177 is the external IP address for openbsd fw. 172.22.55.4
is an internal vm doing telnet to www.google.com port 80 (IP
216.58.208.228).
My relevant pf rules are:
set block-policy drop
set state-policy if-bound
# Scrubbing rules
match inall scrub (no-df)
match out on egress all scrub (random-id)
match on egress all scrub (reassemble tcp)
block all
pass in inet proto tcp from 172.22.55.4 to ! tag
intlans-to-inet
pass out quick on egress inet proto { tcp icmp udp } from 172.22.55.4
divert-packet port 8000 nat-to (vio1:0)
Stopping divert program example, and starting up a Suricata instance
(or Snort, results are the same), they only sees the natted address:
10.5.10.177. An example triggered alert:
12/18/2015-09:23:51.436216 [Drop] [**] [1:2:1] Reject web access to
Google [**] [Classification: Misc Attack] [Priority: 2] {TCP}
10.5.10.177:56172 -> 216.58.208.228:80
My question is: is it possible to NAT an ip after divert-packet rule
acts??
Thanks.
Re: Doing NAT after divert-packet rule
On 12/18/2015 10:17 AM, C.L. Martinez wrote:
Hi all,
This post is related to this one:
http://marc.info/?l=openbsd-misc&m=145017155902016&w=2. After doing a
lot of tests, I have arrived to a satisfactory situation.
At this moment, my divert-packet rules works (for all protocols
without modifying state options) to redirect traffic to an IDS (I am
doing these tests using Snort and Suricata).
BUt, I have a problem with NAT rules. If I am not wrong, a NAT rule
acts before a packet is diverted to specified socket.
I have done some tests using example program from divert(4) man page.
Here is the result:
root@dundee:/nsm/2015-12-18# test_divert
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
10.5.10.177:54967 -> 216.58.208.228:80
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
216.58.208.228:80 -> 172.22.55.4:58816
216.58.208.228:80 -> 172.22.55.4:58816
10.5.10.177:54967 -> 216.58.208.228:80
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
10.5.10.177:54967 -> 216.58.208.228:80
216.58.208.228:80 -> 172.22.55.4:58816
As you can see here, there are two private IP's: 10.5.10.177 and
172.22.55.4.
IP 10.5.10.177 is the external IP address for openbsd fw. 172.22.55.4
is an internal vm doing telnet to www.google.com port 80 (IP
216.58.208.228).
My relevant pf rules are:
set block-policy drop
set state-policy if-bound
# Scrubbing rules
match inall scrub (no-df)
match out on egress all scrub (random-id)
match on egress all scrub (reassemble tcp)
block all
pass in inet proto tcp from 172.22.55.4 to ! tag
intlans-to-inet
pass out quick on egress inet proto { tcp icmp udp } from 172.22.55.4
divert-packet port 8000 nat-to (vio1:0)
Stopping divert program example, and starting up a Suricata instance
(or Snort, results are the same), they only sees the natted address:
10.5.10.177. An example triggered alert:
12/18/2015-09:23:51.436216 [Drop] [**] [1:2:1] Reject web access to
Google [**] [Classification: Misc Attack] [Priority: 2] {TCP}
10.5.10.177:56172 -> 216.58.208.228:80
My question is: is it possible to NAT an ip after divert-packet rule
acts??
Thanks.
Please, any tip or idea??
Thanks.
Re: Error loading pf rules: Device busy
On 01/02/2016 08:33 AM, C. L. Martinez wrote: Hi all, I have a strange problem. Every time that I try to reload my pf rules I seethe following error message: pfctl: DIOCADDRULE: Device busy. I am using OpenBSD 5.8 amd64 fully patched. Any idea?? Sorry for the noise. There was an error in a customized anchor's rules. Thanks.
Problems using squid as transparent proxy for SSL/TLS
Hi all, I have configured squid in an OpenBSD host acting as a transparent proxy. Actually all works OK for all traffic except for SSL/TLS, ex: port 443. My pf rules are: pass in inet proto tcp from $prod_network to ! port $proxy_tcp_svcs divert-to localhost \ port 3129 label "Allow access to Internet via Proxy on port $dstport/$proto" pass in inet proto tcp from $prod_network to ! port https divert-to localhost \ port 3130 label "Allow access to Internet via Proxy on port $dstport/$proto" In my squid.conf: # Squid normally listens to port 3128 http_port 127.0.0.1:3128 http_port 127.0.0.1:3129 intercept http_port 127.0.0.1:3130 intercept ssl-bump cert=/etc/squid/ssl_cert/uxdom.org.cert key=/etc/squid/ssl_cert/uxdom.org.private \ generate-host-certificates=on version=1 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE When some internal client tries to connect to, for example, https://www.google.com: tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG Jan 04 16:34:10.750926 rule 16/(match) [uid 0, pid 1374] block out on vio0: 216.58.210.131.443 > 172.21.55.3.53694: R [bad tcp cksum 7aa1! -> 5af5] 157608502:157608502(0) win 0 (DF) (ttl 64, id 61853, len 40, bad ip cksum 7b96! -> bb5b) Jan 04 16:34:10.750956 rule 16/(match) [uid 0, pid 1374] block in on vio0: 172.21.55.3.53694 > 216.58.210.131.443: F [tcp sum ok] 2332161592:2332161592(0) ack 157608502 win 256 (ttl 128, id 12637, len 40) Jan 04 16:34:10.751003 rule 16/(match) [uid 0, pid 1374] block in on vio0: 172.21.55.3.53694 > 216.58.210.131.443: R [tcp sum ok] 1:1(0) ack 1274 win 0 (ttl 128, id 12639, len 40) Jan 04 16:34:10.751027 rule 16/(match) [uid 0, pid 1374] block in on vio0: 172.21.55.3.53694 > 216.58.210.131.443: R [tcp sum ok] 2332161585:2332161585(0) win 0 (DF) (ttl 128, id 12640, len 40) Jan 04 16:34:10.751047 rule 16/(match) [uid 0, pid 1374] block in on vio0: 172.21.55.3.53694 > 216.58.210.131.443: R [tcp sum ok] 2332161585:2332161585(0) win 0 (DF) (ttl 128, id 12641, len 40) Jan 04 16:34:10.752913 rule 16/(match) [uid 0, pid 1374] block out on vio0: 216.58.210.131.443 > 172.21.55.3.53695: R [bad tcp cksum b923! -> b16] 3886046168:3886046168(0) win 0 (DF) (ttl 64, id 24204, len 40, bad ip cksum 7b8f! -> 4e6d) Jan 04 16:34:10.752937 rule 16/(match) [uid 0, pid 1374] block in on vio0: 172.21.55.3.53695 > 216.58.210.131.443: . [tcp sum ok] ack 3886047652 win 256 (ttl 128, id 12644, len 40) I have tried to add a divert-reply rule: pass out on vio0 inet from $prod_network divert-reply .. but it doesn't works. What am I doing wrong?? Thanks.
Re: Problems using squid as transparent proxy for SSL/TLS
On 01/05/2016 04:29 PM, Stuart Henderson wrote: On 2016-01-05, Craig Skinner wrote: Hi Carlo, On 2016-01-04 Mon 16:36 PM |, C.L. Martinez wrote: I have configured squid in an OpenBSD host acting as a transparent proxy. Actually all works OK for all traffic except for SSL/TLS, ex: port 443. I don't use it transparently, but here are some links from those who do: http://www.benzedrine.ch/transquid.html http://www.kernel-panic.it/openbsd/proxy/ ^^ out of date http://nomoa.com/bsd/gateway/proxies/web.html ^^ doesn't really deal with "transparent" proxies other than telling you not to http://wiki.squid-cache.org/ConfigExamples/Intercept/OpenBsdPf http://wiki.squid-cache.org/KnowledgeBase/OpenBsd These should be pretty much OK, though they cover two different config cases, one of which is a bad idea and involves either running squid as root or giving it access to /dev/pf. The docs in the pkg-readme are probably a better bet for someone using the package as they only cover the method needed for the way that the squid package is built. However OP has got this side of things working already, the problem is only when using it with SSL MITM. I'd suggest double-checking the PF rules, but I need to get this working myself soon too, so I'll try and put a test setup together. Thanks Stuart. It is correct: my squid is working ok in transparent mode when services are not encrypted via TLS/SSL, ex: http, 1025><655535 ... The problem is only with SSL/TLS services
Tips & tricks about using mysql under OpenBSD
Hi all, In the following weeks, I need to install a syslog collector server using mysql as a backend to store all logs (and I would like to use OpenBSD 5.7 to accomplish that). I expect +/- 5k-6k EPS from our servers (unix, linux, windows). As a syslog process I will use syslog-ng or rsyslog. But my question is about using mysql under OpenBSD. Due to the log volume, I will need to do, probably, some type of "tuning" in mysql side. Somebody uses mysql in production environments with a respectable amount of inserts under OpenBSD? Tips & tricks about what options to use under fstab where mysql stores all data, memory limits, etc? Thanks.
Re: Tips & tricks about using mysql under OpenBSD
On 04/01/2015 12:51 PM, C.L. Martinez wrote: Hi all, In the following weeks, I need to install a syslog collector server using mysql as a backend to store all logs (and I would like to use OpenBSD 5.7 to accomplish that). I expect +/- 5k-6k EPS from our servers (unix, linux, windows). As a syslog process I will use syslog-ng or rsyslog. But my question is about using mysql under OpenBSD. Due to the log volume, I will need to do, probably, some type of "tuning" in mysql side. Somebody uses mysql in production environments with a respectable amount of inserts under OpenBSD? Tips & tricks about what options to use under fstab where mysql stores all data, memory limits, etc? Thanks. Please, any inputs?
Custom rc.d startup script for sslsplit doesn't stops the process
Hi all,
I have created a custom rc.d script to launch sslsplit at startup and
stop it at shutdown. Start option works without problems, but this
script doesn't stop process.
Here it is:
#!/bin/sh -x
#
daemon="/usr/local/bin/sslsplit"
. /etc/rc.d/rc.subr
rc_reload=NO
rc_cmd $1
Options in rc.conf.local are:
sslsplit_flags="-d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443"
When I try to stop it:
+ daemon=/usr/local/bin/sslsplit
+ . /etc/rc.d/rc.subr
+ [ -n ]
+ [ -n /usr/local/bin/sslsplit ]
+ unset _RC_DEBUG _RC_FORCE
+ getopts df c
+ shift 0
+ basename /etc/rc.d/sslsplit
+ _name=sslsplit
+ _RC_RUNDIR=/var/run/rc.d
+ _RC_RUNFILE=/var/run/rc.d/sslsplit
+ _rc_do _rc_parse_conf
+ eval _rcflags=${sslsplit_flags}
+ _rcflags=-d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
+ eval _rcuser=${sslsplit_user}
+ _rcuser=
+ eval _rctimeout=${sslsplit_timeout}
+ _rctimeout=
+ getcap -f /etc/login.conf sslsplit
+ > /dev/null
+ 2>&1
+ [ -z ]
+ daemon_class=daemon
+ [ -z ]
+ daemon_user=root
+ [ -z ]
+ daemon_timeout=30
+ [ -n ]
+ [ -n -d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443 ]
+ daemon_flags=-d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
+ [ -n ]
+ [ -n ]
+ printf %s -d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
+ daemon_flags= -d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
+ daemon_flags=-d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
+ readonly daemon_class
+ unset _rcflags _rcuser
+ pexp=/usr/local/bin/sslsplit -d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
+ rcexec=su -l -c daemon -s /bin/sh root -c
+ rc_reload=NO
+ rc_cmd stop
It doesn't works:
8916 ?? Is 0:00.01 sshd: secit [priv] (sshd)
24626 ?? S 0:01.29 sshd: secit@ttyp0 (sshd)
5118 ?? Is 0:00.01 sshd: secit [priv] (sshd)
1098 ?? I 0:00.55 sshd: secit@ttyp1 (sshd)
17658 ?? Ss 0:04.65 /usr/local/bin/sslsplit -d -Z -l
/var/log/sslsplit -S /tmp -k /root/configs/sslsplit/ca.key -p
/var/run/sslsplit.pid -c /root/configs/sslsplit/ca.crt -u proxy ssl 127
1814 p0 Is 0:00.00 -ksh (ksh)
3346 p0 S 0:00.13 -ksh (ksh)
What am I doing wrong??
Re: Custom rc.d startup script for sslsplit doesn't stops the process
On 04/20/2015 11:50 AM, Antoine Jacoutot wrote:
On Mon, Apr 20, 2015 at 11:44:59AM +, C.L. Martinez wrote:
Hi all,
I have created a custom rc.d script to launch sslsplit at startup and stop
it at shutdown. Start option works without problems, but this script doesn't
stop process.
Here it is:
#!/bin/sh -x
#
daemon="/usr/local/bin/sslsplit"
. /etc/rc.d/rc.subr
rc_reload=NO
rc_cmd $1
Options in rc.conf.local are:
sslsplit_flags="-d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443"
You need a pexp variable that patches the process table.
+ pexp=/usr/local/bin/sslsplit -d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
versus
17658 ?? Ss 0:04.65 /usr/local/bin/sslsplit -d -Z -l /var/log/sslsplit
-S /tmp -k /root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
Uhmm .. I am trying some variants, but it doesn't works:
+ daemon=/usr/local/bin/sslsplit -d -u proxy
+ daemon_flags=-Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ . /etc/rc.d/rc.subr
+ [ -n ]
+ [ -n /usr/local/bin/sslsplit -d -u proxy ]
+ unset _RC_DEBUG _RC_FORCE
+ getopts df c
+ shift 0
+ basename /etc/rc.d/sslsplit
+ _name=sslsplit
+ _RC_RUNDIR=/var/run/rc.d
+ _RC_RUNFILE=/var/run/rc.d/sslsplit
+ _rc_do _rc_parse_conf
+ eval _rcflags=${sslsplit_flags}
+ _rcflags=
+ eval _rcuser=${sslsplit_user}
+ _rcuser=
+ eval _rctimeout=${sslsplit_timeout}
+ _rctimeout=
+ getcap -f /etc/login.conf sslsplit
+ > /dev/null
+ 2>&1
+ [ -z ]
+ daemon_class=daemon
+ [ -z ]
+ daemon_user=root
+ [ -z ]
+ daemon_timeout=30
+ [ -n ]
+ [ -n ]
+ [ -n ]
+ [ -n ]
+ printf %s -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ daemon_flags= -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ daemon_flags=-Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ readonly daemon_class
+ unset _rcflags _rcuser
+ pexp=/usr/local/bin/sslsplit -d -u proxy -Z -l /var/log/sslsplit -S
/tmp -k /root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt
ssl 127.0.0.1 8443
+ rcexec=su -l -c daemon -s /bin/sh root -c
+ rc_reload=NO
+ rc_cmd stop
pexp result is correct now, but daemon is not stopped ...
Re: Custom rc.d startup script for sslsplit doesn't stops the process 8SOLVED)
On 04/20/2015 12:15 PM, C.L. Martinez wrote:
On 04/20/2015 11:50 AM, Antoine Jacoutot wrote:
On Mon, Apr 20, 2015 at 11:44:59AM +, C.L. Martinez wrote:
Hi all,
I have created a custom rc.d script to launch sslsplit at startup
and stop
it at shutdown. Start option works without problems, but this script
doesn't
stop process.
Here it is:
#!/bin/sh -x
#
daemon="/usr/local/bin/sslsplit"
. /etc/rc.d/rc.subr
rc_reload=NO
rc_cmd $1
Options in rc.conf.local are:
sslsplit_flags="-d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443"
You need a pexp variable that patches the process table.
+ pexp=/usr/local/bin/sslsplit -d -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
/root/configs/sslsplit/ca.crt -u proxy ssl 127.0.0.1 8443
versus
17658 ?? Ss 0:04.65 /usr/local/bin/sslsplit -d -Z -l
/var/log/sslsplit
-S /tmp -k /root/configs/sslsplit/ca.key -p /var/run/sslsplit.pid -c
Uhmm .. I am trying some variants, but it doesn't works:
+ daemon=/usr/local/bin/sslsplit -d -u proxy
+ daemon_flags=-Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ . /etc/rc.d/rc.subr
+ [ -n ]
+ [ -n /usr/local/bin/sslsplit -d -u proxy ]
+ unset _RC_DEBUG _RC_FORCE
+ getopts df c
+ shift 0
+ basename /etc/rc.d/sslsplit
+ _name=sslsplit
+ _RC_RUNDIR=/var/run/rc.d
+ _RC_RUNFILE=/var/run/rc.d/sslsplit
+ _rc_do _rc_parse_conf
+ eval _rcflags=${sslsplit_flags}
+ _rcflags=
+ eval _rcuser=${sslsplit_user}
+ _rcuser=
+ eval _rctimeout=${sslsplit_timeout}
+ _rctimeout=
+ getcap -f /etc/login.conf sslsplit
+ > /dev/null
+ 2>&1
+ [ -z ]
+ daemon_class=daemon
+ [ -z ]
+ daemon_user=root
+ [ -z ]
+ daemon_timeout=30
+ [ -n ]
+ [ -n ]
+ [ -n ]
+ [ -n ]
+ printf %s -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ daemon_flags= -Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ daemon_flags=-Z -l /var/log/sslsplit -S /tmp -k
/root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt ssl
127.0.0.1 8443
+ readonly daemon_class
+ unset _rcflags _rcuser
+ pexp=/usr/local/bin/sslsplit -d -u proxy -Z -l /var/log/sslsplit -S
/tmp -k /root/configs/sslsplit/ca.key -c /root/configs/sslsplit/ca.crt
ssl 127.0.0.1 8443
+ rcexec=su -l -c daemon -s /bin/sh root -c
+ rc_reload=NO
+ rc_cmd stop
pexp result is correct now, but daemon is not stopped ...
Ok, now it works... I have removed /var/run/rc.d/sslplit file and now it
is working ...
sslsplit needs to be restarted every 30 min.
Hi all, I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: May 6 09:50:14 obsd57 monit[23714]: Monit start delay set -- pause for 120s May 6 09:52:14 obsd57 monit[16338]: 'localhost' Monit started May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' process is not running May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 09:53:44 obsd57 monit[16338]: 'sslsplit' process is running with pid 22344 May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' process is not running May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 10:27:46 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 10:28:16 obsd57 monit[16338]: 'sslsplit' process is running with pid 5788 May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' process is not running May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 11:00:49 obsd57 monit[16338]: 'sslsplit' process is running with pid 1295 Is this a normal behavior?? Or maybe exists some problem in this OpenBSD host? From the other side, all other services running in this box, works without problems: dnscrypt_proxy, pf, opensmtpd, etc ... Thanks.
Re: sslsplit needs to be restarted every 30 min.
On 05/06/2015 11:15 AM, C.L. Martinez wrote: Hi all, I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: May 6 09:50:14 obsd57 monit[23714]: Monit start delay set -- pause for 120s May 6 09:52:14 obsd57 monit[16338]: 'localhost' Monit started May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' process is not running May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 09:53:44 obsd57 monit[16338]: 'sslsplit' process is running with pid 22344 May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' process is not running May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 10:27:46 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 10:28:16 obsd57 monit[16338]: 'sslsplit' process is running with pid 5788 May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' process is not running May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 11:00:49 obsd57 monit[16338]: 'sslsplit' process is running with pid 1295 Is this a normal behavior?? Or maybe exists some problem in this OpenBSD host? From the other side, all other services running in this box, works without problems: dnscrypt_proxy, pf, opensmtpd, etc ... Thanks. Hi all, I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Please, any advice, help or tip??
Re: sslsplit needs to be restarted every 30 min.
On 05/11/2015 09:00 AM, Philip Guenther wrote: On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther Here is her answer: Hi C.L., This is very likely not a bug in sslsplit itself. I cannot support the OpenBSD packages or OpenBSD monit functionality. You will have to use whatever mechanism OpenBSD provides to support their system and packages. I am not familiar with what or how that would be. Daniel Ok, I will try these recommendations Phillip. Many thanks.
Re: sslsplit needs to be restarted every 30 min.
On 05/11/2015 10:59 AM, Stuart Henderson wrote: On 2015-05-11, C.L. Martinez wrote: On 05/11/2015 09:00 AM, Philip Guenther wrote: On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther Here is her answer: Hi C.L., This is very likely not a bug in sslsplit itself. I cannot support the OpenBSD packages or OpenBSD monit functionality. You will have to use whatever mechanism OpenBSD provides to support their system and packages. I am not familiar with what or how that would be. Daniel Ok, I will try these recommendations Phillip. Many thanks. Additionally to Philip's advice, the package does not include an rc.d script so you have written your own. Please also include a copy of this script and the command line flags you're using. Can you replicate the problem if you run sslsplit in the foreground or better still in debug mode (-D)? (Did the upstream developer ask you to do this? If not, I am *very* surprised). Ideally run it from gdb in debug mode (obviously replace the "set args" line with whatever you normally use, plus -D): # gdb `which sslsplit` set args -c /path/to/cert.pem -D https 127.0.0.1 8585 ipfw run If/when it crashes, "backtrace full" and "thread apply all backtrace", along with the recent debug output might be useful. Many thanks Stuart. I will try it as soon as possible.
Re: sslsplit needs to be restarted every 30 min.
On 05/11/2015 10:59 AM, Stuart Henderson wrote: On 2015-05-11, C.L. Martinez wrote: On 05/11/2015 09:00 AM, Philip Guenther wrote: On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther Here is her answer: Hi C.L., This is very likely not a bug in sslsplit itself. I cannot support the OpenBSD packages or OpenBSD monit functionality. You will have to use whatever mechanism OpenBSD provides to support their system and packages. I am not familiar with what or how that would be. Daniel Ok, I will try these recommendations Phillip. Many thanks. Additionally to Philip's advice, the package does not include an rc.d script so you have written your own. Please also include a copy of this script and the command line flags you're using. Can you replicate the problem if you run sslsplit in the foreground or better still in debug mode (-D)? (Did the upstream developer ask you to do this? If not, I am *very* surprised). Ideally run it from gdb in debug mode (obviously replace the "set args" line with whatever you normally use, plus -D): # gdb `which sslsplit` set args -c /path/to/cert.pem -D https 127.0.0.1 8585 ipfw run If/when it crashes, "backtrace full" and "thread apply all backtrace", along with the recent debug output might be useful. Yep, it seems the problem is "Too many open files" message: leapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 ssl [172.22.55.1]:41558 [74.125.226.170]:443 sni:ci6.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:50639 [74.125.226.171]:443 sni:ci4.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Failed to open '/tmp/20150511T113718Z-[172.22.55.1]:50639-[74.125.226.171]:443.log': Too many open files (24) Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:59905 [74.125.226.160]:443 sni:plus.google.com names:*.google.com/*.google.com/*.android.com/*.appengine.google.com/*.cloud.google.com/*.google-analytics.com/*.google.ca/*.google.cl/*.google.co.in/*.google.co.jp/*.google.co.uk/*.google.com.ar/*.google.com.au/*.google.com.br/*.google.com.co/*.google.com.mx/*.google.com.tr/*.googl
Re: sslsplit needs to be restarted every 30 min.
On 05/13/2015 06:57 AM, Stuart Henderson wrote:
On 2015-05-13, Stuart Henderson wrote:
On 2015-05-11, C.L. Martinez wrote:
Yep, it seems the problem is "Too many open files" message:
leapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA
dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
ssl [172.22.55.1]:41558 [74.125.226.170]:443
sni:ci6.googleusercontent.com
names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com
sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
Warning: Failed to write to content log: Bad file descriptor
Warning: Failed to write to content log: Bad file descriptor
ssl [172.22.55.1]:50639 [74.125.226.171]:443
sni:ci4.googleusercontent.com
names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com
sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
Warning: Failed to write to content log: Bad file descriptor
Failed to open
'/tmp/20150511T113718Z-[172.22.55.1]:50639-[74.125.226.171]:443.log':
Too many open files (24)
Warning: Failed to write to content log: Bad file descriptor
ssl [172.22.55.1]:59905 [74.125.226.160]:443 sni:plus.google.com
names:*.google.com/*.google.com/*.android.com/*.appengine.google.com/*.cloud.google.com/*.google-analytics.com/*.google.ca/*.google.cl/*.google.co.in/*.google.co.jp/*.google.co.uk/*.google.com.ar/*.google.com.au/*.google.com.br/*.google.com.co/*.google.com.mx/*.google.com.tr/*.google.com.vn/*.google.de/*.google.es/*.google.fr/*.google.hu/*.google.it/*.google.nl/*.google.pl/*.google.pt/*.googleadapis.com/*.googleapis.cn/*.googlecommerce.com/*.googlevideo.com/*.gstatic.cn/*.gstatic.com/*.gvt1.com/*.gvt2.com/*.metric.gstatic.com/*.urchin.com/*.url.google.com/*.youtube-nocookie.com/*.youtube.com/*.youtubeeducation.com/*.ytimg.com/android.com/g.co/goo.gl/google-analytics.com/google.com/googlecommerce.com/urchin.com/youtu.be/youtube.com/youtubeeducation.com
sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
Error 24 on listener: Too many open files
Program exited normally.
(gdb) backtrace full
No stack.
(gdb) thread apply all backtrace
(gdb)
Aha. Unless it's very busy I wouldn't expect sslsplit to use a huge
number of openfiles simultaneously, so I wonder if it is failing
to close something.
Please try "fstat | grep sslsplit" soon after startup (allow a couple
of requests to go through first), then again after it has handled
a larger number of connections (maybe 5 minutes or so?) - let's see
if something is building up.
No need to run it in gdb for this now, it is exiting normally (i.e.
following normal error handling and reaching the end of the program)
so you could just use your normal startup script.
Also, as mentioned before, please show the command line you're using,
I've just done some small tests with divert-to ("ipfw" nat engine),
rdr-to ("pf" nat engine) and static destination and haven't noticed
an FD leak in the normal case.
Of course if it is just very busy, you may need to raise an openfiles
limit (ulimit -n if starting manually, or via the relevant class in
login.conf if using an rc.d script, which would be 'daemon' unless
you've added a separate class for it).
Uhmmm ... I think you are right Stu, my pf rules needs to be wrong:
pass in quick inet proto tcp from $laptop to { !
! } port $sslsplit_ssl_ports rdr-to 127.0.0.1
port 8443 tag intlans-to-inet
As you can see, I redirect directly to sslsplit's listening port, but
according to sslsplit's man page, that is wrong... And it seems, this is
the explination about the error of "Too many open files" ...
Am I right??
OT: Exists some problem with dnscrypt-proxy package?
Hi all, I have installed an openbsd 5.7 VM today to do some tests with pf rules. One of the components to I need to enable in this gateway is unbound+dnscrypt-proxy. I have configured forwarding in unbound.conf: forward-zone: name: "." forward-addr: 127.0.0.1@4553 And I have started dnscypt-proxy with the following arguments: -d --user=_dnscrypt-proxy -a 127.0.0.1:4553 -R dnscrypt.eu-nl -p /var/run/dnscrypt-proxy.pid Output: 32032 ?? Is 0:00.00 /usr/sbin/ftp-proxy -m 25 32411 ?? Is 0:00.00 /usr/local/sbin/dnscrypt-proxy -d --user=_dnscrypt-proxy -a 127.0.0.1:4553 -R dnscrypt.eu-nl -p /var/run/dnscrypt-proxy.pid 5667 ?? I 0:00.03 /usr/local/sbin/dnscrypt-proxy -d --user=_dnscrypt-proxy -a 127.0.0.1:4553 -R dnscrypt.eu-nl -p /var/run/dnscrypt-proxy.pid 1256 ?? Is 0:00.00 /usr/sbin/cron 17818 ?? Ss 0:00.12 sshd: root@ttyp0 (sshd) 527 ?? Is 0:00.05 unbound -c /var/unbound/etc/unbound.conf 30164 p0 Ss 0:00.02 -ksh (ksh) 7382 p0 R+ 0:00.00 ps -xa 16881 C0 Is+ 0:00.00 /usr/libexec/getty std.9600 ttyC0 3047 C1 Is+ 0:00.00 /usr/libexec/getty std.9600 ttyC1 And it doesn't works. But if I change unbound's forward section to: forward-zone: name: "." #forward-addr: 127.0.0.1@4553 forward-addr: 8.8.8.8 Works ok. Removing all forward seciton, unbound works ok also. Then, I am doing something wrong but I don't know which. Any idea?? Thanks.
