It may look like a mess to you, but that sort of syntax is insanely popular in the firewall world. Take a look at pf. nftables syntax is pretty obviously heavily borrowed from that.
> I have no idea what kind of building they're in, but let's assume it's a 20 person office.
It's Theo's basement.
"That’s enough for the organization of the hackatons, running of the servers (three racks of computers in my basement), electricity and internet access." (http://undeadly.org/cgi?action=article&sid=20111018061633 )
Photo: http://www.openbsd.org/images/rack2009.jpg
Edit: here is a video from 2006 http://www.youtube.com/watch?v=BlgdvSNpi60
Compare that to the pf manpage. And in the OpenBSD FAQ there is a thorough guide. pf is OpenBSD's packet filter framework. pf is awesome and the documentation even more so.
I wish Linux network utilities would have that amount and quality of documentation. iptables, tc, ip, all have shit documentation.
OpenBSD is ported to many architectures which could not be easily virtualized or emulated.
If they are building software for a Sparc version of OpenBSD they have to use a Sparc server.
Whenever someone says this I wonder how they feel about OpenBSD's approach to patching the OS. Anytime a problem is found OpenBSD posts the patch and it is the responsibility of the user to patch and compile the fixed binary. The other option is to follow the stable branch and recompile the entire OS when a problem is found. This can be a serious problem is someone is not on top of this. OpenBSD 5.5 came out in May 2014 but since the code freeze was back in March 2014 they knowing released it without the Heartbleed bug being fixed. It's the user's reasonability of the user to patch their system. The same goes with packages. They are not updated and it is the user's responsibility to follow the STABLE ports branch and recompile in packages with bugs.
Looking at the fixes, woow
Seeing that i cannot be -1 at that line and that the function return i, this fix scares me a lot (well, not the fix, the fact that this funciton was able to make this function fail but return success at the same time. Wondering if malformed packet could trigger that...).
Now that the NSA has poured gasoline on the erosion-of-trust bonfire, we can get started. x-post from /r/linux :
They've said from the very beginning that this is a two stage project: Fix the code for OpenBSD, then port.
What's happening here is that people are porting a pre-alpha project to really disparate platforms and the OpenBSD crew are saying, "Hold up! It's not ready yet!".
As for portability, OpenBSD is surpassed by few: http://www.openbsd.org/plat.html
NetBSD wins definitely, an argument could be made for Debian but the support is better under OpenBSD IME.
EDIT: formatting
From one of the new songs with the latest release:
> Found my way upstairs and read hackernews
> whining about comic sans and CVS.
> Whiiiiiiinne whine whine....
>Whiiiine whinee.... Whine Whineee....
>whine.. They... Use Cee.. Vee Esss...
is there really any difference between the technical-oriented subreddits and HN nowadays?
There are a lot of different ways to do this - OpenBSD changed time_t which was traditionally the 32-bit value to 64-bits in 5.5, which broke a lot of things all over the system, which they fixed:
http://www.openbsd.org/55.html
The presentation on how this was done, the different ways other systems fixed it, and what was required is here - it's quite interesting as many things you wouldn't expect break, and this "simple fix" was much harder to implement than just changing a variable type:
O_O
With Java for Classic Mac? I assume you have Mac OS 8...
OpenBSD 5.5 for macppc could run it faster if you run it with CWM as the window manager. (Kinda like ultraminimal "desktop environment").
Not sure if it's enough of a reason, but from their crypto page:
> When we create OpenBSD releases or snapshots we build our release binaries in free countries to assure that the sources and binaries we provide to users are free of tainting. In the past our release binary builds have been done in Canada, Sweden, and Germany.
(Not US because crypto export laws)
>First question. It seems AOSP is open but they develop and then release instead of having a repo where you can see development happening. What is this style called where you develop openly vs waiting till its complete and then releasing? Are the BSD's developed in the open or are they like Android?
This is actually OpenBSD’s raison d’être. The “open” in the name refers not to the license, but the development methodology. OpenBSD pioneered this by inventing anonymous CVS, letting you download the latest source code, view commit logs, make diffs, and so forth without a developer account. We take that for granted today, but in 1996 it was a revolutionary concept.
I googled "font anti-aliasing", is this what you mean?
I don't have a problem reading stuff. Can you post a screenshot from your setup so that I know what I'm missing?
Also, how the hell did you know I'm on reddit all day?!
It doesn't exactly look like you're dropping frames; I could be wrong, it is a gif. IMO this post comes across as needless complaining.
"How dare the dev improve the general user experience of the app with no real performance impact."
Yes, that little animation is slightly more expensive to render out, but not by much. Using your same logic you might as well ask why the font is being anti-aliased.
"Wouldn't it run faster if it wasn't anti-aliased?"
Technically yes, but, for the small performance cost, the aesthetic improvement is beneficial for most people.
Ultimately, the dev is the one who is gonna draw the line in the sand on this kind of thing, but generally if the feature isn't causing you problems, maybe don't complain about it.
OpenBSD doesn't even implement it as a binary:
#! /bin/sh # $OpenBSD: true.sh,v 1.2 1996/06/26 05:41:53 deraadt Exp $
exit 0
Funny how that works. We have a couple major issues which are resolved pretty quickly and suddenly Windows users think these are comparable to what they deal with all the time.
Just for the general populus who may come across this at a later time/date:
Remember, code is by it's very nature imperfect. Is Linux Perfect - not at all. Is it better than other alternatives - mostly yes. Is it the best out there for security - nope and we all know that.
It was too short notice. It takes time to build a shitload of stuff and fab and ship CD-ROMs. This was the great year 2K38 release (a massive amount of work). Expect LibreSSL in OpenBSD 5.6. Which is what the gang are currently putting a massive amount of work into. Note that in the course of that work, they're finding further problems that are sufficiently severe to warrant their own 5.5 errata and patches, including one posted today. If they had dropped everything and binned and spent extra money (they don't have) to remaster/remake the CDs after heartbleed, they would have had the same problem a few days later with the next bug, and the next bug, and the next bug. They've seen that the state of OpenSSL is so bad, they can't win that race. Hence LibreSSL and further bulletins as events warrant. Of course, for each patch, the decision whether this actually applies to you, i.e. whether you're actually running that code/service – that's up to you. If you've not running OpenSSL on your server, then you might even decide to wait – caveat emptor. After all, OpenBSD is an OS by people who know what they're doing for people who know what they're doing.
Wow, you may be right! I was somehow very sure they had a third party audit the code for compliance, but their security page suggests otherwise. It sounds like it is another team within OpenBSD, but they do the audits and code fixes, so they're definitely developers, too. Thanks!
As far as I know you are supposed to get a small amount of entropy from your operating system regularily and use that with a secure random number generator in userspace.
OpenBSD provides a random number generator called arc4random(3) for that purpose. I generally trust them to know what they are doing.
Do we need one, no. That said the OpenBSD devs don't care what other people need, it's what they want that matters to them.
As for being more secure, the focus isn't on performance but on understandable code. They don't implement their own memory allocation which allows fixes and exploit mitigation in the base OS to also benefit httpd.
Chroot by default is a common theme with OpenBSD, such that if something does manage to get arbitrary code executed by the process it has a significantly limited environment in which to get a foothold. If there is no programming language interpreter in the chroot then it's not feasible for exploits to use them either.
With privilege separation if a process does for some reason maintains escalated privileges it's isolated via sockets and very limited in what it will accept over that socket and in what it does in general in order to mitigate the process that's dropped privileges to use it as an exploit vector. This slide by Theo might help explain, that whole presentation is relevant to the security focused aspect of OpenBSD development.
For lists, queues et c I use the macros from BSD queue.h. Simple enough to drop into whatever project I'm working on.
All the firmware distributed as part of OpenBSD is freely redistributable, see the -license
files in /etc/firmware. This firmware would otherwise be in ROM or flash, and may comprise the core functionality of the device.
Stop conflating the term blob, which OpenBSD has long history of fighting against.
There is no reason for them to all have public IPs. If you want you could easily assign each employee a /24 to do with what they will on private ranges.
reallocarray(3) is a malloc(3)/realloc(3) extension from OpenBSD, it is very portable and easy to incorporate into existing codebases.
The intention of reallocarray is to replace the following idiom:
if ((p = malloc(num * size)) == NULL) err(1, "malloc");
..with the much safer:
if ((p = reallocarray(NULL, num, size)) == NULL) err(1, "malloc");
In the first example, num * size may lead to an undetected integer multiplication overflow.
reallocarray(3) performs the same overflow detection that is conventionally done by calloc(3), but without the expensive memory zeroing operation. It returns NULL on overflow, with errno set to ENOMEM, as is permitted by standards.
It is now being used extensively by LibreSSL as within OpenBSD's own userland; and in the kernel, as mallocarray(9).
The most dangerous part of strlcpy/strlcat is the return value. To try and detect incomplete copies, it runs over the entire length of the source string. (see the while(*s++); part from the function's source code)
Say you are tokenizing a 10MB XML or CSV file. Every time you used strlcpy() to move a chunk from the source string to the token string, it would run through the rest of the source string. Thus, tokenizing the entire document would effectively result in O( n^2 ) overhead. If you tokenized every ~10 bytes, that would be 5,000,000,000,000 terminator checks. (10MB/2 * 10M/10)
strncpy has a similar problem, where it fills the target buffer with nulls after the source string is exhausted. Plus its other faults like potentially not null-terminating the target string at all and such.
I've been trying to promote my workaround to both of these issues, strmcpy and strmcat. No need to fight about getting it into a standard. Just stick it in your source file directly.
//return = strlen(target) inline size_t strmcpy(char *target, const char *source, size_t length) { const char *origin = target; if(length) { while(*source && --length) *target++ = *source++; *target = 0; } return target - origin; }
//return = strlen(target) inline size_t strmcat(char *target, const char *source, size_t length) { const char *origin = target; while(*target && length) { target++; length--; } return (target - origin) + strmcpy(target, source, length); }
(Code condensed for posting purposes. Code is ISC or public domain, your choice.)
How would Arm get better if it's prohibited from doing business with a good chunk of its customers?
Do you know where OpenBSD and OpenSSH are based, and why? Do you know which country both cannot move into?
> If you're on a 32-bit operating system (which is becoming rarer and rarer), you probably want to start compiling with -D_TIME_BITS=64 within the next 21 years.
Isn't it feasible to use this option by default in GCC? OpenBSD did switch to 2038-proof time on i386 in 5.5. Wouldn't this make it even more transparent and painless?
Nota: I have really no idea how software is actually built, I'm genuinely curious
i encourage you to read those slides
but tl;dr the libressl code and especially their new libtls API offer stronger implementation security guarantees, is easier to work with, and is probably more 'future proof' against bus factors.
Another missing astonishment: public anonymous checkouts. We take this for granted now, but before anonymous CVS was developed by OpenBSD (in 1996 or so), you had to have an account on the machine containing the repository in order to do a checkout, diff, or view history.
First benefits of the Great Purge:
Even though we haven’t switched to the fork yet I imported those two at work immediately. Thanks, Theo & Gang.
13 years ago I gave up on consumer routers and just started installing OpenBSD on cheap low power devices. Currently I’m running it on an edgerouter lite I got marked down to $50 in a promo.
Yes it’s a pain to spend a few hours getting it going the first time but that amount of time spent in night 0 eliminates the next 18 months of pain.
> ... I have no way to respond to the bug report...
Yes, you do. This bug report reply is on the bugs@ mailing list.
There is a Majordomo server at https://lists.openbsd.org where, if you subscribe, you may request this archived Email be sent directly to your Email address, where you can then reply to the list, or the author.
Addition info on Project mailing lists may be found at http://www.openbsd.org/mail.html
My first impression is - can we use other tools to confirm the chance it is OpenBSD 4.0? I rarely use nmap - so I have no idea if that's a bogus result or not. Are there tools and techniques?
I do see in your output "Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port"
OpenBSD is the paranoid's choice of OS. Real hackers (not script kiddies) would tend to keep up on it - even if they don't use it daily. What's interesting is how old that is - year 2007! And I've noticed that the kernel panic episode (last week) we had some Fedora Core 12 being used also old 2009 stuff.
If indeed it is OpenBSD 4.x - and not a simulation or misdetection (nmap default or something) - they may actually want someone to hack it using bugs found after it's maintenance cycle ended. Because it no longer gets updates: http://www.openbsd.org/errata40.html
> which CVS verifies the integrity of
afaik it's not signed though..
> Right, snapshots are the exception. But they're not always used. Typically (in my experience) snapshots are used when upgrading from source is impossible(incompatible source changes), or are very difficult.
I highly doubt this considering that the upgrade process documentation describes the install kernel method and only makes a passing remark on how to recompile it (or rather recommends it only if needed).
Also the openbsd fanboy I know doesn't compile from source either.. so..
Website even seems to recommend against it:
http://www.openbsd.org/faq/faq5.html
> 5.2 - Why do I need to compile the system from source? > > Actually, you very possibly do not. > > Some reasons why NOT to build from source: > > * Compiling your own system as a way of upgrading it is not supported. > * You will NOT get better system performance by compiling your own system.
> Here's something we urgently need: a drop-in replacement for OpenSSL.
That is not possible. OpenSSL exposes a number of internal structures as part of its "public API", you can't implement a drop-in replacement for OpenSSL without essentially being OpenSSL (hence drumroll LibreSSL which started from there and started trimming).
What you can do is implement saner APIs like libtls[0].
The man page:
> The httpd program first appeared in OpenBSD 5.6. httpd is based on relayd(8).
The intial commit:
> Add httpd(8), an attempt to turn the relayd(8) codebase into a simple web server
CVS has worked well for the developers for the last ~18 years. You don't replace something proven just because there's something new and shiny.
OpenBSD was one of the first open source projects to make available their source repositories to the public, you can read more about it in Chuck Cranor and Theo de Raadt's paper on Anonymous CVS.
http://www.openbsd.org/papers/anoncvs-paper.pdf
http://www.openbsd.org/papers/anoncvs-slides.pdf
Not 100% sure, but I think they are dragging their feet on this one because it will break lots of compatibility with existing programs.
You should read the explanation for this release's song lyrics. It does a good job explaining why this is good news for everybody, not just OpenBSD.
Sure, that too. But the commit messages in the past few days and their pace (and commits to other subsystems in OpenBSD as well) have a distinct smell of a hackathon. Which means that the messages were intended to be read by others in the same room within minutes and cause random laughs.
edit: I checked. There was a hackathon that actually ended today.
My routine is to buy an install CD whenever they do shit like this, the kind of awesome shit that makes me want to buy the whole team a beer.
They have other merch too, if that is the kind of thing you also buy. I think these things are basically the OpenBSD tip jars, so go nuts.
I think you're underestimating the amount of changes they need to test daily. Here is an archive of their commits mailing list. Some days amount to over 30 source code changes.
Now take a look at hardware platforms they support. They need to test each and every change on each of those platforms to ensure that it doesn't break. That includes compiling, running it and I'd assume (hope?) automated testing.
For a long time, OpenBSD’s pthreads implementation was “uthreads,” a user‐level threading library that is old, unmaintained, and buggy. User‐level threads are also bad for performance—several threads are condensed into a single process run by the kernel.
Rthreads is a kernel‐level threads library (so named because it uses the rfork(2) system call). Since it is integrated with the kernel, each thread in a program is equivalent to a kernel process, which is better for performance.
If you must use Open Source for security matters...then only use OpenBSD and "PF" is the firewall for that.
http://www.openbsd.org/faq/pf/
(personally, though I'd just buy a 50-user license Cisco ASA 5505...but that's just me :-)
He was only talking about daemons that run as root. Obviously anything running as root can get out of a chroot directory. For many daemons that don't, such as apache, it is a sound security practice.
When in doubt, look to OpenBSD.
When your webserver can use pledge and is also written to be as featureless as possible. This makes it easy to understand the configuration files so you know that when you are setting it up you are making your attack surface as small as possible.
Most of the critical CVEs I've seen since running linux are missed because they are in some random kernel module that is infrequently used and even less frequently understood. Additionally, OpenBSD is general seen as having higher overall code quality when it comes to security.
But most of all (more than my desire for security) I just like being able to better understand how my system is working, and right now OpenBSD allows me to do that (or at least lets me think I understand it better, I feel like there's always more to learn when it comes to the Linux though due to its immense size and scope).
Edit: remove nonsense about ports.
The one thing that really irks me about this policy is the FAQ entry on using ports. By discouraging the use of ports as an 'advanced' feature, they are actually telling inexperienced users to run unpatched software for up to six months at a time.
2013 presentation by Theo de Raadt
Q&A from the same conference
In fact, going through the papers on the OpenBSD website would be a good idea—there are lots of presentations there, and I’m sure you can find some interesting ones.
Not trying to argue that you're wrong for preferring Terminator or anything along those lines, but for the record tmux does have mouse support, including resizing:
resize-pane [-DLMRUZ] [-t target-pane] [-x width] [-y height] adjustment Resize a pane, up, down, left or right by adjustment with -U, -D, -L or -R, or to an absolute size with -x or -y. The adjustment is given in lines or cells (the default is 1). With -Z, the active pane is toggled between zoomed (occupying the whole of the window) and unzoomed (its normal position in the layout). -M begins mouse resizing (only valid if bound to a mouse key binding, see MOUSE SUPPORT).
--
MOUSE SUPPORT
If the mouse option is on (the default is off), tmux allows mouse events to be bound as keys. The name of each key is made up of a mouse event (such as ‘MouseUp1’) and a location suffix (one of ‘Pane’ for the contents of a pane, ‘Border’ for a pane border or ‘Status’ for the status line). The following mouse events are available:
MouseDown1 MouseUp1 MouseDrag1
MouseDown2 MouseUp2 MouseDrag2
MouseDown3 MouseUp3 MouseDrag3
WheelUp WheelDown
Each should be suffixed with a location, for example ‘MouseDown1Status’.
The special token ‘{mouse}’ or ‘=’ may be used as target-window or target-pane in commands bound to mouse key bindings. It resolves to the window or pane over which the mouse event took place (for example, the window in the status line over which button 1 was released for a ‘MouseUp1Status’ binding, or the pane over which the wheel was scrolled for a ‘WheelDownPane’ binding).
The send-keys -M flag may be used to forward a mouse event to a pane.
The default key bindings allow the mouse to be used to select and resize panes, to copy text and to change window using the status line. These take effect if the mouse option is turned on.
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux
you are running snapshots then.
to upgrade download a new bsd.rd into /
reboot and type bsd.rd at the boot prompt "boot> bsd.rd"
instead of i for install chose u for upgrade
after upgrade reboot and run sysmerge(8) and then run pkg_add -u
also always look at http://www.openbsd.org/faq/current.html before upgrading
That may be because Git was the new product, while GPL-licensed CVS is working just fine, so there's no need to hurry with its replacement. They are working on it, thought, judging from the date of last commit, and I remember reading somewhere that it's almost ready.
I'm not too sure how you expect the kernel hackers to be using provisioning tools to manage things beyond one or two machines.
Do your provisioning tools even work on even half of the architectures supported by OpenBSD? http://www.openbsd.org/plat.html
OS: OpenBSD 5.8-current
Shell: pdksh
WM: cwm
GTK Theme: Numix
Icon Theme: Numix
Fonts: Luxi Sans and Mono, Helvetica
Wallpapers: Random from Bradley Castaneda and Views of the Pacific Northwest
The dzen2 status bar is a work in progress. It's not reflected in the screenshots, but the icons change in response to system events.
I'll share the dotfiles if anyone's interested.
The only tutorial you need to get started is to follow the suggestions in "man afterboot" and to use this FAQ from the OpenBSD site, which has an example ruleset at the bottom. http://www.openbsd.org/faq/pf/index.html
Pf is enabled by default to pass traffic outbound from the host itself. You only need to write rules if you are wanting something to come in. The rules have a simple yet powerful syntax, so most people familiar with Linux should be fine as long as they read the main FAQ and the man pages (which, unlike most Linux distros, are accurate, have regular use case examples at the bottom, and are kept up to date).
> Here we have a serious article about keeping OpenBSD modern done in ... Comic Sans?
It looks like the plan to draw out the people who don't even scroll down TFA before complaining worked!
imo, the web site is wonderful. It has a beautiful feel to it, an aesthetic, if you will, or perhaps a statement on design and fashion (see the recent rush to move from shiny to flat design because it's become the cool thing to do). It's also accessible and doesn't rely on dangerous JavaScript VMs to function. Katherine Prio's artwork is just stunning and unlike anything any other operating system is doing.
(also, it may offend your nerd cred, but after a quick comparison I actually find the serif font my browser gives the paper after scrolling down less readable than Comic Sans...)
The best way to convert from -stable to -current is, by far, to download a bsd.rd snapshot from a mirror, verify its authenticity with signify(1)
, boot from it, and go through the upgrade process, then follow the steps in the -current FAQ.
Yeah, there is a function from OpenBSD called strtonum
for this purpose. It has been designed to catch most common use cases and eliminates the hand-rolled boilerplate you had to use before. Here is the man page. Again, strtonum
is not in the glibc for ... reasons.
I don't really understand the confusion here. The base system hasn't suddenly stopped including an HTTP client.
OpenBSD's ftp(1) utility supports both HTTP and HTTPS. It's the backend used by the package tools and the system installer.
It was decided the base system didn't need a text-mode HTML parser/renderer, which, also just happened to bundle a bunch of obsolete network protocol clients.
If OP’s Mac mini is from 2005, it is macppc
, and cannot use syspatch. The first Mac mini with an x86 processor was released in 2006.
>Note that binary patches are only available for the amd64, i386, and arm64 architectures.
Author (and a tad surprised to see this pop up here). I've mostly found that dynamic arrays are served well enough with malloc/realloc, and are less clunky to use that way in C.
Although I should add some code to realloc() an array such that the new entries in the tail are zeroed.
Edit: Thinking of an API kind of like:
void *arraygrow(void *p, size_t *cap, size_t sz, size_t eltsz);
Similar to realloc, (and influenced by reallocarray) but doing the whole power of two growing thing. Used like:
ds_arrayinit(&p, &cap); // really just zeros them p = ds_arraygrow(p, &cap, nelt, sizeof(int)) // cap now holds the maximum capacity, guaranteed >= nelt*eltsz. // pass it back in for sane amortized O(1) appends.
Additionally, you should be able to set that as a default for a range of ssh servers using ssh_config. You can do this (at least, in Linux systems, but likely OSX as well) by creating a config
file in your ~/.ssh
directory (which may need to be created).
In that file, you can specify a selection of hosts to apply settings to, and then the settings you wish to apply. eg;
Host * ForwardAgent yes ForwardX11 yes
Host rpi*.domain.tld ForwardX11Trusted yes
You can run man ssh_config
, or read up on the directives here
Exactly, sadly Mozilla and Gnome are or were heading the same path.
Besides from TDF and EFF, don't forget about OpenBSD.
Here are a some of their contributions: http://www.openbsd.org/innovations.html
Sure sure, I wouldn't actually disagree, just note that 95% isn't actually that great. That's a problem every 20 minutes - probably because of the endless bashisms you've picked up (don't worry I'm not going to argue that pure standard sh isn't sucky and I'm prone to bashisms too. Just saying you do have to be a bit careful learning a super-featureful shell like bash or zsh. Learning another simpler non-bash/non-zsh but moderately featureful alternative like OpenBSD's ksh variant can help)
From http://www.openbsd.org/faq/upgrade55.html#time_t (emphasis added):
> OpenBSD 5.5 is year 2038 ready on all platforms, but this required a change to a 64 bit time type, which should cover us for the next 290 billion years...
You obviously don't understand Quite the level of snark that comes with OpenBSD. These are quotes pretty much straight out of the commit log, and damn if they aren't accurate.
looking at the internet archive seems to hint towards that webpage not being updated in at least 4 years.
it's probably better to look at the release pages to see what the latest is on the crypto stuff: http://www.openbsd.org/54.html and if you really want to dig deeper the changelog: http://www.openbsd.org/plus54.html
as for why they dont use SSL on their website.. i cant speak for them, but i dont really see that theres much need to.
edit: oh yeah. more than that: $OpenBSD: crypto.html,v 1.135 2009/05/11 08:42:15 jsg Exp $
Reading through the upgrade guides, I found this:
> * IPsec HMAC-SHA2 incompatibility: > > Two bugs in IPsec/HMAC-SHA2 were fixed, resulting in an incompatibility with the HMAC-SHA-256/384/512 hash algorithms with previous versions of OpenBSD and other IPsec implementations sharing the bugs. In particular the default authentication algorithm HMAC-SHA-256 is affected. Upgrade both sides together, or switch to another authentication algorithm during the transition.
Here's an article on this subject:
http://bsdly.blogspot.com/2012/12/ddos-bots-are-people-or-manned-by-some.html
You can also rate limit with PF: http://www.openbsd.org/faq/pf/filter.html#stateopts
Ultimately, mitigating DDoS'ing is difficult. Cloudflare can do it because they have the infrastructure for it.
> The openssl application is not suitable for production use > > Yet it gets used as the "example code" to develop production applications
Hi,
You can create it by running :
$ cd /dev $ sudo ./MAKEDEV video2
There is a small utility in base to record / display webcam, see video(1)
Add the following snippet to your .ssh/config
to prevent timeouts if you haven't already tried:
Host * ServerAliveInterval 60 ServerAliveCountMax 10
Details in the man page.
If you still have problems, try using autossh
.
This appears to be the most-requested feature for LibreSSL. I will give it a shot:
2.1.0 represents the first portable snapshot for what will eventually become the version included with OpenBSD 5.7.
A few bullet-point for this new snapshot would be:
This is by no means all. I spent about 10 minutes reviewing the logs just now to create this list, but I would suggest you do the same if you are interested.
The LibreSSL 2.0.0 - 2.0.5 portable releases did not really have detailed changelogs either. They were literally snapshots of the OpenBSD 5.6 tree through its development. The final summary for the 2.0.x portable series is represented by the OpenBSD 5.6 release notes (changes since its initial fork from OpenSSL 1.0.1h). It is as notable (perhaps more!) for what it removes as what it adds. http://www.openbsd.org/56.html
OpenBSD has added security features to their gcc-local(1), but a major factor for sticking with gcc 4.2.1 is licensing. It was the last GPLv2 version. The gcc3 is maintained for older platforms where gcc4 either lacks a backend, or is "too bloated".
Here's one bug fixed: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/d1_both.c.diff?r1=1.7;r2=1.8;f=h
A variable in a code block was set after a goto. It's quite obvious nobody did peer review if bugs like this slip in.
DDOS is a bad idea of course. But if you do want to annoy the spammers, have a look at OpenBSD's spamd. When a spammer connects it throttles the connection to try and tie up the maximum amount of resources on the spammer's computer. If it's waiting for your server to send back the SMTP response at one character per second then that's time that it can't use to send spam to other people. So at least you're doing something.
http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&sektion=8
http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1
https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding
I assume they don't block SSH. Use your ssh_config to automatically set up remote forwarding whenever your machine connects to the remote server. Then make a cron job that checks to make sure the tunnel is established (netstat/ps | grep), then reestablishes the connection to the remote forward if lost. You'll want to have keys with ssh-agent setup too so you never have to type in a password. Bon chance.
It is the ISC license. It might not be widely recognized but the OpenBSD developers use it.
>If there were a backdoor, I wouldn't be surprised if it they were told to quietly forget about it
In this case though "they" are a group of people who make a point of developing and releasing their software in Canada to avoid US government regulations on cryptographic code (they also specify "non-American" as a requirement when asking for developers to work on crypto code), and seemingly have nothing to gain from this.
Of course some will put on their tin-foil hatters and point out that only someone working with the FBI would pretend to be so afraid of US involvement.
OpenBSD has always been open source and free, and it also has had a long history fighting against binary blobs.
http://www.openbsd.org/lyrics.html#39
The creators of this "LibertyBSD" project have been utterly confused from the start about what a binary blob is (..closed source kernel drivers, not firmware). All device firmware included with OpenBSD is freely redistributeable with licenses in /etc/firmware
. Additional firmware is installed through fw_update(1) if the hardware is detected. There are absolutely no binary blob drivers, OpenBSD doesn't even support loadable kernel modules.
This is merely an attempt for them to solicit donations, a bitcoin address has been prominently displayed on their website, and originally they withheld their "deblobbed" version until a goal was reached..
They have absolutely no involvement in the development of OpenBSD.
> And does anyone actually check ten thousands of lines of code provided by someone?
Yes. There are a lot of projects that do or specifically rely on code audits. See e.g. http://www.openbsd.org/security.html
You'll want to trunk the three ports together using LACP, then assign the trunk interface to the VLAN.
Just make sure your switchports have the same configuration.
(EDIT: Typo)
Questionably useful tip: OpenBSD man pages for basic commands like tar tend to be far superior to any Linux ones I've read. There can be some differences in flags and options but usually there's enough overlap for them to be useful.
The install56.fs
and miniroot56.fs
are suitable for USB devices, hence the sizes. The .iso images are not hybrid and thus are only writable to optical media.
OpenBSD has deprecated FTP installs in favour of HTTP, and releases are cryptographically signed using signify(1).
1) No, the only thing that is missing is proprietary graphics drivers and Adobe Flash.
You don't need Adobe Flash for YouTube - HTML5 is fine, and when it's not, youtube-dl works well.
I'd like to note that OpenBSD answered this question in their FAQs: "Can I use OpenBSD as a desktop system?"
2) No. Just OpenBSD. Try it. :)
Both Linux Mint PPC and OpenBSD have PPC editions.
http://www.openbsd.org/macppc.html
If you want, I can help you to install an OpenBSD desktop with XFCE4, device automounting and such.
our time is limited. no matter how hard we try, there is only 24 hours a day per person.
and the openssl codebase sucks. We're talking vacuum cleaner levels of sucks. We didn't want to work on it, and we assumed they were doing a good job.
http://www.openbsd.org/papers/bsdcan14-libressl/mgp00004.html and http://www.openbsd.org/papers/bsdcan14-libressl/mgp00005.html are valuable slides describing it.
And then you've got OpenBSD's pf packet filtering firewall to think about, if you're interested in making even more decision trees about what you need for a good router these days.
Like a few other commenters have stated, I don't want to have to learn IOS' or JUNOS' strange & convulated ( to me, at least ) ways in order to feel confident that I've set up my router correctly. Coupled with the expense of enterprise-grade equipment, the learning curve is too expensive for me to even want to bother.
OpenBSD & pf, on the other hand, will run on any $20/$50/$500 trash computer with a couple extra network cards for wifi & gigabit ethernet. which are like $40 a pair now. Learn at your own pace, on disposable equipment if you must, & you'll probably see that pf's syntax & overall layout is far better than banging your head against yet another Cisco cert or, even better, ponying up serious moolah to hire a Cisco certified person.
If you want, you can even run a locked-down meshed perimeter grid with trunking & failover, with all the amenities of bgpd & it's ilk, with centralized logging through syslogd & advanced QoS tuning available with the various packet filtering mechanisms built in to pf.
But you don't have to. If all you need is a single router/firewall, you can definitely do that all by your lonesome, or sign up for the @misc mailing list to join the many other OpenBSD users in conversation.
( I'm done 'buying' "routers" now, I think. )
To support openBSD and its efforts, donate, donate, donate.
http://www.openbsd.org/donations.html
https://https.openbsd.org/cgi-bin/order
http://www.openssh.com/donations.html
You probably use something from openbsd and may not know about it.
besides, everyone knows openBSD shirts and posters are better than linux's designs. ;)
That's not quite what guard pages do. And they are talking about setting MALLOC_OPTIONS=G.
Why would they need ssl on their website? Is there some way an interested party would NOT know that you are going to www.openbsd.org? It isn't as if there is anything you can do there but browse the site, access the ssl enabled store, or download from a mirror.
>They claim to focus on security on cryptography--why is the above so?
I can't speak for the people who work on the project. Usually, my experience has been that they are friendly and informative if I've done my homework. If you have questions about this, I think that it may be a good idea to peruse the changelog, maybe read the very complete man pages, or possibly peruse the misc@ mailing list archives.
Hey, if you don't have an answer by then, the folks on the list are usually very helpful.
Server OS: http://www.openbsd.org/60.html
There are 8570 sparc64 packages available, including media servers.
Great way to get started: https://ftp.openbsd.org/pub/OpenBSD/6.0/sparc64/INSTALL.sparc64
While Reddit isn't necessarily the best place to report a problem, the same sort of information would be needed here as any other communication channel.
This guidance on problem reporting is from the FAQ: http://www.openbsd.org/faq/faq1.html#Bugs
And here is additional detail on reporting problems: http://www.openbsd.org/report.html
This is pretty much exactly the wrong way around. OpenBSD is easy to set up for either desktop or server use, because it's easy to set up. While FreeBSD has PC-BSD to make desktop use easier, OpenBSD is easy enough on its own that it doesn't need that.
The FreeBSD Handbook is full of awesome and win, and I highly recommend it. No "but" to that at all. OpenBSD does have its FAQ, which is also really good. To say there's no hand-holding is misleading.
For someone like OP who has installed tons of Linux distros (including Arch), having the OpenBSD FAQ and the man pages should be more than enough to get going easily.
okay so pf is a match-last system, which means your stuff could be getting caught up in a rule later on in your pf.conf that does not have a logging option so you want
block in log quick proto tcp from any to any port { 25, 110, 465, 587, 995 }
note the addition of the quick
keyword, you also want to add in port 587 which is a mail submission port
secondly pf doesn't immediately flush everything to /var/log/pflog
you say you've got nothing in the log file, so I don't know if you mean nothing at all or nothing relevant so I'd check to see if you've got logging turned on
/etc/rc.conf pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_flags=""
If you want realtime access to the log you need to use the pflog0
interface via tcpdump -n -e -ttt -i pflog0
and the logged data via tcpdump -n -e -ttt -r /var/log/pflog
http://www.openbsd.org/faq/pf/logging.html goes into detail as to how to filter the log
"No Blobs" is misleading.
The "blobs" the OP is referring to, are firmware that is loaded into the firmware of a hardware device.
These are not in-fact blobs loaded into the kernel.
That's just a bandaid fix to the problem. To quote the manual itself:
> Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.
In other words, if a malicious user has SSH shell access, you are screwed no matter what.
you also need to edit /etc/ttys to spawn getty on tty00.
tty00 "/usr/libexec/getty std.9600" vt220 on secure
basically turn the 'status' column from 'off' to 'on'.
edit: