Re: TLS now supported on openbsd.org?
Em maio 10, 2016 9:07 Kamil Cholewiński escreveu: On Tue, 10 May 2016, Giancarlo Razzolini <grazzol...@gmail.com> wrote: This is of limited usefulness. All you need to do (as a mitm) is to block the connection on port 443, client will now automagically fall back to using 80 and plain text... It's even easier than filtering out STARTTLS for SMTP. Go google some, why opportunistic encryption is a bad idea. K. Limited? Sure. STARTTLS is a bad idea and I didn't meant that by any circumstance. Opportunistic encryption is a bad idea. As it is DNS, as it is DNSSEC, as it is TLS. But it is what he have. For now. Ironically, google does it, facebook does it, twitter does it, pretty much every freaking big site does it. Don't beat a dead horse anymore. As I said, all I cared about was the anon cvs page. Which now I can access over TLS, even if I have to guess it is accessible over TLS. Cheers, Giancarlo Razzolini
Re: TLS now supported on openbsd.org?
Em maio 10, 2016 1:29 Bob Beck escreveu: And statements like this - and people that think this is a good idea, are why I spoof DNS answers in bars and coffee shops, and why I don't read misc@. This is never a good idea, unless you want the connections intercepted and MITM'ed. I don't see the issue with this Bob. Of course it means the first access is the one with very high value. But as it is with HPKP, and as it is with SSH itself. I see that you guys are working on having openbsd included in HTTPS Everywhere and all. But it still leaves it up to the user. If you put HSTS on top of a one time redirect, the client will never again access the site using http. It is a concession. One that you don't seem keen to make. And, on a second thought, I only care for the anon csv page where you have the ssh host keys. The rest of the site can be left unencrypted. Until every UA is changed to first try TLS and *only then* fall back to clear text http, this kind of measure has its uses. Cheers, Giancarlo Razzolini
Re: TLS now supported on openbsd.org?
Em maio 9, 2016 18:39 Theo de Raadt escreveu: Giancarlo Razzolini <grazzol...@gmail.com> wrote: > It is really nice to finally see TLS on openbsd.org. How about redirecting > http to https? I dislike the idea. Let me be more clear, both of you. Those decisions will made by the people (Bob et all) who maintain the back end. They don't need your opinions. Go take your opinions and give them to your BANKS INSTEAD. Theo, I agree with you. After all, if you wanted our opinions, you would have take them a long time ago. I think it is nice you guys (finally) put TLS on the openbsd.org main site. Despite all its flaws, TLS do have valid use cases. An OS site is a perfect example. Also, as you putted, BANKS. Fortunately my country has a pretty decent banking system and they do follow all of the TLS best practices. At least the bank I use, do. OpenBSD's site eventually will catch up with the rest. It is a big win nevertheless. Cheers, Giancarlo Razzolini
Re: TLS now supported on openbsd.org?
Let's Encrypt uses 4096. I think lets encrypt uses by default 2048, not 4096. Also, 4096 might indeed cause trouble with some old software. I recall issues with mono and older java versions. It is really nice to finally see TLS on openbsd.org. How about redirecting http to https? Also, it seems STS isn't being used. I don't know if this is a testing phase, but it would be nice to have those nevertheless. Cheers, Giancarlo Razzolini
Re: Python requirements.
Em abril 25, 2016 4:12 Jay Patel escreveu: Hi Muhammad, I reinstalled everything but still same error. Is it platform error or python one? Thanks, Jay Jay, This is an issue with kombu. You need to update your celery installation. pip install -U celery should fix that. This happens because kombu is using an internal python function that got removed from 2.7.9 to 2.7.10, if I recall it correctly. I had this same issue recently. 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: 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: 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 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: 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: 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 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 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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<UP,POINTOPOINT,RUNNING,MULTICAST> 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: 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: 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: 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: 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: 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 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 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: 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: 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: 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 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: 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: 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: 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: 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: Making IPv6 NAT prefer privacy address
Em 24-09-2015 08:36, Stuart Henderson escreveu: > What is the purpose of IPv6? The main purpose that I see is "ability to > continue getting internet addresses after v4 runout". (If it had been left > at that and didn't change a bunch of other things at the same time, perhaps > more people would be using it already). This sure is the purpose now. Short term. But one of the main reasons the address space is so large, is for every connected device be accessible from every other. > > And, like it or not, the majority of network admins have learned their > trade in a post-NAT world, and are relying on things which are difficult or > impossible to do without that... Yes. I got that. But I prefer to learn to do things properly, even if it means it's more difficult. > So you're relying on your ISPs CPE for network addressing and it doesn't > have a way to add a static route? It seems like you would have the same > problem with v4, doesn't it? I can add a static route, yes. And it answers to IA_PD requests, and also IA_NA. So I've managed to get it working for my internal machines. The only issue is that the CPE wont try to route the prefix it delegated to me. What it does instead, is to keep asking, using NDP, who has the address. Hence the need for a NDP proxy. > > Can you terminate the session on the OpenBSD box instead? If you mean a pppoe or other way to get the IPv6 directly on the OpenBSD box, then no. My CPE is only routed, unfortunately. But this discussion gave me the idea of making a bridge for my dmz and using ULA with nat on my internal networks, that don't need much external connectivity. This also solve my problem of having only one /64 prefix. Cheers, Giancarlo Razzolini
Re: Making IPv6 NAT prefer privacy address
Em 24-09-2015 16:51, Devin Reade escreveu: > Another consideration that has entered the picture since that idea came out, > though, is how much easier it will be in the non-NAT world for advertisers or > whomever to track individuals' behaviour. Not everyone likes that. Hence privacy addresses extensions and non-temporary address associations. In hindsight, it was a poor choice to make IPv6 addresses based on MAC addresses, given the advancements on pseudo-random number generation. The fact is, that OpenBSD and the other OS's should prefer privacy address for everything (even pf itself). This already happens on some linux configurations, where you have a semi stable privacy address any given time on a interface, and only that kind of address, not the MAC address based form. Anyway, this ULA natted will sure have it's uses, specially now in the beginning of the IPv4 to IPv6 migration. What Stuart mentioned that most of network administrators where born in a world already needing nat, has a big impact on this. Still it's not substitute to proper implementation and might even slow IPv6 deployment for a while. But with the advent of more devices in the IPv6 world, the so called internet of things, nat will have a performance hit on that, so it will eventually fade away, hopefully. Cheers, Giancarlo Razzolini
Re: Making IPv6 NAT prefer privacy address
Em 23-09-2015 04:40, Stuart Henderson escreveu: > Saves messing about with DHCPv6-PD I see. So you translate from what exactly? Wouldn't it be better to use af-to instead of nat? But I can relate to that, given that my CPE will give me a PD, but won't route packets back because it thinks the prefix is reachable using NDP. Hence the need for a proxy, which OpenBSD currently doesn't have. Cheers, Giancarlo Razzolini
Re: Making IPv6 NAT prefer privacy address
Em 23-09-2015 11:49, Stuart Henderson escreveu: > Exactly. It also makes it easier to handle multiple ISPs for load-balancing > or failover, which IPv6 handles poorly (short of using BGP). Wouldn't multipath and properly constructed ifstated scripts be better in this case? Like reloading dhcpv6 servers, rtadvd, and anchors, etc. > > Also it's good for winding up IPv6 purists :-) Wound up me. :-) Cheers, Giancarlo Razzolini
Re: Making IPv6 NAT prefer privacy address
Em 23-09-2015 11:16, Marios Makassikis escreveu: > Rather than announcing the prefix obtained via DHCPv6-PD you can pick a prefix > from fd00::/8 and announce that on your network. > It is the equivalent to RFC1918 addresses, except it is for IPv6. Figured it. These are ULA, right? > Therefore, it is > not routable and you need to perform NAT on it. The global address is the one > the router obtained via static configuration/SLAAC/DHCPv6, which will then be > used by all your clients. It kind of defeats the purpose of IPv6, doesn't it? > Your CPE will see only the OpenBSD router's address so it should work. I ended up setting up a bridge for that. It's harder to filter on them though. I plan to port some NDP proxy to OpenBSD, but all of the candidates looked very cumbersome to my taste. I'll have eventually to do it, unless someone else beat me to it. 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 > Nat on IPv6? Why? Also, if I'm not mistaken, if your card has a privacy address, it will be the one used, but for connections originated from the firewall itself. I'm not aware of any rule you could make that would get you only privacy address. I didn't read the code, but ($if_ext) would give you the first address, IIRC. Which, in your case, is not the privacy address. Also, you could check if your CPE (router) answer to DHCPv6 requests. If so, and if it follows RFC 7084, you could ask a IA_NA from it, and you'd get an address which is not the privacy address, but also is not based on your MAC address. Cheers, Giancarlo Razzolini
Re: Can't ping IPv6
Em 16-09-2015 15:01, Mark Carroll escreveu: > Maybe there's a better way to specify default routes, but that one sure > seems to work. My CPE sometimes won't give me a default route through SLAAC. I'm not sure you're using it, but I presume you are. The only way I have to kind of assure a default route is using a DHCPv6 client. Even then, if your CPE follows RFC 7084, you might end up with a situation where your router doesn't have global IPv6 connectivity and will stop advertising itself as a default route. I'm yet to find a CPE that is completely RFC 7084 compliant. Luckily enough, many CPE responds to this address as your default route (fe80::1). If it didn't, you would have a lot of problems. Cheers, Giancarlo Razzolini
Re: Incoming packets arrives on an interface and outgoing packets takes another interface
Em 09-09-2015 07:11, jean-yves boisiaud escreveu: > I resolved the problem with the reply-to pf directive. If you enable multipath and add the default gateways, you can use a reply-to for the interface only, not needing to pass the gateway address. This solves both LAN connectivity and internet connectivity going to the right interfaces. Cheers, Giancarlo Razzolini
Re: pf vs mp
Em 01-09-2015 22:40, Quartz escreveu: > And when I say "fanless" I mean *completely* fanless, there won't even > be any fans in the chassis or power supply, so low TDP is super > important, and that ends up meaning low performance. It's not clear to > me yet how close to the margin we'll end up being. So now that you are being less vague, then we can start pointing you in the right direction. I've built some OpenBSD firewalls using this kind of hardware, completely fanless using CF for storage. I think you are focusing on the thing that will probably give you less problems, the CPU. These kind of systems tend to have problems with a lot of things, *before* you ever get to the CPU. Don't expect top notch performance from them, specially under heavy loads. That being said, there are lots of options, but I believe that one of the most recommended here on this list is soekris. But there are other options too. P.s.: Talking about this kind of embedded system, you'll most likely end up with a single core one. Pay attention to the RAM speed and bus speed too. Cheers, Giancarlo Razzolini
Re: pf vs mp
Em 01-09-2015 22:26, Quartz escreveu: > OK, so after more info you're switching to the mp side? If that's true > then all the latest recommendations from this afternoon forwards are > in favor of mp. Re-read all my emails. Just because I said I use single core, doesn't mean I switched sides. As I said, you should try and see. But, in general, you will benefit from mp. Yes, I'm being vague, as you were. P.s.: Don't use anything you read on calomel.org. Want to learn pf, read the manual or buy the book of pf. Cheers, Giancarlo Razzolini
Re: pf vs mp
Em 01-09-2015 14:21, Quartz escreveu: > Also, does a local DNS resolver really consume that much cpu that it > would see any notable effect from having another core? I thought that > was more a RAM thing. If it will be the resolver for your entire internal LAN (and the firewall itself), then it will consume more RAM and CPU than pf. Having more of both in this case is better. Again, each case is different and you should really try and see. Also, all of this might become somewhat irrelevant when (if) the mp pf patch enters base. Cheers, Giancarlo Razzolini
Re: pf vs mp
Em 01-09-2015 14:18, Quartz escreveu: > It's not actually a small office, that's just the best analogy I could > think of. My home server many times ends up having more traffic to deal with than my small office. So an analogy not always plays in our favour. > Well... that's kind of the same thing though, isn't it? > Hypothetically, if I have a single core with a speed of "1" vs say a > dual core where each core has a speed of ".75", I'm getting the > impression that the dual will end up being likely slower, given that > pf is currently single threaded and the other stuff isn't accounting > for much overhead. Even though the total computational power of the > dual core would be 50% more, that extra power is effectively unusable. Not exactly. In your case, you are using only a dhcp server and a dns server, along with pf. I'm confident that in most cases you will perform better having the single core at 100% speed than two cores at 75% speed. But don't expect consistent performance through peaks and heavy loads. Again, it all depends on your use case. As other people mentioned, if you are that concerned about pf performance (you shouldn't be), them run only pf, with no other daemons or process with it. > Again, it's not actually an office, and it won't need to scale, at > least not by much. If you expect consistent traffic, it perhaps would be better to actually measure it, and only then decide. pflow(4) and nfsen come to mind. symon is another good candidate. With that, you can deploy only the amount of hardware needed. Cheers, Giancarlo Razzolini
Re: pf vs mp
Em 01-09-2015 16:06, Quartz escreveu: > I think some information is getting lost here. I'm not comparing > single vs multi core operation in a purely mathematical sense on > identical hardware. I'm trying to decide between a setup that uses a > relatively fast single core vs a setup that uses slower multi cores. > In aggregate the multiple cores have more processing power than the > fast single, but in isolation are notably slower. The workload is > mainly pf, and given that pf is currently single threaded, I'm trying > to figure out if the other stuff on the box causes enough overhead > that going with slower multi cores will end up being faster in the end > or not. The short answer is, unless you can guarantee that pf will have its own core and no other process will race against it (you can't), then go for the mp. Truth is, that pf is so fast, that the bottleneck almost never is it. If you ever reach a point where pf is giving you trouble, than I'm guessing you're a backbone with tons of GB/s of traffic. And even then it can adjusted to not give you trouble. Clearer now? Cheers, Giancarlo Razzolini
Re: pf vs mp
Em 01-09-2015 10:21, Quartz escreveu: > > Sorry that was unclear wording on my part. This machine is 95% pf > routing with some dhcp/dns on the side- AFAIK those won't account for > much so if there's nothing else there wouldn't really be a benefit > going multicore, right? Dhcp, no. DNS, yes. As I mentioned, I have a small home server which is single core that has a lot more daemons running and it doesn't break a sweat. A small office isn't that much different from a home server. I see, that more than really wanting to know if you'd be ok with mp, you're seeking validation to go through with a single core. If you're only using pf, dhcpd and dns server, it will work. But don't expect it to scale too well if your small office becomes a medium sized office. Cheers, Giancarlo Razzolini
Re: pf vs mp
Em 31-08-2015 23:38, Quartz escreveu: > Quick question: I need to make a decision between a faster single core > and a slower multicore. The faq currently states that pf gets no > improvement from mp. Is this still correct/current information? Not anymore. There has been some work on mp support, although I don't think it made 5.8. Nor that it will make 5.9, for that matter. > For an OpenBSD machine acting as a gateway/firewall/router with a > handful of related tasks (pf, dhcp server, etc) would mp yield anything? Of course, yes. Just because PF doesn't get any benefits (yet) from MP, it doesn't mean these other programs won't. That being said, you'll probably be ok with a single core. But, if you machine have no problems with it, using MP won't hurt, and will definitely improve your performance. Cheers, Giancarlo Razzolini
Swap block device changed
Hi All, I've recently got a warning on my insecurity script that my swap block device changed: brw-r- 1 root operator 4, 1 May 9 22:56:18 2015 /dev/sd0b brw-r- 1 root operator 4, 1 Aug 22 00:02:14 2015 /dev/sd0b I searched the lists and only come up with this: http://mailman.theapt.org/pipermail/openbsd-newbies/2007-December/003807.html I should mention that this machine is virtualized with qemu-kvm on a Linux host. On this day, I had some issues with the host machine were it would run out of memory, and the machine did lock up at least two times, and I had to hard reset it. These events had nothing to do with the OpenBSD machine per se. Since the OpenBSD machine is using the virtio ballooned memory, I guess it might have something with it, but I fail to see exactly what. Anyone got any clues? Cheers, Giancarlo Razzolini
Re: Openbsd 5.7: IPv6 autoconf not working
Em 18-08-2015 23:34, Alexandre Westfahl escreveu:
6c00 0020 3aff fe80
0001 ff02
0001 8600 fa6d 40c0 0708
0101 fc48 efc3 41fe
0501 05dc
This seems odd to me. It looks like the packet is mangled. I can see the
multicast address, the link-local address. But I don't see any valid
global prefixes. Check your card and cables?
I have on my settings sheet the DNS and the prefix I'm delegated.
You know if this router advertises the DNS through SLAAC? It doesn't
seem to be the case.
I tried wide dhcpv6 and it works but I would like if possible to go without
it.
The modem brand is Huawei but i don't have the model here.
I have a huawei here, and it works both through SLAAC and DHCPv6. But,
there is a catch. My ISP can remotely configure which LAN ports works
and which doesn't. In mine, only the 3 first ethernet ports work, the
remaining doesn't. Check if you're using the first port, try changing
them. And ask your provider to enable the other ports if it doesn't.
Cheers,
Giancarlo Razzolini
Re: redirect nor vpn (as I know it) solves this problem
Em 19-08-2015 09:27, Sonic escreveu: I'm guessing you mean this example (?). == With an additional NAT rule on the internal interface, the lacking source address translation described above can be achieved. pass in on $int_if proto tcp from $int_net to $ext_if port 80 \ rdr-to $server pass out on $int_if proto tcp to $server port 80 \ received-on $int_if nat-to $int_if == Yes, this is what he meant. I've tried a few different twists on it but without success so far. As I'm coming in from the outside and need to appear that I'm inside. As it's written This construct is rather complex. Just to be clear, your setup is something like this?: |GW | - machine - |OpenBSD| - Internet So, when your connect using OpenBSD as the router, the packets get to the machine, but since the machine doesn't have a direct route to your machine, it replies to its GW which is not from where the packet came. I just want to confirm if this is your setup. As others already mentioned, you have some options. If you don't care about UDP, you can use http://www.openbsd.org/faq/pf/rdr.html#tcpproxy. You can have a L2 VPN to your OpenBSD machine, so that you would effectively be inside the same network the machine is. You problem isn't unsolvable. Cheers, Giancarlo Razzolini
Re: Multiple VLANs PF rules
Em 19-08-2015 16:50, Dot Yet escreveu: So, can one of you help me understand how I can write the pf rules to allow communication between em1 and vlan 12/15 or communication between vlan 12 and vlan 15 etc. If all machines have OpenBSD as their gateway, simple pass rules should do. No need for nat nor anything. Now, if some of these networks do not have the OpenBSD machine as its gateway, but the OpenBSD machine has access to the network, then you will need nat. You can have other things such as routes being passed using DHCP, RIP (or other internal routing protocol), etc. Assuming the OpenBSD machine can communicate with every network and every machine on it, you have plenty of options. Cheers, Giancarlo Razzolini
Re: Multiple VLANs PF rules
Em 19-08-2015 18:25, Dot Yet escreveu: The machines are all pointing to the openbsd server as their default gateway. Nice. the nat is only being used to get out to the internet (em0). internal subnets do not use nat to communicate. So you have the setup I outlined. I don't want to use any routing protocol for this, but just simple firewall rules to allow or deny the traffic. You won't need to. The pf man pages are great, and they provide lots of examples. Also, if you take some time to learn BNF, it will surely help you. Cheers, Giancarlo Razzolini
Re: DHCPv6 server - send_packet6: Network is unreachable
Em 18-08-2015 04:30, Claus Lensbøl escreveu: I tried setting a custom link-local address, didn't help. The weird thing is that I have tested a similar set up on a 5.3 router that has no vlan interfaces and a much less strict pf than this one, and that just worked out of the box. It might be obvious, but you are logging blocked rules right? You ruleset might indeed be blocking things, which is why you need to log, and also, use tcpdump. I'm starting to think you have a problem with your vlan configuration. I tried a: pass on vlan710 from fe80::/10 , but that didn't help either. The packets appear on the VLAN? It's a bit problematic disabling pf as the site is running v4 in production. No need, use tcpdump. Any other suggestions? Beside debugging it more and upgrading your OpenBSD installation, none. I don't think IPv6 is the problem though. Remember, SLAAC is ICMPv6 only and DHCPv6 is UDP based, just as DHCPv4 is. So your ruleset must accommodate for that. Cheers, Giancarlo Razzolini
Re: Openbsd 5.7: IPv6 autoconf not working
Em 17-08-2015 22:41, Alexandre Westfahl escreveu: I activated debug but don't get any outputâ anywhere. Since I couldn't find anything, I tried a global grep but without success (cat /var/log/* |grep inet6 and ipv6). Kernel messages will appear on /var/log/messages, IIRC. And on dmesg and on the console. So I guess that, if there was any, you'd see them. Since my tcpdump result are not changed, it means I have to install dhcpv6client? I need the wide one or another one? Can you try to capture the whole packet? Try setting a snaplen of 1500. I believe it is too early to give up on SLAAC. But you might need DHCPv6 anyway, if your router don't advertise the dns servers. See if you ain't getting malformed packets from the router, or if it's advertising, but with no actual prefixes/routes. Per RFC 7084 [0], a router should stop advertising when it doesn't have global IPv6 connectivity. But, not every manufacturer is fond of RFC's. Cheers, Giancarlo Razzolini [0] https://tools.ietf.org/html/rfc7084
Re: DHCPv6 server - send_packet6: Network is unreachable
Em 17-08-2015 08:54, Claus Lensbøl escreveu: pass quick inet6 proto udp from 2a02:188:5002::/48 to __automatic_e513959b_6 port = 547 pass quick on lo0 inet6 proto udp from 2a02:188:5002::/48 to fe80::1 port = 547 pass quick on bge0 inet6 proto udp from 2a02:188:5002::/48 to fe80::8634:97ff:fe11:c494 port = 547 pass quick inet6 proto tcp from 2a02:188:5002::/48 to __automatic_e513959b_5 port = 547 flags S/SA pass quick on lo0 inet6 proto tcp from 2a02:188:5002::/48 to fe80::1 port = 547 flags S/SA From these rules I see you're filtering on global addresses. But your machines doesn't have (yet) global addresses, unless they are getting the address through SLAAC and only is consulting the DHCPv6 server for dns and prefix delegation information. Either way, can you reach your clients through link-local addresses? More specifically, try pinging all hosts using the multicast address: ping6 fe02::1%IF See if you're getting replies, and if so, from the desired machines. The next step would be trying to communicate with then, using their link-local address and some tool like netcat. tcpdump also is your friend here. That way you can be sure you have network level communication with them. You can also try to disable PF and turn on ndp debugging, net.inet6.icmp6.nd6_debug. Cheers, Giancarlo Razzolini
Re: DHCPv6 server - send_packet6: Network is unreachable
Em 17-08-2015 16:22, Claus Lensbøl escreveu: Do you have any good ideas for rules to compensate for this? Allow the entire link-local range? fe80::/10? Link-local aren't routable (at least shouldn't be) and the machines can talk to each other, with no firewall intervention. So the impact should be minimal, if you do so only on LAN interfaces. Cheers, Giancarlo Razzolini
Re: DHCPv6 server - send_packet6: Network is unreachable
Em 17-08-2015 17:55, Claus Lensbøl escreveu: all the vlan interfaces has the same link-local address. Each vlan interface has a scope though, which I do not know how works. Not sure either. But you could try forcing each VLAN to have a different link-local address and see if it helps. Giving out addresses with rtadvd is working fine, it's only the dhcpv6 daemon that cannot give out addresses. I guess it's not working because it does not handle VLAN properly, so it doesn't know where to return the packets to. I might be wrong, but it seems to be the case. I've tried both with a manual dhclient -6 (on a linux client) and with dispatch from rtadvd. Both ends up with the dhcpv6 service dropping the send_packet6: Network is unreachable error. I suggest you also try upgrading your OpenBSD and packages. There have been some IPv6 changes between 5.6 and 5.7 and even more with -current. So, it might be worth. Cheers, Giancarlo Razzolini
Re: DHCPv6 server - send_packet6: Network is unreachable
Em 17-08-2015 17:05, Claus Lensbøl escreveu: Ok, I'll try it out tomorrow and return with results. Thank you for now. I was re-reading your e-mail and the following come to my attention: # ping6 fe02::1%vlan710 ping6: no address associated with name Do you have a link-local address on that vlan interface? If not, then it might not be a firewall problem, after all. Also, when I said for you to allow the entire link-local range, I meant to allow then to perform router solicitation and DHCPv6 requests. Do not allow everything from link-local. Also, you can enforce a boundary by dropping NDP messages (rtsol, rtadvd, neighrsol, etc) that do not have a hop limit of 255. See [0]. By the way, it is equally important, specially for machines that have IPv6 global addresses, that they also have a firewall enabled. Remember, IPv6, by default, do not have edges anymore. So, unless told otherwise, your OpenBSD firewall will happily route any incoming packets directly to their intended destination. Keep that in mind when writing your ruleset. Cheers, Giancarlo Razzolini [0] https://tools.ietf.org/html/rfc4861
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 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
Re: Docker on OpenBSD?
Em 04-08-2015 18:28, openda...@hushmail.com escreveu: a) Discourse is not a conventional Rails app. It has been abstracted to the point of insanity and will require you to make a ton of modifications and disable a ton of stuff if you decide to go that route, Kind figured. To me, any system that need to abstract how it's even deployed, is not a good system. b) if you don't use their official Docker image, the user community will simply refuse to help you over at http://meta.discourse.org. What help? It's a docker container, ain't it? It will never give you problems. ;-) p.s.: I've recently installed gitlab from source and it's also an rails app. But they have a very good documentation on how to do it, and you can understand most of what is happening. Even though they are always advising you to use their Omnibus package.
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: 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: 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: 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: 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: 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: 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: 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 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 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 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 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: 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 gw_cnmac1), (cnmac2
gw_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: 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 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 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 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
