On 09/28/16 22:25, Walter Alejandro Iglesias wrote: > I'm about to run my own web server using OpenBSD. I'm giving my first > steps with pf. I was very enthusiastic till I got to this point: > > https://www.openbsd.org/faq/pf/logging.html > > It says: > > The log file written by pflogd is in binary format and cannot be > read using a text editor. > > So, *binary* logs. Sounds familiar to me. And then:
I hope this doesn't discourage you too much. While I don't have the privilege of reading the developers' minds, there are a few practical considerations that help make the binary logging understandable as the default configuration. One is that firewalls are not necessarily the most capable pieces of hardware you could put your hands on. Decoding every single packet to text and writing to syslog or even to console could in itself add significantly to the load on the system. I hadn't thought of those incidents for several years, but while writing this I remember some episodes involving Linux-based firewalls that did log every packet, decoded to readable text, to the system console and to syslog. In slightly high-traffic situations -- not actual DDOSes by any measure -- logging on to the system to fix whatever was not really doable. Be that as it may, one other thing that comes to mind is that frankly, most of the traffic is likely to be of no interest whatsoever once it's been successfully handled according to your PF rules. > I must confess I'm one among those "run to the hills" paranoids. I'm > not an expert, perhaps I'm judging pflog wrong but, anyway, I still > prefer the traditional way, using cat, grep and tail. Well, for for generally keeping an eye on things and not putting too much strain on anything, setting up pflow(4) to export the metadata to view with something like nfsen is a good option[1]. If you really want to keep a copy of all traffic, well, you need to go for beefier hardware and set up to keep a copy of your traffic somewhere and play with whatever combination of snort, bro and friends that fit your needs. And yes, beefy hardware and sufficient storage will be a requirement. Then again, in all likelihood you will not really want to be staring at all traffic that ever passed through all network interfaces. If and when your chosen tools show up something you want to look into in more detail, applying tcpdump to the binary PF logs may very well be sufficient to find out what happened and make intelligent decisions. If you want to keep the PF logs around for longer than the defaults, look into the log rotation settings as your first step. I remember having a somewhat similar reaction as yours when I first read about the binary PF logs, but in practical terms the way it's done actually makes sense. - P [1] One such setup is described, with some anecdotes just because, at http://bsdly.blogspot.com/2014/02/yes-you-too-can-be-evil-network.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
