PF and interface changing IP
Hi there, I have a pppoe0 interface setup like this (hostname.pppoe0): inet 0.0.0.0 255.255.255.255 NONE \ pppoedev re0 \ authproto pap \ authname 'myuser' \ authkey 'mypass' up dest 0.0.0.1 !/sbin/route add default 0.0.0.1 !/sbin/pfctl -f /etc/pf.conf !/etc/rc.d/isc_named restart !/etc/rc.d/aiccu restart Then I have setup PF to allow incoming ssh traffic. Here is my rule: pass in on pppoe0 inet proto tcp to pppoe0 port ssh keep state The interface has a dynamic IP. I was relying on the "!/sbin/pfctl -f /etc/pf.conf" rule to reload my PF when the IP changes but, apparently, it is not working as expected: it looks like the interface can change its IP without being restarted, so PF never gets reloaded and keeps using the old IP. I am now thinking of placing a cron job that just reloads PF once in a while. Is there a cleaner way to reload PF when the IP changes? Or maybe even a better way to write the rule so that it auto-updates without the need to reload PF at all? Thank you Gabriele Tozzi -- GPG Key Fingerprint: DAD1 E3E3 C3E9 36FB C570 F405 9B5F 7108 A1D0 2FFF
Re: PF and interface changing IP
On Thu, May 12, 2016 at 09:36:35AM +0200, Gabriele Tozzi wrote: > Hi there, > > I have a pppoe0 interface setup like this (hostname.pppoe0): > > inet 0.0.0.0 255.255.255.255 NONE \ > pppoedev re0 \ > authproto pap \ > authname 'myuser' \ > authkey 'mypass' up > dest 0.0.0.1 > !/sbin/route add default 0.0.0.1 > !/sbin/pfctl -f /etc/pf.conf > !/etc/rc.d/isc_named restart > !/etc/rc.d/aiccu restart > > > Then I have setup PF to allow incoming ssh traffic. Here is my rule: > > pass in on pppoe0 inet proto tcp to pppoe0 port ssh keep state > > > The interface has a dynamic IP. I was relying on the "!/sbin/pfctl -f > /etc/pf.conf" rule to reload my PF when the IP changes but, apparently, > it is not working as expected: it looks like the interface can change > its IP without being restarted, so PF never gets reloaded and keeps > using the old IP. > > I am now thinking of placing a cron job that just reloads PF once in a > while. Is there a cleaner way to reload PF when the IP changes? Or maybe > even a better way to write the rule so that it auto-updates without the > need to reload PF at all? You can use interface groups, 'egress' or 'ppp' ? You can also hack your setup to label a router and use 'route '. j.
Re: PF and interface changing IP
>From the pf.conf man page: "Surrounding the interface name (and optional modifiers) in parentheses changes this behaviour. When the interface name is surrounded by parentheses, the rule is automatically updated whenever the interface changes its address. The ruleset does not need to be reloaded. This is especially useful with NAT." Read it all, a few times and whenever is necessary.
Re: PF and interface changing IP
pass in on pppoe0 inet proto tcp to (pppoe0) port ssh keep state Von meinem Samsung Gerät gesendet. Ursprüngliche Nachricht Von: Gabriele Tozzi Datum: 12.05.2016 09:45 (GMT+01:00) An: misc@openbsd.org Betreff: PF and interface changing IP
Re: malloc.conf on BeagleBone Black
On May 10 18:45:49, h...@stare.cz wrote: > > > > > malloc() warning: unknown char in MALLOC_OPTIONS > > > > if it's only some programs, then it's because those are older programs. > > Yes they are. I will get back after they recompile. Thanks. Indeed, after recompiling the ports (it was only port binaries that complained), the warning disappeared. Thank you Jan
Re: PF and interface changing IP
On 12 May 2016, Gabriele Tozzi wrote: (snip) > Then I have setup PF to allow incoming ssh traffic. Here is my rule: > > pass in on pppoe0 inet proto tcp to pppoe0 port ssh keep state > > > The interface has a dynamic IP. I was relying on the "!/sbin/pfctl -f > /etc/pf.conf" rule to reload my PF when the IP changes but, apparently, > it is not working as expected: it looks like the interface can change > its IP without being restarted, so PF never gets reloaded and keeps > using the old IP. (snip) Does it start to work okay if you put the pppoe0 in parentheses? http://www.openbsd.org/faq/pf/filter.html has, ] The name of a network interface or group in parentheses ( ). This ] tells PF to update the rule if the IP address(es) on the named ] interface change. -- Mark
Re: light browsers
dillo
Re: httpd - Multiple index files?
On Thu, May 12, 2016 at 12:04:50AM +, Romain wrote: > Is it possible to supply multiple index files to the directory index > directive? I mean, I would like to write something like that in > httpd.conf: > >directory index "index.html" "index.php" > > which would mean that, if the directory contains "index.html", then > the server should serve it first, if not, then try "index.php", > otherwise the standard error. Not that I'm aware of. Anyway: Such logic should be part of your application, not the web server since it would just add unnecessary and ambiguos complexity to the latter. > Or should I do it in another way? You could try something like this: > Thanks. > Best, > Romain Regards. Erling
Re: PF and interface changing IP
Thank you for all your answers. I did not know about the "new" parentheses feature. Solved :) Gabriele Tozzi -- GPG Key Fingerprint: DAD1 E3E3 C3E9 36FB C570 F405 9B5F 7108 A1D0 2FFF
Re: httpd - Multiple index files?
Allright. Thanks for your answer. On Thu, 12 May 2016 11:40:10 +0200 Erling Westenvik wrote: On Thu, May 12, 2016 at 12:04:50AM +, Romain wrote: > Is it possible to supply multiple index files to the directory index > directive? I mean, I would like to write something like that in > httpd.conf: > >directory index "index.html" "index.php" > > which would mean that, if the directory contains "index.html", then > the server should serve it first, if not, then try "index.php", > otherwise the standard error. Not that I'm aware of. Anyway: Such logic should be part of your application, not the web server since it would just add unnecessary and ambiguos complexity to the latter. > Or should I do it in another way? You could try something like this: > Thanks. > Best, > Romain Regards. Erling
Re: httpd - Multiple index files?
On Thu, May 12, 2016 at 10:18:09AM +, Romain wrote: > Allright. > Thanks for your answer. Have a look at this thread: https://github.com/reyk/httpd/issues/27 And my example would probably be better this way: > On Thu, 12 May 2016 11:40:10 +0200 > Erling Westenvik wrote: > > On Thu, May 12, 2016 at 12:04:50AM +, Romain wrote: > > Is it possible to supply multiple index files to the directory index > > directive? I mean, I would like to write something like that in > > httpd.conf: > > > >directory index "index.html" "index.php" > > > > which would mean that, if the directory contains "index.html", then > > the server should serve it first, if not, then try "index.php", > > otherwise the standard error. > > Not that I'm aware of. Anyway: Such logic should be part of your > application, not the web server since it would just add unnecessary and > ambiguos complexity to the latter. > > > Or should I do it in another way? > > You could try something like this: > > if (basename($_SERVER["PHP_SELF"]) == "index.php") { >header("Location: ".$_SERVER["REQUEST_URI"]."index.html"); >} > ?> > > > Thanks. > > Best, > > Romain > > Regards. > > Erling
Re: Swift?
On Wed, May 11, 2016 at 07:30:42PM -0400, Devin Ceartas wrote: > Can you run Swift on OpenBSD? > > > devin Which one? This:https://swift.org Or that: http://swift-lang.org/main/ rru
Re: light browsers
> dillo is in ports www/dillo - a fast and light graphical web browser (no JS) [http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/www/dillo/pkg/DESCR] "Dillo is a multi-platform graphical web browser known for its speed and small size. It is written in C and C++ and based on FLTK." [http://www.dillo.org/] Very useful, replaces heavy Mozilla and all other huge monstrosities.
Re: light browsers
On 12.05.2016 00:26, 3sad68+aivzh013i5...@guerrillamail.com wrote: Hi, did anyone try Midori or other light browsers with good results ? Sent using GuerrillaMail.com Block or report abuse: https://www.guerrillamail.com/abuse/?a=TEhnBi0PU7Ebih2wvnENdQ%3D%3D Midori works fine. But if your definition of "light" is "consumes little resources" then I would recommend to use one of the browsers with a text interface: - w3m - lynx - links Cheers, Bruno
Re: light browsers
Hi, On Wed, May 11, 2016 at 7:26 PM, <3sad68+aivzh013i5...@guerrillamail.com> wrote: > Hi, > > did anyone try Midori or other light browsers with good results ? I've been using www/luakit for a long time on a thinkpad x40/i386. It is running fast and works just fine. html5 support was fixed in -current [1] a few days ago by me and abieber@ and it works like a charm, so you may to watch videos on youtube without effort... If you are looking either that suckless and functional browser, luakit is over there. [1] - http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/luakit/Makefile // gsoares
Re: Swift?
I was thinking of the Apple sponsored projects which is now supposedly open source & usable server side. I've done Objective-C in the past but have not played with Swift yet myself; if it were available I might play with that amongst all the other languages and frameworks that I am using on projects. No big deal, I'm not sure if it's a particularly good fit or not, just like to play with things. devin -- contact info: http://nacredata.com/devin > On May 11, 2016, at 23:53, Einfach Jemand wrote: > >> On Wed, May 11, 2016 at 07:30:42PM -0400, Devin Ceartas wrote: >> Can you run Swift on OpenBSD? >> >> >> devin > > Which one? > This:https://swift.org > Or that: http://swift-lang.org/main/ > > rru
Re: light browsers
Le Wednesday 11 May 2016 à 10:26:03PM, 3sad68+aivzh013i5...@guerrillamail.com a écrit : > Hi, > > did anyone try Midori or other light browsers with good results ? You might want to give a try to xombrero. It's webkit based and was "Built with security in mind" [0] When in "whitelist" mode, it provides a fine grained, per-domain control over cookies and JS activation and is highly configurable through a well documented conf file (sane vim-like keybindings and mouse control if needed). I use it everyday, it's ok for general purpose even though some fancy website design may appear broken from time to time. [0] https://opensource.conformal.com/wiki/xombrero
Re: light browsers
sogal writes: > Le Wednesday 11 May 2016 à 10:26:03PM, 3sad68+aivzh013i5...@guerrillamail.com > a écrit : >> Hi, >> >> did anyone try Midori or other light browsers with good results ? > > You might want to give a try to xombrero. > It's webkit based and was "Built with security in mind" [0] Basically anything that is using webkit is going to have issues: https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ This means, xombrero, luakit, probably all the others that aren't firefox and chromium. > > When in "whitelist" mode, it provides a fine grained, per-domain control > over cookies and JS activation and is highly configurable through a > well documented conf file (sane vim-like keybindings and mouse control > if needed). > > I use it everyday, it's ok for general purpose even though some fancy > website design may appear broken from time to time. > > [0] https://opensource.conformal.com/wiki/xombrero
Re: httpd - Multiple index files?
On 2016-05-12, Erling Westenvik wrote: > Not that I'm aware of. Anyway: Such logic should be part of your > application, not the web server since it would just add unnecessary and > ambiguos complexity to the latter. > >> Or should I do it in another way? > > You could try something like this: > >if (basename($_SERVER["PHP_SELF"]) == "index.php") { >header("Location: ".$_SERVER["REQUEST_URI"]."index.html"); >} > ?> This is quite a common requirement, using PHP for this seems quite overkill...
Re: light browsers
Le Thursday 12 May 2016 à 09:52:56AM, Aaron Bieber a écrit : > > sogal writes: > > > Le Wednesday 11 May 2016 à 10:26:03PM, > > 3sad68+aivzh013i5...@guerrillamail.com a écrit : > >> Hi, > >> > >> did anyone try Midori or other light browsers with good results ? > > > > You might want to give a try to xombrero. > > It's webkit based and was "Built with security in mind" [0] > > Basically anything that is using webkit is going to have issues: > https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ > > This means, xombrero, luakit, probably all the others that aren't > firefox and chromium. Thanks for the interesting link. The xombrero "security" features lie in the default settings and the possibility to harden them regarding to privacy issues. But indeed, it seems that every single Webkit(Gtk) web browser is broken which leaves us with very few choice. Firefox used to be nice, but I don't like the way it goes with embedded crap such as Hello or even worse, the Pocket thing. Chromium is Google related, not always for the best. [0] IMO both of them are heavy and need a lot of add-ons to be usable. [0] http://arstechnica.com/security/2015/06/not-ok-google-chromium-voice-extension-pulled-after-spying-concerns/
Balanced and failover IPSEC
Hello, this is my first post on OpenBSD, so do not riddle me, please... I have one infrastructure with one tunnel IPSEC. This works ok, but I think I can duplicate the transfers. My topology is like this: * One ADSL 20Mb on Site A * Two ADSL 10Mb on Site B * Consists on one OpenBSD by site, attached the router directly I need share Network A with Network B with ipsec like now, but balanced/failovered. I search solutions and found 3 methods, but I'm not sure which use and this seems a little complicated: * CARP (I haven't two server by site) * PF (with ipsec i'm lost) * ifstated (I dont know nothing of this) I will send my topology graphically on attachment (it will read with system or fixed font). Thanks very much and regards. #20.0.0.0 #--- ## ##### 10Mb |DSL|\ ## ## #--- | ## #####/ | ## ## #### 20Mb## /|.2 ## --- .2 --- .1 ##--/--- |BSD|---|DSL|# INET # |BSD|--- --- --- ##--\--- \ | ## \|.2| | 10.0.0.0 #\ | --- --- #--- | NET NET # 10Mb |DSL|/ --- --- #---101.0.0.0 100.0.0.0 #21.0.0.0
Re: PF and interface changing IP
Am 12.05.2016 11:52 schrieb Gabriele Tozzi: I did not know about the "new" parentheses feature. It was brand-new with the 3.2 release :-) -- pb
Re: TLS now supported on openbsd.org?
> On 2016-05-10, Kevin Chadwick wrote: > >> > Also, after you generate and sign the certificate, you don't have > >> > to keep the script. > >> > >> Validity on the letsencrypt CA is 90 days max. (Partly to restrict > >> usefulness of a bad cert because they don't do CRLs, which are pretty > >> much useless anyway, and partly to encourage users to automate). > > > > Ugghhh, I was fearing that their automate and security mantra might > > clash, but they don't seem to mention it up front. 365 days already > > annoys me especially as I intend to use OpenSSH for anything > > particularly important and cryptanalysis is not a problem for years on > > a low traffic site. > > It's not about cryptanalysis, it's about reducing impact from > compromised hosts and from the weak authentication systems that are done > on all the "low value" DV CAs. (specifically this one is "requester had > access to cause files to be served at an http server running at the > address pointed to by DNS at the time it was requested" so a security > failure at any of a number of points would allow access). > Yeah but all I give them is an CSR. I haven't had an issue like that before with STARTSSL. I agree the CA system is ridiculous though and was disappointed when I found letsencrypt's policy documented showed it to largely be a copy of all that has gone before rather than something revolutionary. I guess without DNSSEC being fixed and widely used or DNSCURVE being widely used or major browsers getting directly involved in domain validation (really the only important thing) then that can't happen. > > You enforce SSL for data submissions, a user checking keys has to check > > the domain in any case and hope the browser domain matching code is > > secure too (yes there has been atleast one firefox bug there) even > > before considering the DNS system. > > Still, browsers are a higher bar than the control panels and front line > support staff at a typical cheap domain host. > Agreed, and non gpg'd emails especially. > > It's main unrealised potential benefit is; add *some* security by > > default to all those insecure wordpress logins. > > That's a terrible reason. And actually it's "make those insecure > CMS sites look more like they might be secure" when they're no > such thing. Because people have been trained into equating https > with security. Which is just plain wrong. > Well yes but more pop up everyday. I have a friend who paid good money for a site and because I didn't want to send passwords by text message or email and enabled SSL on the wordpress login (for free simply because I couldn't allow it!!!) I was asked by the web developer company if I worked for the CIA or something!! Later they changed the password on me to something quite simple!! Interestingly, a few months later the wordpress admin login went down at heart internet and login attempt restrictions put on them all because wordpress sites were being widely brute forced apparently in order to add them as attractive (high upload bandwidth) clients in botnets. -- KISSIS - Keep It Simple So It's Securable
Re: TLS now supported on openbsd.org?
> > It's main unrealised potential benefit is; add *some* security by > > default to all those insecure wordpress logins. > > That's a terrible reason. And actually it's "make those insecure > CMS sites look more like they might be secure" when they're no > such thing. Because people have been trained into equating https > with security. Which is just plain wrong. Also whilst ordering a 100 units could happen when you only want one, often the security such as for payment is a third party server which is *usually* more secure or atleast PCI compliant, haha. Strangely, payment systems (paypal started requiring it last year) often require javascript which I guess is ironically the most likely vector for ID theft in this scenario. So... why is there so much hoo har about SSL everywhere and no attention given to javascript from third party domains doing all sorts of potential things (potentially exploitation) and encouraging payment systems to be javascript free. Both SSL everywhere and javascript nowhere require encouragement and time to accomplish. So is their an agenda or just many idiots who see TLS=security and don't see lack of secure cookie usage and XSS vulnerabilities (now protected by SSL everywhere) meaning a site is likely exploitable in other ways!! Which brings us nicely back to your original point, haha ;) -- KISSIS - Keep It Simple So It's Securable
Re: light browsers
> Firefox used to be nice, but I don't like the way it goes with > embedded crap such as Hello or even worse, the Pocket thing. > Indeed, but it's maybe the last web browser caring about its users, without selling them or asking them to pay. w3m already has been mentionned on the list. With some time, it becomes very handy. But what about netsurf? http://www.netsurf-browser.org/ Regards, -- /Thuban/ [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: httpd - Multiple index files?
Thank you very much! I will look into that. On Thu, 12 May 2016 12:54:02 +0200 Erling Westenvik wrote: On Thu, May 12, 2016 at 10:18:09AM +, Romain wrote: > Allright. > Thanks for your answer. Have a look at this thread: https://github.com/reyk/httpd/issues/27 And my example would probably be better this way: > On Thu, 12 May 2016 11:40:10 +0200 > Erling Westenvik wrote: > > On Thu, May 12, 2016 at 12:04:50AM +, Romain wrote: > > Is it possible to supply multiple index files to the directory index > > directive? I mean, I would like to write something like that in > > httpd.conf: > > > >directory index "index.html" "index.php" > > > > which would mean that, if the directory contains "index.html", then > > the server should serve it first, if not, then try "index.php", > > otherwise the standard error. > > Not that I'm aware of. Anyway: Such logic should be part of your > application, not the web server since it would just add unnecessary and > ambiguos complexity to the latter. > > > Or should I do it in another way? > > You could try something like this: > > if (basename($_SERVER["PHP_SELF"]) == "index.php") { >header("Location: ".$_SERVER["REQUEST_URI"]."index.html"); >} > ?> > > > Thanks. > > Best, > > Romain > > Regards. > > Erling
Re: light browsers
sogal said: >> Basically anything that is using webkit is going to have issues: >> https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ >> >> This means, xombrero, luakit, probably all the others that aren't >> firefox and chromium. > > Thanks for the interesting link. > The xombrero "security" features lie in the default settings and the > possibility to harden them regarding to privacy issues. > > But indeed, it seems that every single Webkit(Gtk) web browser is broken > which leaves us with very few choice. You must face the reality: all web browsers are broken. Modern web rendering engines are too complex and too fast-moving to be securable at all. Mozilla and Google made every effort to ensure that nobody can ever be safe. Webkit1-based browsers (Luakit, Midori, surf, Vimb and Xombrero) use unmaintained engine, so nobody fixes even known issues. People who care about security should probably avoid these. AFAIK situation is similar for QTWebKit (Otter). Situation with Webkit2 (Epiphany and surf2) is a bit better. It is actively developed, and some issues get fixed. But GTK+ port - the one we can use - is undermanned and Linux-centric. It has issues. XUL (Firefox and SeaMonkey) and Blink (Chromium and Iridium) are in better shape, so there issues there are probably fewer. But there still are issues. And we are not top priority platform for either, so upstream does not care much whether things work for us or not. And these are primary targets for bad guys, so those fewer issues have higher chances of being exploited. Thuban said: > w3m already has been mentionned on the list. With some time, it becomes > very handy. > > But what about netsurf? FWIW there is no reason to believe that situation with w3m, netsurf, dillo, lynx and numerous links forks is better. These browsers support smaller subset of HTML/CSS/JS specs then major browsers do, but their developer teams are yet smaller, and their security was never studied in detail. They may be just as broken as major browsers. Who knows? There is no safe bet here. Pick whatever you want, and you'll loose eventually. Or maybe you won't, but only if you are lucky enough. Parsing HTML manually is probably the safest option, albeit ugly. You will still suffer from bugs in your HTTP(S) tool though. -- Dmitrij D. Czarkoff
pf queue bandwidth estimation
using broadbandspeedchecker.co.uk i measured the bandwidth on my virgin media line, the download speed varied form as low as 20Mb/sec up to 50Mb/sec depending on the time of day the test was run, what will be the result if i put a value for the queue bandwidth which is greater or lesser the the maximum download speed ? shadrock
Re: light browsers
On Thu, May 12, 2016 at 6:12 PM, Dmitrij D. Czarkoff wrote: > You must face the reality: all web browsers are broken. Modern web > rendering engines are too complex and too fast-moving to be securable at > all. Mozilla and Google made every effort to ensure that nobody can > ever be safe. A related issue is that different people have conflicting ideas about what "security" means. That said, if you want to minimize leakage of information, you can stand up fresh system images for every site you browse to (and regularly reset them). This can get a little frustrating when you want information from one site to be used at another, but that's also the sort of issue which leads to people using different concepts of "security". -- Raul
Re: TLS now supported on openbsd.org?
>So >is their an agenda or just many idiots who see TLS=security and don't >see lack of secure cookie usage and XSS vulnerabilities (now protected >by SSL everywhere) meaning a site is likely exploitable in other ways!! You guys should seriously check "Nirvana fallacy".
Re: light browsers
> On Thu, May 12, 2016 at 6:12 PM, Dmitrij D. Czarkoff > wrote: > > You must face the reality: all web browsers are broken. Modern web > > rendering engines are too complex and too fast-moving to be securable at > > all. Mozilla and Google made every effort to ensure that nobody can > > ever be safe. > > A related issue is that different people have conflicting ideas about > what "security" means. A related issue is lots of people don't know anything about anything.
Re: Swift?
On 2016-05-12 08:37, nacredata wrote: I was thinking of the Apple sponsored projects which is now supposedly open source & usable server side. I've done Objective-C in the past but have not played with Swift yet myself; if it were available I might play with that amongst all the other languages and frameworks that I am using on projects. No big deal, I'm not sure if it's a particularly good fit or not, just like to play with things. devin -- contact info: http://nacredata.com/devin On May 11, 2016, at 23:53, Einfach Jemand wrote: On Wed, May 11, 2016 at 07:30:42PM -0400, Devin Ceartas wrote: Can you run Swift on OpenBSD? devin Which one? This:https://swift.org Or that: http://swift-lang.org/main/ rru No. There's no package for it. You can install the pre-requisites and attempt to build from source but their build tool does not recognize OpenBSD