Re: HSTS configuration in httpd.conf
Em 01-10-2015 12:58, Carlin Bingham escreveu: > That redirect will only be used the first time a browser (that supports HSTS) > accesses the domain. Once they've been redirected to your https host the HSTS > flag will be set in their browser and from then on the browser will > immediately use https for your domain without going through the redirect. The redirect is still necessary, given the fact that STS headers have a expiration time. So, configure and forget the redirect and always maintain your TLS setup working, and you should be fine. Cheers, Giancarlo Razzolini
Re: Web Filtering with the Blowfish
Em 02-10-2015 16:45, Predrag Punosevac escreveu: > 1. strip as much as possible unwanted ads, banners, pop-ups, and > similar junk There are tons of info regarding this. You're on the right direction thinking of Squid, Dansguardian, etc. There is one recent addon from EFF called Privacy Badger that deserve some mentioning. Instead of using lists, it inspects the tracker behaviuor and blocks them if they are bad. So, an addon has it's uses. > > 2. Scan http and possibly https for viruses (thereby protecting kids > devices as much as I can). You can possibly use realayd as a MITM intercepting proxy for TLS. See: http://www.reykfloeter.com/post/41814177050/relayd-ssl-interception http://www.openbsd.org/papers/relayd-asiabsdcon2013.pdf I think there was something in squid also, in that regard. But, keep in mind that you'll need to install and maintain your CA certs on all your devices(with varied degrees of success making all of them work), and you'll probably need to prevent any other new device from using the same network as yours. Also, I don't think that the sites using pinned certs will work. I know chrome does allow usage of custom CA's, and firefox has an option also. But that is not true for every browser (or lib that some app might be using). To complicate things further, there is HPKP. You can also use pflow(4) with nfsen for detecting odd behaviour in your network, and try to catch anything that might have passed. Cheers, Giancarlo Razzolini
Re: vpn from subnet to subnet through a 3rd enpoint?
Em 06-10-2015 10:35, Markus Rosjat escreveu: > as the subject states is it possible to do that ? Yes, it is. > My tunnels working from the 3rd subnet in each of the other 2 subnets > and back from then. I really want to connect from subnet 1 to subnet 2 > over the enpoint in the 3rd subnet. Are you setting up the routes correctly? > > subnet 1 <---> subnet 3 ; works fine > subnet 2 <> subnet 3; works fine > subnet 1 <---| subnet 3 |> subnet 2; isn't working You should send/setup in the subnet 1 a route to subnet 2 using the subnet 3 router as gateway. The same for subnet 2, otherwise the packets won't get back. > > all 3 endpoints running openBSD and ipsec, some advice would be cool I don't know about doing this using ipsec, as I already mentioned, you need configure the routes. There are also PF rules needed, and, if any of the subnets aren't using the OpenBSD as their gateway, you might need some nat. It's worth mentioning that OpenVPN has this functionality with their client-to-client directive. Even them some routing/firewalling is required. Just keep in mind that if these subnets are connected through the internet, making all of them pass through the subnet 2, will slow things down. Cheers, Giancarlo Razzolini
Re: match rules and priorities
Em 08-10-2015 05:36, Christer Solskogen escreveu:
> I'm having a bit trouble understanding match rules and priorities. I
> have a lot of traffic on other ports than http and https, but I want
> to have top priority on them instead of the others.
>
> So I have these rules:
> match proto tcp to port { ftp, http, https, 3129 } set prio 7
> match proto tcp from port { ftp, http, https, 3129 } set prio 7
>
> Do I need them both? And where in pf.conf should they be? I've tried
> having them on top, and on bottom, but still I get very low speeds for
> downloads on http.
You are mixing things. First of all, ftp goes through OpenBSD's
ftp-proxy. So you should prioritize packets leaving it, not coming from
the machines. Fortunately, ftp-proxy can apply a tag to its packets, so
it should be easy to set a priority on them. Port 3129 is some proxy,
I'm betting on squid, right? Same issue as the ftp-proxy, you should
prioritize the packets leaving it. Perhaps by using the user directive
of pf?
As for direct http and https connections, you can prioritize them,
but keep in mind that you can only queue on the outgoing. Also, you can
set the priority passing two of them, so packets with lowdelay TOS and
empty acks can go to a higher priority, hence improving your interactive
browsing and your downloads.
Cheers,
Giancarlo Razzolini
Re: Your opinion about using rdomain or mpath
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?
> 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? 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
}
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.
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, or your OpenBSD firewall is also running a proxy or dns server.
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.
Cheers,
Giancarlo Razzolini
Re: Your opinion about using rdomain or mpath
Em 14-10-2015 10:31, C.L. Martinez escreveu: > Nop. It is a CentOS 7.x I don't remember if the default dhclient from CentOS works with classless static routes (code 121), but you can install dhcpcd and use it, it certainly works with it. > 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. > 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. > 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. > 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). If you have, lets say, two tunnels that give you access to the same network, you could use mpath and add two routes to it, using different gateways. If they have the same routing priority, OpenBSD would round-robin between them. This is where ifstated can be used, to detect failures and add/remove the routes as needed. Cheers, Giancarlo Razzolini
Re: PF Queuing
Em 14-10-2015 11:15, lists escreveu: > Hi Everyone, > > Under systat q, I see packets that are being dropped / trimmed by PF in > my prioritized ack queue exceed my default queue. If I'm logged in and > catch this happening I can usually identify the traffic which I don't > want using that queue and add a match rule to pf.conf to push it into my > bulk queue. > > But I am wondering if there is a way to log what traffic is using a > queue or which packets are being dropped. > > Thanks, > jh > match log man pflow(4) pkg_add nfsen Happy! Cheers, Giancarlo Razzolini
Re: Your opinion about using rdomain or mpath
Em 14-10-2015 11:33, C.L. Martinez escreveu: > ALL traffic is routed over tun0 interface. Some of our customers use > the same type of configuration. This is my actual problem: > discriminate when I do requests to my customers and when I do requests > to our internal lans. I need my default gw untouched in this OpenBSD fw. So, now that I believe I understood your problem, it's easier to point you in the right direction. I'm presuming that your vio(4) interfaces are the ones with your customers networks, right? And you don't want your OpenBSD default gw to change, but still want to route traffic through your VPN. In this case, you don't need neither rdomain nor mpath. Properly crafted route-to rules in your pf.conf should do the trick. You can even use anchors and up/down scripts (OpenVPN), to change the rules in response to connections/disconnections. You can also do this the other way around: make the route-to rules for your customers and let your OpenBSD use whatever default gateway you want. If your networks are static, you can hard code them in your pf rules. Cheers, Giancarlo Razzolini
Re: Diffie-Helman issue?
Em 20-10-2015 10:25, Kimmo Paasiala escreveu: > Someone correct me if I'm wrong but as far as I know the prime numbers > used in DH group exchange are not secret but must be known by everyone > (and couple other parameters are also public) for the key exchange to > be possible in the first place. How is that different from pre-shared keys then? You can generate your own primes. If you don't the defaults get used. And it are these defaults that can be precomputed, because almost everyone do not generate their own dh parameters. > What NSA can do is to perform a > "pre-calculation" over the possible key exchange results and the > danger is in that too small DH group can be covered sufficiently by > them to be able to crack DH exchange on the fly. > > Hence the recommendation to increase the size of the group size used. The OpenSSH project regenerates the moduli file every release, AFAIK. And the DH parameters for IPSec on OpenBSD just got bumped to 3072 if I'm not mistaken. Bottom line, generate your own (big) parameters and keep them as safe as possible. The dh parameters are even more important than your private key. Specially if you do not change it after a key replacement. Cheers, Giancarlo Razzolini
Re: passive mode ftp pf.conf OpenBSD 5.6 i386
Em 22-10-2015 19:49, Motty escreveu: > I am trying to configure pf.conf (OpenBSD 5.6) I know it is a beaten and old argument, but please upgrade your OpenBSD. 5.6 isn't supported anymore. That being said, I don't think your problem has anything to do with your OpenBSD version. > when I use pasive command FTP server does not > respond. I enabled ftp-proxy (please see relevant information below) You need to configure your ftp-proxy server as a reverse proxy. I believe you attached the information, but this list uses demime, so you'll need to paste the information as text here. Without it, it's difficult to help you. Cheers, Giancarlo Razzolini
Re: correct way to clear sensitive data from env?
Em 23-10-2015 12:14, Tamas TEVESZ escreveu: > case in point: openvpn passing username/password in the environment to > openvpn_bsdauth. > > so there's actually a bit of a sensitive data in env that current > wisdom rightly tends to want to junk as soon as possible. I wrote many years ago an openvpn plugin that would use getpwnam instead of that PAM crap. I believe it's still around on sourceforge. openvpn-auth-passwd if I recall correctly. I developed it specifically because it would work on OpenBSD and also on any platform that works with getpwnam. I can look it up if you want, but I don't even know if it compiles with recent OpenVPN code. Cheers, Giancarlo Razzolini
Re: passive mode ftp pf.conf OpenBSD 5.6 i386
Em 23-10-2015 12:58, Motty escreveu: > ### RULES FOR FTP > anchor "ftp-proxy/*" > pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021 > pass in quick on $ext proto tcp from any to 10.1.10.8 port ftp rdr-to > $web_server port ftp I believe you need a nat instead of rdr. From ftp-proxy(8) man page: In case of passive mode (PASV or EPSV): pass in from $client to $orig_server port $proxy_port \ rdr-to $server port $port pass out from $client to $server port $port nat-to $proxy p.s.: Please let FTP run its course and die! I beg you. Every time an admin starts a ftp server, a puppy dies. Consider using SSH. Or, if you must, DAV. Cheers, Giancarlo Razzolini
Re: correct way to clear sensitive data from env?
Em 24-10-2015 09:07, Stuart Henderson escreveu: > I don't understand why openvpn doesn't just allow passing the > username/password on a file descriptor to the authentication command. > That would avoid the permission problems with via-file and the unsafe > nature of via-env. I don't understand it either. From my point of view, the OpenVPN project has slowed down a lot on the past few years. Coincidentally, it's commercial solution, didn't. > so did Tamas, it's in ports. Good to know. I don't think my code still compiles against newer OpenVPN versions. Cheers, Giancarlo Razzolini
Re: Making IPv6 NAT prefer privacy address
Em 25-10-2015 01:37, Fernando Gont escreveu: > ... as long as IPv6 addresses are not embedded in the app protocol. > > FWIW, I wouldn't go this way. ULAs (fd00::/8) erver a different purpose: > e.g., still be able to communicate within your network if global > connectivity/addressing fails. The fact every edge gets it's own IP address (and generates it the way it wants, at least with SLAAC), always scared me. With IoT getting more and more traction, it's only a matter of time until we see the kind of attacks and probing you suggested on your RFC's. If they aren't already happening. And, given the fact most CPE's being deployed are happily routing traffic into our networks with no firewalling whatsoever, scares me even more. Most do not even begin to follow RFC 7084. I found out that OpenBSD 5.8 indeed will prefer privacy address for EVERY outgoing connection, unless told otherwise. But I had to write a very broad pf ruleset for not needing to write a script to detect every time my privacy address changes and doing the appropriate rule reloading, among other things. I found that that, at least on 5.8-stable, enclosing the interface name with () won't work with IPv6, and the rules don't get reloaded when the addresses change. I will (unfortunately) still use IPv4 based internal LAN's, as long as these IPv6 woes don't get sorted out. I think things will get much worse, before they get better. Cheers, Giancarlo Razzolini
Re: NAT replies not triggering pf rule
Em 25-10-2015 15:31, Michael S. Keller escreveu: > I want to set queues to limit bandwidth for the streaming media > devices on my home network. Unfortunately, the "pass out" rules on my > internal network (external is PPPoE) don't ever trip for replies > received from the world. Are you aware that you'll need to have a queue on the internal interface and another on the egress one right? Queuing incoming packets is very tricky and not always have the desired effect. I suggest you start with prio and see where it leads you: http://quigon.bsws.de/papers/2012/eurobsdcon/mgp00010.html > What am I missing? > > OpenBSD version is 5.8 macppc. > > block drop in log on egress all > block return in on ! lo0 proto tcp from any to any port 6000:6010 > match on egress all scrub (no-df random-id reassemble tcp max-mss 1440) > pass out on egress from (self) to any flags S/SA nat-to (egress:0) > round-robin > pass out on egress inet from 192.168.1.0/24 to any received-on gem0 > flags S/SA nat-to (egress:0) round-robin > block drop in quick on ! lo inet6 from ::1 to any > block drop in quick on ! lo inet from 127.0.0.0/8 to any > block drop in quick inet from 127.0.0.1 to any > block drop in quick on ! gem0 inet from 192.168.1.0/24 to any > block drop in quick inet from 192.168.1.1 to any > block drop in quick on lo0 inet6 from fe80::1 to any > block drop in quick inet6 from ::1 to any > pass in on egress inet proto icmp from ! (egress) to (egress) > icmp-type echoreq code 0 > pass in on egress inet proto icmp from ! (egress) to (egress) > icmp-type unreach code needfrag > pass in log on egress inet proto tcp from ! (egress) to (egress) port > = 8022 flags S/SA modulate state rdr-to 127.0.0.1 port 8022 > pass in on egress inet proto udp from ! (egress) to (egress) port = > 1194 rdr-to 127.0.0.1 > pass in on gem0 all flags S/SA > pass in on gem0 inet proto tcp from 192.168.1.0/24 to 192.168.1.1 port > = 22 flags S/SA modulate state rdr-to 127.0.0.1 port 8022 > block drop out on gem0 all > match on gem0 inet from any to 192.168.1.64 # THESE THREE > match on gem0 inet from any to 192.168.1.57 # DO NOT > match on gem0 inet from any to 192.168.1.62 # TRIGGER > match on gem0 inet from 192.168.1.64 to any # these > match on gem0 inet from 192.168.1.57 to any # three > match on gem0 inet from 192.168.1.62 to any # trigger > pass out on gem0 inet from any to 192.168.1.0/24 flags S/SA I suggest you move your match rules to the beginning of the ruleset and use log on them. So you can watch your pflog interface and see the packets being triggered. Also, you can (should) always use tags. Not only they make your ruleset "debugable", but any stray packet should hit a block rule (possibly logging it). I suspect your first three rules aren't matching because you're using the external interface. Try using the internal on them. Cheers, Giancarlo Razzolini
Re: NAT replies not triggering pf rule
Em 27-10-2015 09:37, Michael S. Keller escreveu: > These are the rules that appear potentially to affect outgoing packets > on the internal interface: > > match inet from any to 192.168.1.62 > block drop out on gem0 all > pass out on gem0 inet from any to 192.168.1.0/24 flags S/SA > > Only traffic that initiates directly from the OpenBSD firewall > triggers these rules. Neither web page loads (which traverse the NAT) > nor SSH session replies increase the trigger counts on any of these > three rules. Since you seem to be unwilling to use tags, lets try to debug this another way. Install and configure nfsen, create a pflow(4) interface and set the default for every state to use pflow: option state-defaults pflow You will see every flow passing, incoming and leaving your firewall. Since you mentioned that you're seeing the traffic on tcpdump, this can make it easier to visualize where you're packets are going. Cheers, Giancarlo Razzolini
Re: passive mode ftp pf.conf OpenBSD 5.6 i386
Em 28-10-2015 08:08, Marcus MERIGHI escreveu: > Giancarlo, do you know of any software that does DAV the way ftpds do > FTP? No, I don't. I mentioned DAV for the simpler setups. > I've been looking for options recently and was baffled about the lack > thereof. Nginx has a simple module, apache has a full solution, don't know about lighthttpd. > > DAV service is usually built into a HTTPd (apache2, nginx, lighttpd) > as a module. The server runs as non-root user (fortunately). > No way to setuid to the user that just entered username/password. Do you really need to setuid things to the user? > > Additionally, HTTPds hopefully run chrooted. Not much room for separate > user spaces. > > I'm afraid there is no real (Web)DAVd. > (Apart from davenport, which is tomcat+davenport+samba. wow.) > > Bye (and thanks in advance), Marcus Don't try to implement the same thing ftp does on top of other protocols. That being said, using OpenSSH you can have everything ftp has even better. You can even chroot every user to his/her home. With the benefit of, you know, talking ssh protocol, instead of ftp. Cheers, Giancarlo Razzolini
Re: OpenBSD 5.8 and IPv6 forwarding doesn't seem to be working
Em 28-10-2015 02:29, Daniel Corbe escreveu: > But I can't ping out or do anything on the client: > > C:\Users\dcorbe>ping ipv6.cybernode.com > > Pinging ipv6.cybernode.com [2001:470:1:1b9::31] with 32 bytes of data: > Control-C > ^C > C:\Users\dcorbe>tracert 2601:5ce:101:5350:21e:37ff:fed6:ad > > Tracing route to 2601:5ce:101:5350:21e:37ff:fed6:ad over a maximum of 30 > hops > > 1 Destination host unreachable. > > Trace complete. You probably have the same issue I ran into. Please run tcpdump on your external if. You will see the packets leaving your internal net. And, if you have control over the remote host being pinged, you can even see the packets getting there. But, no replies ever get back. Your CPE do not know about you delegating the prefix to your internal machines. So, you should be seeing ndp neighbour discovery messages in your external interface. Since OpenBSD do not proxy the ndp messages to your internal lan, the packets get dropped by the CPE. At first, I used a bridge to solve this. But filtering on them is a nightmare. So, know I'm using a ULA prefix on my internal network and natting (I know) ipv6 packets to my external lan address. I will try to port some of the ndp proxy solutions available to OpenBSD. Everyone I found are linux centric. OpenBSD ndp(8) has proxy functionality. I couldn't make it work, and you also need to add entries host by host to it. Cheers, Giancarlo Razzolini
Re: OpenBSD 5.8 and IPv6 forwarding doesn't seem to be working
Em 28-10-2015 11:55, lists escreveu: > I dont think rtadvd is running and allowing his devices to use SLAAC. It is. At least from the information he provided. > > I would check to make sure your device are generating an IPv6 address in > the correct prefix. The prefix is different from the one in its external interface, but that doesn't mean that he isn't getting a valid prefix through PD. He might have configured its dhcpv6 client to assign a IA_NA to its external if, and the CPE got him one from a different prefix. But it sure need to be checked. OP, please take a look into that. If your CPE doesn't have the internal lan prefix, you can't expect it to work. Cheers, Giancarlo Razzolini
Re: OpenVPN, tap interface and bridge
Em 02-11-2015 17:10, Adam Wysocki escreveu: > OpenVPN is running and ifconfig looks like that: > > tun1: flags=8051 mtu 1500 > priority: 0 > groups: tun > status: active >From tun(4) man page: Both layer 3 and layer 2 tunneling is supported; layer 3 tunneling is the default mode. To enable layer 2 tunneling mode, where the tun interface simulates an Ethernet network interface, the link0 flag needs to be set with ifconfig(8) or by setting up a hostname.if(5) configuration file for netstart(8). Note that setting or unsetting the link0 flag causes tun to lose any configuration settings, and that it is not advisable to use the flag with any other parameters. I don't see link0 being set on your interface, at least on your ifconfig output. It won't work in tap mode without it. As for assigning the ip address, you can't assign one directly to a bridge interface. You need a vether(4) one for that. But, if what you want is to bridge an internal lan with an OpenVPN interface, for making any client being able to operate on your LAN as if they were physically present, you don't need an ip address on the bridge, only on the internal LAN interface. Cheers, Giancarlo Razzolini
Re: Iked, ca_getreq: no valid local certificate found
Em 05-11-2015 05:28, Toyam Cox escreveu: > Unfortunately, editing /etc/ssl/x509v3.cnf didn't work for me. > Variable lookup still failed. You need to recreate the certs. Each time you create one, you'll need to edit x509v3 to match the cert being created. At least this did the trick for me. Cheers, Giancarlo Razzolini
Re: dhcpd exiting with strange error message.
Em 05-11-2015 23:07, Jeremy escreveu: > Nov 6 08:25:34 janus dhcpd[11758]: DHCPREQUEST for 192.168.7.36 from > b4:ae:2b:2f:b6:bf via em0 > Nov 6 08:25:34 janus dhcpd[11758]: DHCPACK on 192.168.7.36 to > b4:ae:2b:2f:b6:bf via em0 > Nov 6 08:25:46 janus dhcpd[24427]: Can't open f: No such file or directory > Nov 6 08:25:46 janus dhcpd[24427]: exiting. It seems you have two instances of dhcpd running. It might explain your problem. Cheers, Giancarlo Razzolini
Re: dhcpd exiting with strange error message.
Em 08-11-2015 20:14, Jeremy escreveu: > I suspect the change in PID is as a result of the previous instance > having been killed and the error message coming from the new instance > being (re)started with an invalid argument. > > > Looks like the problem is with Webmin. I've updated its config to > use /etc/rc.d/dhcpd start/stop/restart instead of the defaults, and the > problem has gone away. > > > Mea culpa. I've been away from OpenBSD for about 5 years and was using > Webmin to ease the transition back into things. I'll log this with Webmin. > Apologies for the noise. 5 years away is indeed a very long time. Many things changed in this period. For instance, nginx got into and out of base in this period. I strongly suggest you take a look at, in this order: 1) man pages. In the time you went away the awesome OpenBSD documentation got even better with the advent of mandoc. 2) OpenBSD papers: http://www.openbsd.org/papers/. They are a great way to know about changes and learn in a concise and less dense format. 3) OpenBSD FAQ: http://www.openbsd.org/faq/index.html There is no other way of easing the transition other than that. Webmin is a very intrusive piece of software. Unless you understand everything it is doing in the background, you'll always face up problems for which you won't know the answer, at least, not easily. Cheers, Giancarlo Razzolini
Re: rtadvd not picking up dynamic ranges automatically anymore
Em 09-11-2015 12:45, Sly Midnight escreveu: > I am writing the misc@openbsd.org thread to see if anyone else with IPv6 > experience on OpenBSD has noticed this behavior with the rtadvd daemon. I did. > > I have been using OpenBSD as my firewall now for just under 4 years > (prior to that I used FreeBSD). When I first started using it I used > HE.net's tunnelbroker service to provision my internal network with an > IPv6 subnet with my firewall being the routing endpoint. I've used sixxs. > > This worked well with the rtadvd daemon even without a config, because > it was a static tunnel where the prefix of the subnet was always the > same (unless I manually did something to change it myself). The prefix sixxs give you is also static, so, rtadvd can be run without a config and everything just works. > > However sometime in late 2012 I was able to start taking advantage of > the native IPv6 of my ISP (Comcast), when I was troubleshooting some > other setup a tcpdump showed IPv6 was finally live in my area. After > going through the trouble of finding a way to make it work with a > combination of RA's (Router Advertisements) and DHCPv6, I was able to > get myself directly on my ISP's IPv6 connection. I still employed > rtadvd for provisioning IPv6 internally on my internal subnet. > > The only thing I noticed was that unlike my static IPv6 tunnel, the IPv6 > service from my ISP would change the subnet prefix almost any time the > DHCPv6 client was restarted or at a minimum the firewall was rebooted > (like when a new version of OpenBSD was released and I upgraded in place). Same here. My prefix changes every time my CPE is restarted, or the connection is lost. It stays stable across my OpenBSD firewall reboots though, since my CPE is a router and I'm not using pppoe. > > This was not a big deal as rtadvd would simply see the new prefix on my > internal interface and start sending out RA's with that prefix. And > naturally my internal clients would automatically reconfigure themselves. > > Now I've noticed for a couple releases or more rtadvd does not notice a > change of the available prefixes assigned to the interface it both > monitors and advertises on. I have not changed my config for it, as I > just run it without a configuration file invoking it's default behavior > (since I cannot know what my IPv6 prefix will be ahead of time). I noticed this same behaviour. I devised two solutions, one is to use ifstated to monitor link changes and restart rtadvd accordingly and the other is to use ULA on the internal network. > > Any idea if this was an intentional change to rtadvd or is this a bug > I've run into? I know it used to work that way. I don't know, but things have been changing fast on the IPv6 OpenBSD world. There are some things which didn't made in time for 5.8 that might help you, if you're willing to run -current. These days I prefer using ULA and making nat, so I can assure my internal address space will never change. Cheers, Giancarlo Razzolini
Re: rtadvd not picking up dynamic ranges automatically anymore
Em 09-11-2015 13:52, Martin Pieuchot escreveu: > As soon as you notice a regression please try to notify us. I'm sorry > to say so, but we don't have the manpower to dig for a regression that > might have happen since "a couple of releases". I know Martin. For me it is not a regression, because I only recently, ie, OpenBSD 5.8, started using it with IPv6 enabled CPE's. I'm working on a very detailed bug report, I think I found a routing bug regarding IPv6, I'll test on -current later this week. As soon as I have all the info, I'll post to tech@. What I can talk right now is that, on OpenBSD 5.8-stable, if you have a interface with inet6 autoconf enabled, you aren't able to use manual configuration on any other interface (ULA addressing). The routes simply vanish right after they are added. I confirmed this behaviour with route monitor. > > One of the reason we ask for a dmesg is that we can easily identify when > things broke. We try the best we can not to break things, but sometimes > it is hard. Sorry for that. I was just confirming to the OP that I too had seen this behaviour. Every time I've stumbled upon what I suspect might be a regression or a bug I try to make sure before I report, but I always report them. So far this happened only once on OpenBSD. > > Now if you prefer to cook your own workaround, that's up to you I don't like to cook workarounds, but sometimes they are necessary. In my case I need to monitor changes so I can update DNS records, I was just extending that so the OP could do another thing (restart rtadvd). I don't know anything that could be done in my case, since my ISP and CPE will change the prefix anytime the CPE restarts or the CPE connection to the ISP is lost. Cheers, Giancarlo Razzolini
Re: Making IPv6 NAT prefer privacy address
Em 22-09-2015 15:06, Daniel Gillen escreveu: > Hi > > I currently have the following rule to nat traffic out to the internet: > > match out on $if_ext inet6 from $if_int:network to any nat-to ($if_ext) > > But this chooses from one of the configures addresses (using round-robin). > > Is there a way I can configure pf to prefer the privacy address (the one > without my MAC in it)? > > Thx in advance > > Daniel > Daniel, I've managed to accomplish this by using dhcpcd with the slaac private option. You need first to activate the interface with the inet6 -autoconf option, so you'll get only the link-local address. When you run dhcpcd it will configure only a private address on the interface thus solving your issue. You don't need to make pf prefer the privacy address, because there will only be one address on the interface. Cheers, Giancarlo Razzolini
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Em 10-11-2015 13:58, Kent Watsen escreveu: > Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs > > On boot, the consoles shows error about not being able to load pf.conf > because it can't resolve the symbolic names. If your resolver can't be accessed, this will happen. > > http://www.openbsd.org/faq/faq6.html#Setup.activate says: > >    "... if you had specified a DNS-resolved symbolic name in any of >    the files, you would probably find it worked as expected after >    reconfigure, but on initial boot, your external resolver may >    not be available, so the configuration will fail." > > but I thought that the statement might be limited to `netstat`, and > /etc/rc runs `netstat` before loading the firewall rules. So I'm not > sure why it's not working... As a general rule you should avoid using dns names on anything that might cause the boot process to fail. Even more, you should really avoid using names on hostname.if files. > > Anybody run into this before? - is the fix to add all the symbolic > names to /etc/hosts? Well, if the hosts have fixed addresses, you'd be better using macros on pf.conf that translate to their IP address. This way you won't run into boot issues (or reload issues, in case your resolver is down). This has the added inconvenience that you need to update your pf.conf file manually every time one address changes. Now, if you really, really need to use fqdn's on pf.conf, my suggestion is that you use ifstated to detected if your link is up and your resolver working, and them load the rules into an anchor afterwards. Also, you can update the anchor to reflect any uplink unavailability. Or you can use unbound with local-zones or a unbound + nsd combo, if you also need authoritative. I think you'll need to hack your /etc/rc file to load them before your pf.conf is loaded. Cheers, Giancarlo Razzolini
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Em 11-11-2015 00:06, Nick Holland escreveu: > The point is...if you put in a DNS name, odds are you are going to end > up thinking you are blocking/passing/redirecting a DNS name..when in > reality, you are whatevering JUST the IP address that it resolves to at > the time the firewall rules were loaded. You may have missed a lot, or > it may move. > > IF you are really in a situation where the only things you are trying to > manage with DNS names are simple 1:1 name:ip mappings, an easy solution > would be to have your pf.conf file a "stub" with enough to let the > system come up, then a post boot and periodic (re)load of the "real" > rules in a separate file. I tried to help the OP by suggesting he use macros or anchors; I'd like to take it back. Don't ever use dns names on pf.conf. The only safe way to properly deal with this is using a proxy. Relayd can work quite well for simple cases. Cheers, Giancarlo Razzolini
Re: Welcome-Mail
Em 16-11-2015 13:59, Danny Nguyen escreveu: > I hope these are not dumb questions. > > Would sftp (secure ftp) be a better alternative than ftp? Which "secure ftp" you're referring here? SSH's sftp or ftps? Because if it's the latter, then I'd say it wouldn't be a better alternative. ftp is ftp. Putting a TLS layer on top of it won't change the most hated things about the protocol. And, using SSH's sftp has the added complexity of host keys to the mix. Do you expect that the OpenBSD team would manage all ssh host keys for all the sftp mirrors and put them on the install media? And what if one of them changes? > What was the > logic to remove that option on the network install versus http? is there > even a benefit for the mirrors to be on https (secure http) vs http and > would that allow for a verified download like the openbsd compact disks? You are mixing things here. You can verify any download from any OpenBSD mirror regardless of protocol (ftp, http). Last I checked, there weren't any https OpenBSD mirrors. > I > always got really concerned when the install prompted me that "Directory > does not contain SHA256.sig. Continue without verification?" before > actually using official openbsd compact dics. My intent is to assess the > strengths and weaknesses of the protocols being discussed and comparing > them with respect to security. This has been answered on this list many times. If you're really concerned, verify your disks manually, or perform a network install. My suggestion? Buy the CD's (or donate) to help the project. But perform the installation using a USB stick. As far as weakness and strengths of the protocols, they are quite irrelevant for the OpenBSD installation. Everything is signed using signify. The transfer medium can (and is) be unencrypted. Of course this pretty much means anyone listening knows you're downloading/installing OpenBSD. If your concern is this, then you'll need to figure it for yourself how to hide the fact that you're installing OpenBSD. Cheers, Giancarlo Razzolini
Re: TLS intercepting proxy [MitM]
Em 24-11-2015 11:17, Lampshade escreveu: > I know that relayd can decrypt traffic, then log, then encrypt. You know that this ain't the only thing it can do, right? > The thing is that I want to > send decrypted traffic to another process (privoxy), and then re-encrypt it. Now this, I don't think is possible. At least not without hacking privoxy itself. But hey, if you are gonna hack privoxy, why not hack it to work with divert and do the mitm itself? > I have also problem with Reyk's config because I can not divert outgoing > traffic using pf. > I have tried with rdr-to and nat-to, but it removes destination IP address in > packets. > I want to intercept and alter traffic on the same box that I run Firefox. > Is this possible using pf and relayd or I must use something else? How are you writing the rules? I think it can be done using the self keyword. You can also have success using the user directive. Cheers, Giancarlo Razzolini
Re: The kernels of *BSD include nonfree firmware blobs?
Em 27-11-2015 18:35, bofh escreveu: > Why do you continue by asking about blobs in FreeBSD? Troll Detected. Troll Fed. End of Thread.
Re: A branded USB stick as an alternative to the CD set?
Em 30-11-2015 19:03, Tati Chevron escreveu: > Again, the original idea wasn't mine. I commented on the thread, but in > my mind, I imagined receiving the install source on a medium that had the > same bar to tampering as a CD, such as masked rom. I wasn't thinking of > a standard USB flash device with a glued write-protect switch. My > original > post was a mixture of various thoughts that shouldn't really have been > posted > without further consideration. I don't know if most people are aware of this, but this has been discussed on this list many times. The income of CD sales are what "kind of" pays for Theo full time involvement with OpenBSD. I say "kind of" because sales, as he already mentioned, are going down and down each release. Don't have a CD reader on the machine? Buy them anyway and opt out of the delivery. You can download the iso from the internet, safely verify them and write your own USB stick with it. And Theo gets pay for the wonderful job he (and others of course) do with OpenBSD. Cheers, Giancarlo Razzolini
Re: A branded USB stick as an alternative to the CD set?
Em 30-11-2015 19:34, Theo de Raadt escreveu: > These days the CD revenue is about what a cashier at a store makes. This is truly sad, to not say tragical. > > It seems to keep shrinking, but I will try to keep doing it unless it > nears zero; at which point the artwork will stop also. > > I'm not doing any of this as a business. I believe the research and > development that happens within OpenBSD is very important. That's why > I continue doing this. And I think that most people here is very thankful for this. > > I cannot help but be insulted to the core when random 'people on the > internet' selfishly or unthinkingly misunderstand the focus of OpenBSD > as a R&D project, and recommend an even more broken business plan > which nobody needs or wants. Frankly, it ruins my day. > > For the time, I am on a small bursary as well from some people who > understand the importance, otherwise I'd be looking for a cashier job. I really don't want to see this happen, but I'd imagine you wouldn't stress yourself as much. Keep the good work, Giancarlo Razzolini
Re: A branded USB stick as an alternative to the CD set?
Em 30-11-2015 20:10, Bryan Vyhmeister escreveu: > Let's not waste any more of Theo's time. USB sticks are not the magic > device that some seem to think. Some are not very reliable and prone to > failure. I've had very mixed results with budget USB sticks in > particular. Going with a more expensive USB stick like a major brand > name *usually* turns out better but that's still no guarantee. If you > don't want a CD set, simply donate the amount the CD set costs directly > to the project. That provides funding for OpenBSD while also not wasting > anyone's time. > > http://www.openbsd.org/donations.html Let's just be clear that the CD's revenue (or non-revenue as it seems) goes straight to Theo. Donations do the OpenBSD foundation doesn't, at least not directly. So, in order to help him directly, buy the CD's but do not get them delivery. That way Theo saves the shipping, and you contribute directly to him. Which, isn't different from contributing to OpenBSD. Cheers, Giancarlo Razzolini
Re: A branded USB stick as an alternative to the CD set?
Em 30-11-2015 21:56, Theo de Raadt escreveu: > But that model does not help me. Please don't give out the impression > that it does. The dwindling effectiveness of the CD sales support > model is a bit of a worry. Sorry for creating that impression. It surely wasn't my intention. Now you made it even more clear how things operate. Cheers, Giancarlo Razzolini
Re: OpenBSD + pf + DPI
Em 02-12-2015 12:56, Alessandro Baggi escreveu: > I don't search an all in one solution software for DPI, but asking if > there is some software on base/ports to accomplish to this purpose and > if someone had configured a solution with OBSD for DPI (personal > experiences). My question is malformed, sorry. Take a look at bro. It's on ports. Cheers, Giancarlo Razzolini
Re: home keys in tmux
Em 02-12-2015 10:42, Ted Unangst escreveu: > How do i fix this? (Why do i need to fix it?) Coincidentally, I saw that same question asked today on IRC and it wasn't even on OpenBSD. The OP changed it by setting TERM to xterm-256 if I'm not mistaken. And he also nailed it down to the fact that the num lock switch was on (or off). At first I thought it wasn't tmux related. But now it seems otherwise. Cheers, Giancarlo Razzolini
Re: pf, anchors, and macros
Em 02-12-2015 07:56, Sarevok Anchev escreveu: > .. but I don't think it's relevant as I've tried to run the test between > pf.conf and the base anchor, and still macros defined in pf.conf are not > available from /etc/pf/anchors/base. > > Is this intended behaviour? Macros need to be present in each anchor file. Tables don't need to. I have a little script that copies all my macros after I edit /etc/pf.conf to the anchors. I use commented marks on /etc/pf.con to know where to begin copying and where to end. But you get the point. Cheers, Giancarlo Razzolini
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Em 08-12-2015 16:24, Michael McConville escreveu: > There are still some privacy benefits to using HTTPS. It will confound a > lot of simple filtering and monitoring software, and what you're reading > on the site is pretty obfuscated. It also helps security on sketchy > networks. > > HTTPS isn't a perfect solution, but it's something. Especially when ISPs > are starting to inject beacons into HTTP requests and more closely > observe usage. > > That said, I suspect none of the sysadmins have the time or interest, > and that's understandable. I started a thread regarding TLS on the OpenBSD site some time ago, I think it was 2013. There was startcom at the time and I even offered to buy certs if the startcom certs weren't acceptable. I don't see why this changed with letsencrypt in town. There wasn't interest at the time, and I don't see why there will be now. One of the main benefits of the TLS wouldn't only be to render impossible for anyone to know which pages you're accessing on the site, but also the fact that we would get a little more security getting the SSH fingerprints for the anoncvs servers. Having them in clear text as they are today, isn't very secure. Also, now that we have two free TLS certs providers, one can use HPKP and completely disregard the CA's, which is a security benefit. Cheers, Giancarlo Razzolini
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Em 08-12-2015 23:23, Stuart Henderson escreveu: > I wasn't aware that > it lets you disregard the CAs though Once the client has the two certs pinned (the primary and the backup), if a malicious CA try to impersonate the server using a forged (although perfectly valid) certificate, the client shouldn't connect to it, because it already has the fingerprint pinned. It is the same rationale as ssh host keys, trust on first use. But, by the way this thread evolved, we're beating a dead horse here now. Cheers, Giancarlo Razzolini
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Em 10-12-2015 20:03, Christian Weisgerber escreveu: > The true elephant in the room is that I can't get the current OpenBSD > source tree securely. (Well, _I_ can if push comes to shove, but > the general user community can't.) CVSync? No integrity or > authenticity. AnonCVS over SSH? Nope, no integrity or authenticity > because the mirror itself got the tree over CVSync. Assuming you > trust the mirror in the first place. I agree with you. We don't want TLS to hide the fact that we are accessing the openbsd site. We want TLS to get a little extra confidence that what we are seeing on our screen is what the OpenBSD devs wanted us to see. Someone mentioned signify keys also. Nowadays if I want to be (kind of) sure I got everything right, I need to download the files from different mirrors, using different internet connections, using vpn's and tor, etc. The TLS could be implemented on a non mandatory way, you don't need to redirect HTTP connections to HTTPS ones. But it would be nice to have the option, at least. Cheers, Giancarlo Razzolini
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Em 11-12-2015 09:28, Stefan Sperling escreveu: > I would consider signify keys printed on CDs and copied across several > web sites safer than trusting the hundreds of CA certs shipped with a > standard web browser. Didn't we just established that with HPKP you can disregard the CA completely? At least if you trust your fist access to the site. But I think this thread followed its course, lets move on. Cheers, Giancarlo Razzolini
Re: LibertyBSD, recently forked from OpenBSD, has been deblobbed as much as its creator could see?
Em 19-02-2016 12:42, Jorge Luis escreveu: > "What is LibertyBSD? > OpenBSD is universally known as an operating system designed with security > in mind, proudly being able to say that it has had "Only two remote holes in > the default install, in a heck of a long time!" Will you please, please, go away?
Re: QEMU CPU cores not showing up
Em 13-11-2013 22:40, Jeff Fuhrman escreveu: > I'm the tech Bruno has been working with regarding this. QEMU version is 1.5 > and the relevant section of the KVM Config file is " > 4". > We've tried it with 2 sockets, with 4 sockets, with 2 threads, 4 threads, and > so on. ACPI and APIC are enabled for the KVM Container. > > Jeff Fuhrman > Level 2 Technician - BlueVM I have the same issue using the same qemu version. Do you guys also experience random lockups? I've seem sometimes the OpenBSD VM sshd will simply stop answering. Also if I try to login directly through the VM's console, when I insert the username it will not prompt me for a password. The strangest thing is, the machine still answer ping packets. I could not debug it yet, since it happens randomly. I have to force a shutdown to be able to access the machine again. To add to the strange thing, I have another bare metal machine, with a different hardware, but using the same qemu version, and I had never experienced any lockups. But it also will not show more cores on OpenBSD. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: QEMU CPU cores not showing up
Em 14-11-2013 11:43, David Coppa escreveu: > On Thu, Nov 14, 2013 at 2:33 PM, Giancarlo Razzolini > wrote: >> Em 13-11-2013 22:40, Jeff Fuhrman escreveu: >>> I'm the tech Bruno has been working with regarding this. QEMU version is >>> 1.5 and the relevant section of the KVM Config file is " >>> 4". >>> We've tried it with 2 sockets, with 4 sockets, with 2 threads, 4 threads, >>> and so on. ACPI and APIC are enabled for the KVM Container. >>> >>> Jeff Fuhrman >>> Level 2 Technician - BlueVM >> I have the same issue using the same qemu version. Do you guys also >> experience random lockups? I've seem sometimes the OpenBSD VM sshd will >> simply stop answering. Also if I try to login directly through the VM's >> console, when I insert the username it will not prompt me for a >> password. The strangest thing is, the machine still answer ping packets. >> I could not debug it yet, since it happens randomly. I have to force a >> shutdown to be able to access the machine again. > Have you applied the patch for the errata below? > > for 5.4: > > http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/003_vnode.patch > > or for 5.3: > > http://ftp.openbsd.org/pub/OpenBSD/patches/5.3/common/010_vnode.patch Not yet David, will look into it. I am moving almost all of my infrastructure servers to virtualized ones. Even my firewall is virtualized now. But I am experienced these random lockups now and then. Will apply the patch and test it again. I do have another issue with running an OpenBSD guest in which it wont do interrupt remapping so I have to enable an unsafe behavior on kvm which allows it to do pci passthrough with "unsafe" interrupts. There are some issues using this in which a privileged user in the guest machine could escalate it's privileges on the host and/or crash it. Anyway, this isn't a problem for me right now, when I do have some time I'll look into it. Thanks, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: QEMU CPU cores not showing up
Em 14-11-2013 14:18, InterNetX - Robert Garrett escreveu: > The issue you outlined below is not an openbsd issue, this is a kvm > issue. and depends greatly on the version of linux/whatever you are > using. The interrupt remapping you are talking about is either a bios > issue (likely) or an issue with the hypervisor. > > it sounds like to me you are using or attempting to use SRIOV. > > all of the issues that you mentioned are still relevent even with > "safe interrupts", as well as several you did not mention. Robert, I do believe it is a specific issue with OpenBSD, because using the same hypervisor I can do pci passthrough, using the same versions, hardware, etc, to other operating systems using interrupt remapping. I do have indeed SRIOV enabled on my bare metal bios. The thing is that kvm specifically warns me that the guest do not support interrupt remapping, when using openbsd only. As I told before, it is not a problem for me right now, since I enable the unsafe interrupt assignment and the OS works normally. Also, David, thanks for pointing out the patch, because since I applied it, I did not experienced anymore lockups (so far). I am betting it was indeed the problem. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: rtfm
patric conant escreveu: Is /etc/group documented somewhere, specifically, there are several _groups and I am trying to discover if they are read, I thought I had read that _groups were ignored, but can't find reference to it one way or another. man -a group makes no mention of files, nor the file, apropos /etc/group also yields nothing, any pointers are appreciated, also, is this a hole in the documentation, or just my understanding of it? You need to learn how to use the apropos/man utilities. Issuing an apropos group returns lots of useful info: . . . group (5) - format of the group permissions file group (8) - manage group information on the system . . . The number between the parenthesis specify in witch part of the manual pages is the page you want, you only need to specify it: man 5 group And you're ready to go. Also, man man is always a good reading. My regards, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD Stable Ubuntu 8.04 Hardy Heron 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
Re: help with pf and transparent squid
fRANz escreveu:
Hi.
I've some trouble with this configuration:
LAN -- fw (openbsd 4.4) -- adsl router
LAN: 192.168.100.0/24
fw int int: sis1
fw int ind: 192.168.100.2
fw ext int: sis0
fw ext ind: 10.0.0.2
router int ind: 10.0.0.1
I try to configure pf to redirect all web traffic from internal lan to
an internal squid server (192.168.100.8) but rdr doens't works.
Now clients works _without_ proxy; when I enable this rule:
rdr pass on $int_if inet proto tcp from any to port www ->
192.168.100.8 port 3128
no one can navigate.
If I manually config browser to use squid as proxy, everything goes
fine (so squid is active and functionally).
What's the trouble in this config?!
Regards,
-f
#pf.conf
# macros ###
ext_if = "sis0"
int_if = "sis1"
out_tcp = "{25, 53, 80, 110, 443}"
out_udp = "{53}"
table { 192.168.100.1/32, 192.168.100.2/32, 192.168.100.4/32, 192.168.
100.5/32, 192.168.100.6/32, 192.168.100.7/32, 192.168.100.8/32, 192.168.100.250/
32 }
table { 192.168.100.50/32, 192.168.100.51/32, 192.168.100.52/32, 192.1
68.100.53/32 }
table { 192.168.100.3/32, 192.168.100.100/32, 192.168.100.230/32 }
# options ##
set block-policy return
set skip on lo0
scrub in
# nat ##
nat on $ext_if from !($ext_if) to any -> ($ext_if)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr on $int_if inet proto tcp from any to port ftp -> 127.0.0.1 port 8021
#rdr pass on $int_if inet proto tcp from any to port www ->
192.168.100.8 port 3128
rdr on $int_if inet proto tcp from any to 192.168.100.251/32 port 8080
-> 10.0.0.1 port 80
# filter ###
anchor "ftp-proxy/*"
antispoof quick for { lo $int_if }
block in all
pass in on $int_if proto icmp all keep state
pass in on $int_if proto tcp from any to 192.168.100.8 port 3128 keep state
pass in on $int_if proto {tcp, udp} from to any keep state
pass in on $int_if proto {tcp, udp} from to any keep state
pass in on $int_if proto tcp from to any port $out_tcp keep state
pass in on $int_if proto udp from to any port $out_udp keep state
pass out keep state
Create a new entry on inetd.conf, much of the one in the pf faq:
127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w 20
192.168.100.8 3128
Restart inetd and then, instead of making a rdr rule redirecting the
traffic to the squid server, you redirect it to the port your inetd is
listening. The netcat then will create a connection to your squid server
and everything should work:
rdr pass on $int_if inet proto tcp from any to port www -> 127.0.0.1
port 5000
The reason why the rdr you're trying to do, doesn't work, is that, the
pf won't reflect the connection back to the interface it come. I recall
making this work on other firewalls, but on pf, it doesn't work. But,
using the inetd work just as the same.
My regards,
--
Giancarlo Razzolini
http://lock.razzolini.adm.br
Linux User 172199
Red Hat Certified Engineer no:804006389722501
Verify:https://www.redhat.com/certification/rhce/current/
Moleque Sem Conteudo Numero #002
OpenBSD Stable
Ubuntu 8.04 Hardy Heron
4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
Re: help with pf and transparent squid
Stuart Henderson escreveu: On 2008-12-30, Giancarlo Razzolini wrote: fRANz escreveu: Hi. I've some trouble with this configuration: LAN -- fw (openbsd 4.4) -- adsl router LAN: 192.168.100.0/24 fw int int: sis1 fw int ind: 192.168.100.2 fw ext int: sis0 fw ext ind: 10.0.0.2 router int ind: 10.0.0.1 I try to configure pf to redirect all web traffic from internal lan to an internal squid server (192.168.100.8) but rdr doens't works. Now clients works _without_ proxy; when I enable this rule: Create a new entry on inetd.conf, much of the one in the pf faq: 127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w 20 192.168.100.8 3128 Restart inetd and then, instead of making a rdr rule redirecting the traffic to the squid server, you redirect it to the port your inetd is listening. The netcat then will create a connection to your squid server and everything should work: rdr pass on $int_if inet proto tcp from any to port www -> 127.0.0.1 port 5000 the rdr+nat rule combination from the same faq page is slightly less insane for this use, but it still means you lose IP addresses from the squid logs, which you might not want to lose. it's better to put the squid on a different network interface + subnet. The is this downside, well noted. But, with some simple tricks, you can make a log on the firewall also, with the page's people are accessing. But, just a question, why not put the squid proxy in the firewall? My regards, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD Stable Ubuntu 8.04 Hardy Heron 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
Re: Release IP-adress OpenBSD 3.8
Anders Vquist escreveu: Hello. I have been looking for information on how to release the current lease of IP-adress. What should I di, where should I start, if I want to release the IP-adress? /Anders It's a little vague, but, if you are using dhclient to get an ip from a dhcp server and want to change your ip address, the short answer is: you can't. But, if the dhcp server was configured according some "best practices", the lease time you be one day or so. So, if you stay one day with the machine offline, you'll probably get a new ip the next time you turn it on. Another option is to change the interface mac address, but this must be done every time you boot the machine, which is a pain in the ass. Now, if you are the dhpd server and want to release an ip address, i always find it more easy to: 1) stop the dhcpd server 2) edit the file /var/db/dhcpd.leases and manually remove the entries corresponding to the desired ip address. 3) start the dhcpd server again. Keep in mind the next time you answer something on the list to be more specific and descriptive. My regards, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD Stable Ubuntu 8.04 Hardy Heron 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
Re: Binat purpose?
On 25-10-2014 15:10, Theron ZORBAS wrote: > # here is where and what i dont know to do? > # How to forward https requests to https_server arriving at pppoe1 interface/IP Your problem isn't with binat, which, by the way, you don't need. There are several options for solving your problem. The easiest one is to create a rdr-to rule with a reply-to rule. This will make your packets to return through the right interface. Take a look at the pf.conf man page. But basically the rule would be something like: pass in on ($wan2) from any to ($wan2) port https rdr-to $https_server reply-to $wan2 Cheers [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: sudo nohup tcpdump at startup
On 02-02-2015 17:03, fRANz wrote: > Again, > it's not a problem hack the rc file but when possible I avoid it, as > suggested many times in this list;-) You could use tmux for this. You can start a detached session that in turn run your command. You can latter attach to it and see what went wrong. My suggestion is that you call tmux from /etc/rc.local using su -c to make it run as another user and then give that user permission to sudo to root for running the tcpdump command. This way you avoid needing to ssh as root to the machine, and can also filter which commands the user can run in /etc/sudoers. Cheers, Giancarlo Razzolini [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: a thankyou to OpenBSD
On 10-02-2015 22:26, Diana Eichert wrote: > My day job entails a lot of Linux support, lately I've been > dealing with the big screwup associated with network interface > naming. WHY can't Linux follow BSD's straightforward NIC > naming? This answer is a simple one: systemd > It's positively bizarre all the crappy little files > and "utilities" they have come up with so you can munge NIC > names to something more useful than "p3p2"!!!. I don't know if you know this, but just put net.ifnames=0 in your kernel's parameters and it will revert to the old way. Anyway, I, like you, have many OpenBSD systems that "just work". Thank you OpenBSD. Cheers, Giancarlo Razzolini [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: CPU criteria for OpenBSD firewall
On 18-02-2015 20:30, ML mail wrote: > Stupid question but if you would have to choose between two different Intel > CPUs for an OpenBSD firewall using 4 to 6 Intel NICs with all /24 networks > behind and around 50-60 Mbit/s average traffic would you rather choose the > CPU with higher Frequency and less cores or for a CPU with lower frequency > but more cores? This question isn't stupid at all. And the answer is probably entirely based on your setup. I do have a similar system, but with less average traffic, 10MB/s, and one 6-port intel card. In my setup, having the lower frequency, more cores is better, because my firewall isn't used just for PF. If you're gonna use you OpenBSD firewall for other processes such as, proxy, dns server, web server, dhcp server, it won't hurt to have more cores. Cheers, Giancarlo Razzolini
Re: CPU criteria for OpenBSD firewall
On 19-02-2015 01:12, Eric Furman wrote: > A firewall should be a firewall. Period. > It's your first line of defense against attack. > Each and every additional thing you run on it just > makes it that much more vulnerable to attack. Of course it does. But since not all of us have the budget for this kind of setup, I believe this trade-off is an acceptable one, if you understand the risks. Also, there are some things you can't do if you run the services on a separate machine such as divert(4). Cheers, Giancarlo Razzolini
Re: lynx is gone?
On 04-03-2015 15:48, Jeff St. George wrote: > Its not in my pay grade to offer a technical opinion on Lynx removal! > But ,,WHAT r u folks using instead, considering?? Well, for the task the OP mentioned, finding a mirror for pkg_add, you could do plenty of things to accomplish that. netcating to the OpenBSD site and running the http get's by hand is one that comes to mind. curling the mirrors page is another. The fact is, there are no decent/secure text mode browsers, and given the discussion on tech@ last year about lynx removal, I believe it should have gone sooner. I don't think any other text mode browser will make into base in the near future, unless someone develops a secure one. Cheers, Giancarlo Razzolini
Re: lynx is gone?
On 04-03-2015 20:30, Paolo Aglialoro wrote: > > Using netcat or ftp to browse the web/intranet/localhost in the 3rd > millennium is like eating a steak with a spoon. But it's so fun man! If people looked under the hood more often, we wouldn't had the bug nightmare that was these past years. Heartbleed, ghost, shellshock, etc. Konsole output ~# nc -vvv www.openbsd.org 80 Connection to www.openbsd.org 80 port [tcp/www] succeeded! GET / HTTP/1.1 Host: www.openbsd.org HTTP/1.1 200 OK Date: Thu, 05 Mar 2015 13:28:54 GMT Server: Apache Last-Modified: Wed, 19 Nov 2014 17:29:26 GMT ETag: "84c3c06e225fcffbdd723847e25fa29b1586fbe2" Accept-Ranges: bytes Content-Length: 4871 Content-Type: text/html > > It's the same logic of leaving open root ssh access with pw=password: > nothing can stop a stupid misuse of things. But this is not a good reason > to delete ssh. lynx removal does not compare to this. It was removed based solely on technical merits. That, and the fact that no OpenBSD dev would spare time to fix it. > > And, just for the records, I bet that 99% of use of lynx is just sysadmin > stuff on CLI systems, for the rest (the dangerous horrid scary world...) > there are X clients with Firefox. Who's going to warez sites with lynx? Of > course we're all a pkg_add away, but that is not the point. I didn't got your point. > > Security is a damn good thing. > Excesses not. Then you're on the wrong Operating System. OpenBSD is secure by default. If lynx had the tiniest chance of compromising your system, then I'm glad it's gone. Cheers, Giancarlo Razzolini
Re: lynx is gone?
On 05-03-2015 13:20, Paolo Aglialoro wrote: > I perfectly agree with you, both on fun and curiosity. > > Nevertheless, not all the times we have got time enough "to have fun > netcatting servers". More than often u just have to go straight to the > point. But before you can get to the point, someone (hopefully) looked under the hood for you. > Btw, try these with (net)cat: > > $ lynx saveddocument.html > $ pdftohtml -stdout -i manual.pdf | lynx -stdin As I mentioned, "for the task the OP mentioned". Of course netcat does not replace a browser. > Actually it does on a user viewpoint: a server daemon is up 24/7 while a > client is activated by the user. For the server, insecurity comes mainly > from its own flaws, for the client danger does not mainly come from the > tool itself (unless it's a totally hopeless sw) but from the *potentially* > silly utilization which is done by the user. You forget that programs bring along libraries and other potentially nasty stuff when ran. lynx had support for a lot of protocols besides http. Take a look at the tech@ thread from last year that prompted it's removal. > So it looks like that, till some months ago, everybody here was on the > wrong OS and risking their lives, as lynx was in base! But I have never > read here about anybody who had his system compromised because of poor > lynx. So, right now, this deletion reflects more a "what if" worry than a > real threat, i.e. lynx <> shellshock. Many of OpenBSD security features are based on " what if". That does not mean that in the future, the "what if", can't become a real threat. The mentality of the OpenBSD devs is in the right place. They try hard to make a OS that try to don't allow you to shoot yourself in the face. Even if that means removing software that might (or not) pose a threat to you in any point in the future. Cheers, Giancarlo Razzolini
Re: Route for a special IP
On 11-03-2015 12:39, Zhi-Qiang Lei wrote: > I have a OpenBSD 5.6 router with two external interfaces pppoe0 and tun0. I am assuming the pppoe0 connects directly to the internet and tun0 also has internet connectivity at the other end of the tunnel, right? > > Generally, all packets will go through pppoe0. However, now I have a special > client with IP 192.168.1.200, is it possible to force it to use tun0? Thanks. You can do this with a simple route-to rule: pass in quick from 192.168.1.200 to any route-to tun0 If tun0 has a fixed gateway address you can change the rule to: pass in quick from 192.168.1.200 to any route-to (tun0 gateway) Cheers, Giancarlo Razzolini
Re: What happens to OpenBSD when Secure Boot becomes manditory?
On 02-04-2015 17:52, John Merriam wrote: > I have a feeling that there will be alternatives to secure boot for a > while if not forever. I for one will never buy anything that is secure > boot only unless the 'secure boot' is something that I have complete > control over. I would rather use a typewriter... The DoomsDay scenario of the first machines that got out with "SecureBoot", in which they only had Microsoft keys and never allowed the user to change it, is less and less common. Today you have control over SecureBoot. You can disable it, you can reset it's keys, so it will sign whatever you have there and go from it and so on. That's not to say that some manufactures don't get it wrong. I think is very dangerous that microsoft gets to dictate how the manufactures should do their firmwares, but this is the world we're living on these days. At least now we have more people paying attention to what happens on our computers BEFORE any OS is loaded. Cheers, Giancarlo Razzolini
Re: offtopic: political correctness
On 08-05-2015 15:38, Steve Litt wrote: > Yes, it sucks, but no more than calling it "nazi". The day "Absolute > OpenBSD 2nd Edition" kills millions of Jews, Gypsies, and retarded > people, while invading Poland and rocketing London, it will earn the > epithet "nazi". Until then, using that epithet simply dilutes what the > real nazis did. You proved your own point by saying "retarded people". Which is a term that has not been (or should not) used for decades now. Just to prove that is hard to please everyone. A joke is a joke. Sometimes it makes a hard subject easier to swallow (as it is with cryptography). Perhaps *that* one was misplaced. Cheers, Giancarlo Razzolini
Re: offtopic: political correctness
On 08-05-2015 11:38, Nick Holland wrote: > In that case, you may wish to avoid reading the FAQ, the man pages, > certainly not the commit message log. Come on. Those are hilarious! > You probably don't want to talk to the developers. Some at least. > > The only thing PC about OpenBSD is ... a couple target platforms. :) I'm remembering someone that was offended by smtpd manual page(IIRC). Even sent a patch to fix it and everything! > > Nick. > (making note to offend more in the future) Oh no! Please don't! Cheers, Giancarlo Razzolini
Re: Update OpenBSD Remotely
On 17-05-2015 11:08, Peter Leber wrote: > I recognize that there's m:tier's binary patching service > (https://stable.mtier.org), but the packages are signed > by m:tier rather than the OpenBSD project. While following m:tier's > binary patches is a good compromise to me, it's not a perfect solution. > I'm perfectly fine with running the -current flavour of OpenBSD feature- > and stability-wise, but I did not have the success of remotely triggering > a script, rebooting the machine and have an up and running updated > machine. > While I did find the autoinstall(8) feature, which, since 5.7, should be > able to trigger an automatic upgrade if the file /auto_upgrade.conf is > present, I did not see an effect in the bootup messages on the virtual > machine I'm using for testing things out. > Furthermore, I did find a tool named snap, aiming at making running > -current more enjoyable (see https://github.com/qbit/snap), but it does > also seem to be relying on the user to manually start the upgrading > process on system reboot, if I got everything correctly. Do you really need to follow -current? Because I've been using m:tier and their openup tool for years to follow -stable with no problems. I don't like the idea of automatic update + reboot. But it's doable with openup. I personally have it setup to run with -c from cron so it will mail me what changed. Following -current on a production or critical environment will prove to be a challenge. Unless you carefully test each snapshot and then have some tool like puppet to automate the upgrade with snap or other tool. Even with autoinstall(8). Cheers, Giancarlo Razzolini
Re: Resolve names from chroot'ed OpenBSD httpd
On 21-05-2015 20:57, Daniel Bolgheroni wrote: > Warning: stream_socket_client(): unable to connect to > tcp://api.wordpress.org:80 (php_network_getaddresses: getaddrinfo > failed: no address associated with name) in > /htdocs/wordpress/wp-includes/class-http.php on line 1008 Do you have the relevant files in your chroot's etc directory? I believe that you need at least a resolv.conf there. Also, a localtime is always a good idea. Cheers, Giancarlo Razzolini
IPV6 routing issue
HI all, I've recently changed my ISP and they have native IPv6. My customer premises equipment, which is a GPON, supports both stateless as DHCPv6 on it's LAN interface. I want to put a OpenBSD firewall between this CPE and my internal network. I'm using OpenBSD 5.7 stable. My CPE receive a /64 prefix delegation from my ISP. Unfortunately, this is a dynamic prefix, so I can't configure anything manually. I've managed to get wide-dhcp6 working and requesting the prefix to be delegated to my internal network. After that, all I needed to do was to run rtadvd on my internal interface, and my internal LAN machines began to be autoconfigurated getting ip's from the delegated prefix. The OpenBSD firewall has 2 ipv6 addresses. One on the WAN interface and another on the LAN interface. If I use ping6 to ping any ipv6 host from my firewall, I can ping them with no problems. But, If I ping setting the source to be the ipv6 address from the internal interface, it won't work. Also, no machine from my LAN can connect to any host through ipv6. I've inspected the traffic with tcpdump, and I can see the packets leaving my network and getting on the destination. The problem is the packets never gets back. My CPE equipment keeps asking for neighbour solicitation asking who has the ipv6 address, but the OpenBSD firewall never replies, so the packts get dropped. I'm currently with PF disabled. But I had the same problem with it enabled and with the default firewall configuration. I'm trying first to get ipv6 connectivity working to after filter the packets. Anyone had a similar issue? Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 10:07, Patrik Lundin escreveu: I have struggled with a similar problem a few years back. Can it be that the upstream equipment does not create a route for the delegated prefix pointing to your openbsd machine? This would explain why you see neighbour solicitations on the outside interface. The upstream router is not aware that the prefix should be routed to you. Yes, I believe it to be te problem. The prefix is delegated to the CPE, not the OpenBSD machine. When I run the dhcp6c program, it asks for a prefix delegation from the CPE and gets one. But I don't think that the CPE is trully delegating the prefix, hence that's why he's issuing neighbor solicitation messages. Someone pointed to me that I'll need to use a ndp proxy or use the openbsd machine as a bridge filter. I can't change the CPE configuration, it's locked by my ISP. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 10:43, Gregor Best escreveu: I've also seen something similar. A friend of mine suggested [0], though I haven't tried it. I circumvented my problem by using a routed /64 on a Hurricane Electric tunnel. I wouldn't like to use a tunnel, since my ISP is (kind of) providing native IPv6 connectivity. Depending on your hosting provider, their setup might actually be vulnerable to a neat little trick: If you see NDP requests for prefixes that are not your own while tcpdump'ing your external interface, you might be able to add an address inside one of those networks to your external interface and have it reachable from the outside, so that in effect you can use an IPv6 address that's outside of your prefix. Since my CPE is working in routed mode, I don't see anything like that. But, I believe that this will be a problem for many ISP's, since I doubt they will implement authenticated NDP. I will look into this ndp proxy daemon, since I couldn't make the ndp(8) proxy functionality to work. Thank all you guys who replied. Both on and off list. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 10:43, Gregor Best escreveu: https://github.com/DanielAdolfsson/ndppd This doesn't compile on OpenBSD. I'm correcting it's includes and headers, but it seems it's linux centric. I'll probably need to change it's code. I've found some other tools but it seems almost all of them are linux centric: [0]: https://github.com/fishilico/autoneighxy [1]: https://github.com/andriyanov/ndp-proxy I don't know if OpenBSD does have any NDP proxying functionality, besides the one in ndp(8). But it seems to me that, besides a bridge, a NDP proxy is the only viable solution (besides my ISP allowing me to change my router configuration). Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 16:17, Christian Weisgerber escreveu: So you have TWO networks. One between the CPE and your OpenBSD firewall, and one containing the firewall and your internal machines. Yes. Two interfaces, to be more exactly. So you get ONE network address. I get a prefix on the CPE. And I can configure any address in the prefix on any machine on my LAN (or the OpenBSD LAN iface). And traffic gets out. Just won't get replies. You can't use a single network address for two networks. This has nothing to do with IPv6. It's the same with IPv4. I'm aware of that fact. But, since my CPE replies to an IA_PD request, I imagined it would be able to route the packets correctly. You can use private addresses for your internal network and run NAT on the firewall. Or you can configure your firewall as a bridge and filter there. http://www.openbsd.org/faq/faq6.html#Bridge I'm trying to get some NDP proxy running on OpenBSD. But all of them are linux centric. Perhaps, for now, I will use it as a filtering bridge. Since I have enough interfaces on my OpenBSD machine, I will have a bridge specifically for IPv6. And IPv4 will still be NATed. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 16:44, Christian Weisgerber escreveu: Well, you can add an IPv6 address for each internal host to the external interface of your firewall, use private addresses on the internal network, and then use pf's binat to map between the two. This will preserve port numbers, although it may not be enough for nasty protocols like SIP. I know I could use NAT. But, I really think it's almost an abomination to use it, when you have native IPv6 support. I'll contact my ISP to see if they can change my CPE mode of operation or, at least, allow me to configure it. In the meantime, I'll go with a bridge firewall. It seems like the most hassle free way to go. Perhaps I'll hack some NDP proxy. But I need IPv6 connectivity, and I need it now. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
Em 01-07-2015 11:47, Patrik Lundin escreveu: Thanks for the pointers, the first commit was pointed at by another developer off list, and seems like exactly the fix needed for the initial issue we ran into. I've ran exactly into this same issue, and had to add the default router manually. Your thread, and mine (a few days ago): https://marc.info/?t=14352773773&r=1&w=2 They show how IPv6 is being implemented in the real world. Most ISP's are being forced to implement IPv6 and all sorts of things, mostly bad, are coming out of it. In my case, I ended up implementing a bridge. But I believe in the near future I will have to use a NDP proxy, because my CPE advertise itself as a dns server, both in SLAAC and through DHCPv6, so it overrides my own configuration. But it's good to know that OpenBSD current is moving into RFC 7084 direction. Please, report back to the list if you can make it work with -current. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
Em 01-07-2015 16:29, Florian Obser escreveu: What I was trying to say: ifconfig IF inet6 autoconf was supposed to do the same as rtsol IF before I removed it. Turns out it does more; it allows sending of router solicitations and accepts (part) of router advertisments even if forwarding is enabled. That was an oversight and wasn't supposed to be possible. So don't depend on it, it can't possibly work. On the other hand it's not really a bug either. More of a missing feature. So using it hurts, so don't do it;) That missing feature was added in -current This is consistent with behaviour I've seen on -stable. Good to know that it's fixed on -current. Cheers, Giancarlo Razzolini
Re: Microsoft Now OpenBSD Foundation Gold Contributor
Em 08-07-2015 15:34, Jorge Gabriel Lopez Paramount escreveu: there are other OSes out there, no need to make accusations or throw a tantrum about it. Go use these other OSes and leave OpenBSD alone. You'd be doing us a favor. Cheers, Giancarlo Razzolini
Re: nat on addresses with different default routes
Em 08-07-2015 15:05, lausg...@gmail.com escreveu: My isp gives me a bunch of dynamic external ip addresses via dhcp one per nic. They don't share common default gateway route all together, so I'm forced to put each next in its own rdomain. As so, http://www.openbsd.org/faq/pf/pools.html#nat or http://www.openbsd.org/faq/pf/pools.html#outgoing examples are not applicable. I'm just interested in random redistribution. Here's an ugly solution I currently use: match out on em0 inet from lan:network nat-to (em0:0) match out on em1 inet from lan:network nat-to (em1:0) match out on em2 inet from lan:network nat-to (em2:0) pass in on lan inet from lan:network to !lan:0 # fallback pass in on lan inet from lan:network to !lan:0 rtable 1 probability 34% pass in on lan inet from lan:network to !lan:0 rtable 2 probability 34% What would be the correct way of doing this? Is it possible to achieve this using vether(4) without big performance penalty (which occurs when real nic and virtual interface which relies on it are not in the same rdomain)? Thanks! You could, instead of using routing domains, enable mpath, and then deal with the default gateways using route-to and reply-to. Load balancing can be achieved with the round-robin or, even better, least-states directive. To put a cherry on top, you can make all these rules on anchors and make ifstated check for the gateways availability, and update the rules accordingly. At least this is my approach for dealing with many default gateways. Using tags you can write an even conciser ruleset. Cheers, Giancarlo Razzolini
Re: Microsoft Now OpenBSD Foundation Gold Contributor
Em 08-07-2015 18:48, Артур Истомин escreveu: And it was send from Linux OS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 Shame for you, linux fan boy:) And this proves what exactly? You don't know about my use for neither Linux nor OpenBSD, you don't get to talk about it.
Re: nat on addresses with different default routes
Em 09-07-2015 02:27, lausg...@gmail.com escreveu: Thank you for the answer! Indeed its a more correct approach. Is there a simple way to teach (any openbsd compliant) dhcp client to use mpath? Also not sure whether it will work in this case:http://www.rinta-aho.org/blog/?p=214 I don't recall if the openbsd base dhclient have it, but you could possibly use some that is on ports and make it not add the default routes. And, you could make it call a script that creates them. They need to be created with the -mpath modifier anyway. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
Em 13-07-2015 13:39, Christian Weisgerber escreveu: Once you get that far, you might notice that dynamic addresses for your network are rather inconvenient. You'll need to update all references to your internal hosts in * pf.conf * DNS zones * ... any other daemons that might refer to them ... And you need to reload you pf rules when any of them changes (specially privacy addresses). You'll also need to distribute the addresses to your hosts. If you don't like SLAAC-style addresses, you'll need DHCPv6. Which you might also need for the nameserver, NTP server, etc. This for a IPv6 only network. My approach is to keep the RFC 1918 internal IPv4 net for these. Out of the box, OpenBSD is poorly equipped for all of this. Agreed. On the other hand it's quite equipped in the routing and firewalling of IPv6 networks. Even NAT64 is simple to do with pf. I recently switched ISPs and the new one offers native IPv6 the TR-187 way, but given that level of pain I'll stay with my SixXS tunnel and my static /48 for the time being. I'm doing the exact same thing. My tunnel have an acceptable latency and, since I'm using it only for a site to site VPN, I'll stay with it for a while. But my ISP is implementing native IPv6 and sooner or later I'll have to deal with this. So will you. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
Em 13-07-2015 14:42, Michael McConville escreveu: Part of it was that you need inbound IPv6 ICMP and UDP ports open. This seems like a fundamentally bad idea because it prevents client machines from just blocking all incoming connections (something I've done since starting with OpenBSD). The client doesn't need inbound UDP ports to be open. The OpenBSD firewall do, if you're using DHCPv6 to configure it. If using SLAAC, only RS and RA icmp messages are needed. Since stateless configuration is done using multicast (ff02) and link-local (fe80) addresses, no need to worry. You can even make a rule allowing only your CPE link-local, if you want. Also, DHCPv4 seems to do fine without incoming connections. Maybe there's a good reason for them, though. DHCPv4 needs port 68 udp to be open. The difference is that many firewall implementations (not pf) have this allowed in their default configuration. Here's the guide that solved my pf woes: http://pivotallabs.com/configuring-freebsd-9-1-as-an-ipv6-dhcp-client/ I was considering trying to develop a tool to make it a smoother process. However, it increasingly seems like a consequence of DHCPv6 being unnecessarily complex. You don't need DHCPv6. I use stateless both for my firewall getting it's IPv6 address from the CPE and for it advertising the prefix on the internal network. Most modern systems can configure the dns using stateless configuration. So only a subset of ICMPv6 messages need to be allowed both on the router and clients. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
Em 13-07-2015 17:42, Daniel Melameth escreveu: I’d love it if someone would be open to spending the time to do a “PHD” write up on getting OpenBSD base usable as a stateless IPv6 router/firewall with Comcast. While I agree that write ups like these should be unnecessary, and man pages should have all the relevant information needed for someone to do this without hand holding, IPv6 is still “new,” has a lot of moving parts and still isn’t widely used. For one, I didn’t know all of this could be done without DHCPv6 so I’m very interested in doing this at home. Well, I prepared myself studying IPv6 years ago using tunnel brokers like sixxs. You can find a lot of relevant information on the man pages, but, since a man page is better to be simple and clean, some things need RFC's digging and/or source code. I will take some time in the near future to try to port a NDP proxy to OpenBSD. I'm currently using a bridge firewall between my CPE and the client machines. While this works, the machines get the DNS servers from the CPE, and not from my firewall, which is far from optimal. But I can at least filter on the packets as they pass through my bridge. Better to have the clients talk directly to the CPE,which, by the way, comes from factory with no firewall enabled. Any connection from outside gets routed to the clients. Better enable firewall on your clients too. You never know when you will connect to an IPv6 enabled network that routes every incoming connection. I know, I know, end to end connectivity, etc. But people aren't prepared to this. The CPE routers today do not allow incoming connections, because we have to use NAT. So it would never know where to forward the packets to, unless you tell it to. But, with IPv6 end to end, there will be a lot of people that will be caught off guard, specially because almost every OS (except OpenBSD) will automatically configure IPv6 if present. Cheers, Giancarlo Razzolini
Re: nat on addresses with different default routes
Em 17-07-2015 14:17, lausg...@gmail.com escreveu:
Ok, so isc-dhclient + dhclient-script with this
modificationhttp://www.rinta-aho.org/docs/openbsd-pf/dhclient-script.patch
supplied to it + route-to rules used like
inhttp://www.rinta-aho.org/docs/openbsd-pf/pf.conf do work.
Nice to hear that. This script can sure be improved.
However round-robinhttp://www.openbsd.org/faq/pf/pools.html#outgoing
construction doesn't work for this case.
Rule like
"pass in on lan inet from lan:network to !lan:0 route-to { (cnmac1 ), (cnmac2
) } round-robin"
fails with
"multiple tables or dynamic interfaces not supported for translation or routing"
and I don't know other way of dynamic passing of gateways from dhclient to pf
for this rule without usage of multiple tables.
As I mentioned, I would use least-states, instead of round-robin. Also,
I had a similar issue and solved it using (egress). Since your
interfaces will have default routes, they will be all part of the egress
group. You can exploit that. Use tags and tcpdump to debug your rules, I
believe you can find a solution.
Cheers,
Giancarlo Razzolini
Re: nat on addresses with different default routes
Em 17-07-2015 17:38, lausg...@gmail.com escreveu: Thanks much for all your good help! I will try it. No problem. For now I'm just still using probabilistic rules with quick keyword + fallback rule but using mpath instead of rdomain and this works smoothly now! If I recall correctly, you could mix mpath with rdomains. But, as much as I like rdomains, I still prefer mpath for multiple ISP's setups. If I'll need to setup multi-isp setup ever, I'll use anchors and "make ifstated check for the gateways availability, and update the rules accordingly" like you suggested. ifstated works great in this. It's a state machine, so you can code any scripts into it and handle very complex setups. The most complex I ever recall I've done was a firewall with 4 different ISP's, and a complex ruleset. There were all sorts of checks and failovers, lots of anchors. This was almost 10 years ago. Things have changed. But some didn't. Cheers, Giancarlo Razzolini
Re: PPPOE issue
Em 17-07-2015 18:56, "Dante F. B. Colò" escreveu: I already posted this question here but i think i didn't explain very well, i have a issue in a openbsd 5.7 (tried also 5.6 and 5.5 same thing) with pppoe internet broadband connection , when i start the pppoe0 interface the connection does not estabilish and shows the message below repeatdly ,how can i troubleshoot this , does anyone here have any idea ? pppoe0: host unique tag found , but it belongs to a connection in state 3 pppoe: received PADO but could not find request for it With only this there isn't much we can do to help you. How are you configuring you pppoe interface? What does tcpdump on the physical device tells you? I had some problems with more than one concentrator replying to PADI requests. Had to block it's MAC address requests using a bridge and mac filter rules. It wasn't ideal, but it worked. My ISP had a broken configuration where more than one concentrator would reply. They eventually fixed it, but I had to debug a lot to get to this. Perhaps you're seeing something similar. But without more information it's difficult to know. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: > In my *very* limited testing, using variations of the first ssh > command in that blog post, none of my OpenBSD boxes with fairly > pristine out of the box /etc/ssh/sshd_config permitted more than three > tries before closing the connection. I also tested some Linux boxes > (CentOS 6.something) with the same result. I have tested the command with various linux (CentOS 6, Ubuntu 12.04, 14.04, 15.04, Archlinux, plus some others) and OpenBSD (5.4, 5.5, 5.6 and 5.7) machines, and none of them were vulnerable. I don't have any FreeBSD machine available to test it. But it seems to be the only OS affected. I'm betting that they have some bad interaction between the openssh configuration and their PAM configuration. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: > However, running that command pinting at a FreeBSD 10.1 box in my care > gave more than three tries. I aborted well before reaching 1 for > obvious reasons. Digging some more, I've found this: http://seclists.org/oss-sec/2015/q3/156 It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
Em 23-07-2015 13:29, Garance A Drosehn escreveu: > It is a real issue. Your servers might not see the issue depending on > what > options have been set for sshd_config. My freebsd boxes do *not* have > the > problem, but that's because I have set > 'ChallengeResponseAuthentication no'. > I don't even remember why I set that on my freebsd boxes. I change very > few settings, but for some reason I decided to change that one. Yes, it seems so. Going through the source code and the openssh-unix-dev mail list, I see that it's indeed an issue that could affect a lot of machines. But it depends on the right (wrong) combination of factors which, unfortunately, FreeBSD has. Using the default ssh configuration you need to append the Konsole output -o NumberOfPasswordPrompts=1 option for being able to test this bug. My first attempts didn't had this. But I still can't replicate it on linux hosts. I can reproduce it on Mac's too. And it's as nasty as on FreeBSD. The problem is with the KbdInteractiveAuthentication option, which defaults to the same value of ChallengeResponseAuthentication which in turn has the "yes" default. If there are any forms of PAM authentication delays, they still apply. But that could perhaps be overcome with some kind of distributed attack, with many connections opened. Cheers, Giancarlo Razzolini Konsole output
Re: Alleged OpenSSH bug
Em 23-07-2015 16:43, Garance A Drosehn escreveu: > As noted in my message, I did actually test it on a variety of systems. You mentioned FreeBSD boxes and a Mac. That ain't a variety of systems. > I happened to avoid it on my systems, but that was more by luck than > any cleverness on my part. This says a lot about you. > > The original post wondered if this was some mis-timed April Fool's > joke. My reply was just to say that it's a real issue, although > many people won't see this issue due to the way sshd is configured > on their systems. You were condescending, admit it. Quoting you: "I'm also told that there is a patch for the oversight in OpenSSH's code" There was no oversight. There were people using the OpenSSH code in unintended ways. The OpenSSH portable is only provided by the OpenSSH project because there are developers that care for it. People should stop being lazy and use OpenSSH as close as upstream as possible and even better, with no portable "glue" code. You don't need PAM, specially if you're using PubKeyAuthentication. If you must use OpenSSH portable, at least bother enough to secure it. The patch wasn't provided because of a bug in OpenSSH code, it was provided because people are lazy, and wouldn't fix their own PAM configuration. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
Em 23-07-2015 18:10, Ted Unangst escreveu: > Come on. Calling it an oversight is not condescending. I think it's perfectly > reasonable to say it was an oversight. He did't say it was the hole of the > century. There's no need to be so defensive. Yep. Others also told me this off list. I already sorted things out with the OP. But, truth is, that this bug is being sold by others, including news sites, as "The BUG". It's hard to stay over the fence when things like this happen. Perhaps I need to drink less coffee and see what that thing called meditation is all about. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
Em 24-07-2015 14:27, Kevin Chadwick escreveu: > The guidance is to use pubkey or long passwords in which case you > should either have no problem or notice the cpu cycles if your an admin > worth any salt. There are tons of info regarding OpenSSH best practices. The link bellow [1] is one of them. I personally let my servers with only the state of the art, which currently is ed25519 for both PubKeys and HostKeys, chacha for cipher, curve25519 for kex and hmac-etm for mac. [1] https://wiki.mozilla.org/Security/Guidelines/OpenSSH
Re: Firewall question: is using a NIC with multiple jacks considered insecure?
Em 27-07-2015 09:13, Kimmo Paasiala escreveu: > It's next to impossible identify the make and > model of the NIC that holds an IP address With IPv6 and poor configuration, a remote attacker already have that information. MAC addresses reveal a lot of information about a NIC. Cheers, Giancarlo Razzolini
Re: ipv6 kernel pppoe + slaac problem
Em 27-07-2015 18:16, Stuart Henderson escreveu: > Can you try 6.9.1 from -current ports please? (I updated it recently > so packages might not be there yet). You can try using the wide-dhcp6 too. But, I couldn't make it work because my upstream router would delegate the prefix, but not route the packets to my OpenBSD firewall. So, some form of NDP proxying is required. Nothing in the base or in the ports can do that, AFAIK. I ended up deploying a bridge. I also have the same issue, the prefix delegation from my ISP is dynamic, not static so, every time my router gets restarted, I get a new prefix from it. If your prefix delegation solution doesn't account for it, you might need some form of monitoring (ifstated comes to mind), to reload both your dhcp and rtadvd. IIRC, OpenBSD isn't yet RFC 7084 ready (I have my doubts whether it even should be). One of the core things is, if the router lose global IPv6 connectivity, it MUST stop advertising itself as a IPv6 router. And rtadvd doesn't do that yet AFAIK. Truth is, most ISP's are ing up IPv6 deployment. Some of them are doing it for the money (charging more for something that should be default, as static PD). Others are doing it because of plain and simple lack of knowledge. Cheers, Giancarlo Razzolini
Re: OpenBSD machine was hacked
Em 28-07-2015 06:17, Wong Peter escreveu: > Dear All, > > Recently, I'm realized that my openbsd firewall router was not usable > anymore due to pf rules had changed by using carp and pfsync mechanism. > > Here is my prove. > > I'm tried to reinstall the whole machine and plugged in the modem LAN cable > to NIC card. All my written pf rules was flush and changed. This happen > even without internet connection(No IP address assign). > > I'm suspected this is did by my ISP. I'm believed my openbsd machine was > located same subnet with their machine. > > I'm even tried to disable carp protocol but my pf rules still get flushed > out. > How this can happen? > How to prevent it? > How my ISP can synchronize its pf rules to my machine without IP assign? > I'm suspect they achieved at Layer 2 by using mac spoofing/mac target to my > machine. > net.inet.carp.allow=0 > > Please help. Very urgent. > > > > > > You use a very controversial subject in order to draw attention in the hope that someone will help you. And not only you can't manage to give a shred of evidence to support your claim, as you can't even manage to provide enough information for some good soul on this list to help you. Come back when you sorted this out. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 25-07-2015 11:50, Stuart Henderson escreveu: > Actually that's fine, a point-to-point interface can be unnumbered, > or in the case of IPv6, it can just have a link-local address. In my case I don't have a ppp interface, my CPE talks to my OpenBSD firewall through normal LAN. > DHCPv6 PD would give you a /64 or (if allowed by the ISP) a larger > prefix to assign to interfaces as you choose. Normally you would > assign this to "internal" interface/s, but assuming the ISP allows > more than a /64, you *can* apply part of that delegation to the > PPP interface if you would like it to have a globally routable > address. This is one of my problems, my ISP would only give me a /64 prefix, not a /56 or other manageable size. I can ask a PD from the CPE, but the only prefix already is delegated to the CPE itself. So the CPE keeps asking me neighbor solicitation messages, and won't route the packets. Unless I use NDP proxying, I can't do normal routing. As I stated, I did a bridge. When I have some free time I'll visit the NDP proxy again. Perhaps I'll be able to port some of the existing solutions to OpenBSD. Cheers, Giancarlo Razzolini
Re: Maintaining CAs not in cert.pem
Em 30-07-2015 09:15, trondd escreveu: > I guess the meat of the question is "is certs.pem the only location for > CAs used by the system?" (ignoring application certificate stores, ie. > Firefox or java). Another meat could be, why you're using self-signed certificates? Given the plethora of options for getting free (valid) certificates. Cheers, Giancarlo Razzolini
Re: Maintaining CAs not in cert.pem
Em 30-07-2015 13:58, Kimmo Paasiala escreveu: > That depends on the use case of the certificate. Use of self-signed > certificate is no less secure than an "official" one as far as the > actual encryption on the transport layer goes. It's only a question if > the user trusts the authenticity of the self-signed certificate and > the issuer of certificate is prepared to educate his/her users what a > self-signed certificate is and why they should trust it. Yes, self-signed certs have their uses. VPN's come to mind. Custom CA's for intercepting, also. Since most people don't even care about tls warnings, they got their uses. But, as it is becoming clearer and clearer to the OP, you need to maintain it yourself, and not screw up. Cheers, Giancarlo Razzolini
Re: Maintaining CAs not in cert.pem
Em 31-07-2015 03:07, Peter Hessler escreveu: > this is a real problem for real people. Which was pretty much solved with PKP [0]. As I mentioned, custom CA's have their uses, but in the end, they are just one more thing waiting to bite you in the ass. You can pretend to have a decent OPSEC for a while, but in the end you CA private key will end up being on the same machine your certs are being used. With PKP you can disregard the CA completely, but your certificate will be recognized on pretty much every device. It's nice that the discussion spawned a change in the way how the certs.pem is handled on system upgrades, but moving it to examples is not a solution (shouldn't even be discussed ironically). The bottom line is, want your own CA, deal with it. [0] http://tools.ietf.org/html/rfc7469
Re: reply-to for blocked packets
Em 03-08-2015 05:23, Kapetanakis Giannis escreveu: > Is there a way to sort this out and route packets to the correct > interface? You can try to create "enforcing" rules. Create 2 rules in your outgoing interfaces that, when they detect a packet leaving a interface but it should be on the other, you force route-to rules (not reply-to) on them. Block rules with return do create states, but as soon as the packet is sent, they enter in TIME_WAIT status (as it should be). Do you really, really, need to return the packets? Perhaps in your case you can benefit from routing domains. Cheers, Giancarlo Razzolini
Re: reply-to for blocked packets
Em 04-08-2015 04:52, Kapetanakis Giannis escreveu: > I've already have rules for outgoing traffic that utilize route-to. > However this applies only for new packets generated from host itself. > It does not match on returns. Not necessarily true. You can filter on your outgoing interfaces as this: pass out on $ext_iface1 from ($ext2_iface) route-to ($ext_iface1 $ext1_gw) keep state pass out on $ext_iface2 from ($ext1_iface) route-to ($ext_iface1 $ext1_gw) keep state This will enforce that any rogue packets going out on the wrong if, gets routed to the right gw. Of course this is for natted packets, since I using the external interfaces ip addresses. For routed packets, you will need to write more specific rules. > > Dropping instead of return would definitely stop it. > Routing domains indeed seems they only solution in case I want returns. Not sure if they are the only solution, but it seems to be the easiest one to deploy, in your case. > if block rules with return do create a state, why do they not respect > the reply-to ? Now you got me. I would need to read the source to answer you, but I believe that reply-to ends up only working for pass rules, not block ones. Cheers, Giancarlo Razzolini
Re: Docker on OpenBSD?
Em 04-08-2015 12:59, openda...@hushmail.com escreveu: > Are there any efforts being made to port the FreeBSD Docker port to OpenBSD? Not that I know of, but I'm not a dev and might be wrong. I do follow @tech, and didn't saw anything docker related, ever since I'm on the list. My personal opinion is that OpenBSD shouldn't even get near docker. But hey, it's my opinion. > but it's the only way I can install Discourse >From what I read on their site, they use off the shelf software that might have a package/port on OpenBSD. You could succeed in installing it outside a docker. Unless their software is stupid and try to verify if you're inside a docker and refuses to run if not. Cheers, Giancarlo Razzolini
Re: Docker on OpenBSD?
Em 04-08-2015 13:50, Gregory Edigarov escreveu: > They just use RoR, and it definitely run on OpenBSD. Do you know what these docker ready images sound to me? Laziness. Truth is, we have an avalanche of developers that are empowered by these so called devops tools, puppet, chef, docker ready images, etc. But they grow accustomed with this so called readiness and easiness that they never bother to know what's under the hood. Heck, they don't even bother to know if the under the hood is secure. These tools certainly have their use on the development phase of a project. And puppet and friends certainly make the job of admins easier. The difference, as always, lies on who is using. You see the OP grow so fond of this easiness that he comes to the point of asking on this list (without even searching first) if OpenBSD will import the FreeBSD docker port, so that he can simply take a image and install something, that can, with some work and thinking, be installed on the metal. This is wrong. And is also part of the security problem. Cheers, Giancarlo Razzolini
Re: Docker on OpenBSD?
Em 04-08-2015 17:48, Etienne escreveu: > Couldn't agree more. And someone else writes it better than I do: > http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html I truly don't know which is worse: Developers pretending to be sysadmins or sysadmins (if you can call them that) being lazy. I bet that a lot of the good old fashioned admins got replaced by a new "devop" who can deploy everything really fast cutting every corner possible. And people still want it to be ported to OpenBSD. Cheers, Giancarlo Razzolini
