RE: Possible Setup
Realistically, this kind of layer 7 stuff can be done in at least two ways: 1) Like spamd (or a transparent proxy) that is redirects all traffic on a particular port (e.g. tcp/25) to another IP and port that is services by a userland application. The application then communicates as appropriate. Communication down the original redirected stream get appropriately redirected, but new communication links need some trickery. 2) Like Snort (or othe BPF application) that sniffs the traffic off the interface, reassembles the frames into streams (like a proper TCP stack does) and then requires trickery to reply down the same comms channel, and a little more should other ports need opening. Option 1 is much simpler, but has the problem that you must know what port to initially intercept. Option 2 effectly listens to all network traffic - so could examine web traffic running on tcp/12345, but unless you just want to reach by blocking the traffic, rather than communicating man-in-middle style, you work is cut out. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Where do you want to go today? Same as every day Windows Update. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Hartmeier Sent: Tuesday, June 29, 2004 12:11 AM To: cloper Cc: [EMAIL PROTECTED] Subject: Re: Possible Setup On Mon, Jun 28, 2004 at 03:16:15PM -0700, cloper wrote: > drop in log quick on $ext_if layer 7 "edonkey login" > drop in log quick on $ext_if layer 7 "aim send message" While for applications TCP is a byte stream protocol, packet filters (as the name implies) operate on a lower level. They do not see payload as an ordered stream, but see individual packets containing chunks of payload. In general, the payload is broken into chunks at arbitrary borders, chunks can arrive in non-sequential order and there can be gaps and overlaps. So, if you look at these individual packets as they pass through, you can't really 'look for the string "edonkey"' inside the stream. All you could do is look for the string inside one packet's payload. But that's generally useless, as a) the string could be broken into multiple packets by chance legitimately (not very likely, but it will occur) b) the sender can intentionally break the string into multiple packets to bypass the filter (very likely and very easy to do), send chunks out of order or create overlaps. c) there will be many unexpected false positives. If you had the above rules in place, you wouldn't have been able to send your email, would you? If you'd browse the lists archive over HTTP, you couldn't load the page containing this reply. There's an endless list of protocols that might legally contain these strings, and you can't rely on P2P protocols to not use arbitrary ports. If you'd be happy with that, this would be easy to hack into pf. Just add a char array to struct pf_rule, make pfctl parse the search arguments into rules, and have the kernel search for the arguments inside each packet. But given a)-c), it will prove useless, IMO. A P2P client can cause a string to get split up using one or two lines of simple userland socket option fiddling. I wouldn't be surprised if some of them already do that just for this purpose. If they don't, their next releases will for sure. Either you have a solid reliable solution, or you write code that will be useless in two months when the opponents catch up. So, you'll end up wanting to reassemble packets into streams before searching for strings. And you'll end up adding protocol awareness to the code (so a HTML document containing the sequence "edonkey login" sent over HTTP doesn't match). Restricting rules to ports won't help much, as P2P protocols intentionally use port 80 and HTTP-alike protocols exactly to get through firewalls and proxies more easily. You'll find that a single simple piece of code won't do, instead you'll need to implement stateful logic for all protocols you don't want to block outright. Once you're there, you'll find that doing this in kernel makes it a) harder (writing your own TCP reassembly in kernel is certainly more complex than just getting a stream in userland). b) more dangerous (mistakes easily produce remotely exploitable crashes or kernel compromises) compared to doing the same in userland as application level proxies. The most simple and reliable solution, in the end, would be to pick existing proxies for the protocols you need to forward (like squid for HTTP) and add the filtering there, if th
RE: Step effect?
If you said it was asymmetric line, I'd say that upstream was throttling downstream. But you don't get too many 110Mb/s ADSL lines... Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Where do you want to go today? Same as every day Windows Update. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jedi/Sector One Sent: Friday, March 12, 2004 12:09 AM To: [EMAIL PROTECTED] Subject: Step effect? Hello. Since I have installed OpenBSD as a bridge in order to shape the outgoing traffic to our ISP to 110Mb/s, I noticed something strange. The traffic grows smoothly up to 90Mb/s and then goes up to 110Mb/s but not smoothly at all, rather through steps. A look at the mrtg will make it clear : http://c9x.org/stepfx.png It happens every day and the step effect is often even more visible. The servers behind the firewall can push more than 110Mb/s with no problem. The curve was smooth before the AltQ bridge. The system is not loaded (load is 0.04), NICs are ti(4) and em(4), pf rules are basically "pass all" and all packets are going to the default queue which is 100% of the interface whose bandwidth has been set to 110Mb/s. RED is used, without ECN. Any idea about what could be wrong? Or is it a normal behavior with AltQ and RED? TIA, -Frank. -- __ /*-Frank DENIS (Jedi/Sector One) -*\ __ \ '/http://www.PureFTPd.Org/";> Secure FTP Server \' / \/ http://www.Jedi.Claranet.Fr/";> Misc. free software \/
RE: spamd vs extremely determined spammer
It's worth considering that a normal ping is around 60-odd bytes, so this is equivalent network load to being ping'd once a second. ...and anyone with a internet link will see continuous scans because of viruses that will likely be similar in bandwidth usage. Consequently, in this instance isn't using any more downstream than you would loose from normal internet 'noise', and the upstream is kind of equivalent to pinging out. I run a dozen pings a second 24x7 just to monitor/diagnose for network faults. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Where do you want to go today? Same as every day Windows Update. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Hartmeier Sent: Tuesday, March 09, 2004 12:50 AM To: Jay Moore Cc: Christopher D. Lewis; [EMAIL PROTECTED] Subject: Re: spamd vs extremely determined spammer On Mon, Mar 08, 2004 at 06:19:08PM -0600, Jay Moore wrote: > Thanks for your encouragement. Maybe I'm reading the pfTop output > incorrectly, but doesn't it say that _my_ resource cost on this > transaction was 335K packets and 13 MBytes of bandwidth? If so, I > wouldn't call this "no effect" on my resources. Obviously, it costs you as much bandwidth as it costs the sender, as any packet the peer sends, you receive and vice versa. But you don't waste as much CPU cycles, disk space and memory as the peer does. You might have delayed the entire queue of the sender by two days, who knows ;) 13MB in 48 hours (that's just 78 bytes per second) is considered a tiny stream by most people. If, for some reason, this means significant cost for you, don't run spamd. Just blocking the port with RST is cheaper. Daniel
RE: Remotely Counting Machines Behind Nat
I don't think PF can (currently) do this. A easier/better solution would be to run a socks server on one of the boxes and use socks on the others as clients. Then all the connections come from a single PC. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Where do you want to go today? Same as every day Windows Update. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nikolay Denev Sent: Tuesday, February 17, 2004 11:20 PM To: [EMAIL PROTECTED] Subject: Re: Remotely Counting Machines Behind Nat > Hello All, > > It says in the FAQ that using the 'reassemble tcp' scrub option keeps > an observer from guessing how many hosts are behind a NAT gateway. > The main thing I plan to use this for is to prevent my ISP from > finding out I have more than 1 computer connected, and then start asking me to pay more money > for extra IP addresses. Problem is that TCP SYN packets that go though my > NAT/pf box still have OS ambiguities. So my ISP can see that Windows, BSD, > and Linux TCP SYN packets are coming from my cable modem, therefore proving > that I have more than 1 machine, and that I need to be charged accordingly. > > Is there a way with pf to "wash" these ambiguities (window size, syn packet > size, etc) away so that all outgoing TCP packets look the same? Maybe even > set them to user-defined variables, as we already can with 'max-mss' > and 'min-ttl'? > > Thanks for your time. > Aaron > > Tell them that you have several operating systems, and you run them simultaneously under vmware. :) :) :) --nd
RE: quick on all pass/block?
Absolutely, but PF is so quick it will only really make any difference speed-wise if you're looking at 100's of rules and only _*if*_ you're have performance problems currently. The real advantage of quick is management, it's easier to read a ruleset top-down, than bottom up, especially when most of the rules don't apply. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Where do you want to go today? Same as every day Windows Update. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hsiao-lung Chang Sent: Sunday, February 08, 2004 10:21 AM To: [EMAIL PROTECTED] Subject: quick on all pass/block? Are there any disadvantages to using quick on all pass/block rules and reverse the order of all the rules? First match seems would be faster than last match... Thanks. Hsiao-lung -- Give the gift of knowledge! http://www.cksf.org/
RE: Prevent passive fingerprinting
And tweak Apache to lie for you too. ErrorDocument is there for a reason ;-) You'll need to hack Apache to make it lie about it's ServerTokens, and expose_php is another to add to the mix. I've managed to get netcraft _really_ confused. Of course none of these is any real _protection_, but just like a firewall, they may buy you more time to notice you're under attack. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Where do you want to go today? Same as every day Windows Update. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Wright Sent: Friday, February 06, 2004 9:41 PM To: [EMAIL PROTECTED] Subject: Re: Prevent passive fingerprinting > > is there any option for pf to prevent passive os fingerprinting for > > the clients behind an obsd nat-box? > > Use 'module state' option on your 'pass out' rule to randomize TCP ISN > generation and options 'reassemble tcp timeout modulation', 'random-id' > in your 'scrub' rule. I've found that this does very little in the way of preventing OS fingerprinting. It does stop outsiders from guessing your uptime, but that's about it. From what I can tell, most OS fingerprinting is based on the window size, ttl, SYN packet size, etc. p0f is very educational if you want to learn about it, especially the p0f.fp file (http://lcamtuf.coredump.cx/p0f.shtml). Setting min-ttl, or max-mss can help, but p0f usually can still guess correctly using fuzzy matching. I've found it much more effective to change some kernel variables. Below are some I've found useful on my FreeBSD systems: net.inet.ip.ttl net.inet.tcp.rfc1323 One of these makes more of a difference than the other, can't remember which: net.inet.tcp.recvspace net.inet.tcp.sendspace Here is a patch I've found to give you some control over TOS: http://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/001078.html Just remember that if you're going to all this trouble to disguise your OS, don't leave your OpenSSH banner on, like I did! :-) Aaron
RE: Filter on packet content
You might want to ask the company: "How could this impact my company profits?" Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Cammarata Sent: Wednesday, January 28, 2004 11:30 PM To: [EMAIL PROTECTED] Subject: Filter on packet content Hi all. My company recently underwent the first stages of a security review by a third-party. In this first stage they gathered information about our network via publicly accessible records and such, and did some port scans and some other light probing to see what they could detect on our network. The one thing that stuck out to me was this (from their report): "remote host does not discard TCP SYN packets that also have the FIN flag set." This note appeared for every visible server they probed. Now, I thought (based on the PF FAQ) that doing a scrub on incoming packets would stop this from happening. The first line (well, 2nd really) of my pf.conf is "scrub in all". Is something odd going on here? All of our servers they probed are behind the firewall, so the scrub rule is in effect for all of them. Is scrub just cleaning the packets instead of dropping them outright? PS. the actual first line of my pf.conf is: # It puts the lotion on the packets... ;)
RE: pf firewall box "stutters"
NIC Autoneg. Switch it off on the switch and fix the speed & duplex. Switch it off on the PC and fix the speed & duplex. good luck, Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scotty Sent: Sunday, January 11, 2004 3:02 AM To: [EMAIL PROTECTED] Subject: pf firewall box "stutters" Would love some suggestions on what to check to find out why one of my OBSD boxes is stuttering. By stuttering i mean network connectivity goes away but comes back.. It simply drops packets on both inside and outside interfaces, the interfaces as far as the switch is concerned stay up and running (i.e. they dont bounce) there are no errors (rx or tx) on the switch ports that these connect to. Running OpenBSD 3.3 w/PF. If i Disable pf while this happens i get same result (i.e. it doesn't matter if pf is enabled or disabled). I noticed that my clock is off, and it could be that the system is freezing, but i have yet to be able to verify that. Its running on a P4 1.8Ghz, Tyan MB, 256m ram, two fxp's and it ran fine for 8 months, it was rebooted (hard reboot, via remote power strip) last week and since then has done this twice when traffic gets "high" and high for this box is 3 to 4 mbps, it averages ~ 0.7mbps Nothing in the logs. What would you check next? -Scotty
RE: 3.4 upgrade
I don't recall there EVER being a non-backward compatible change to PF - can anyone correct me on this? (cross-posted to pf@ as they are the PF experts) Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven S. Sent: Wednesday, December 31, 2003 7:56 PM To: 'Bryan Irvine'; [EMAIL PROTECTED] Subject: Re: 3.4 upgrade I remotely upgraded some 3.2 machines with no syntax changes in pf. One of the machines is used as a multi-segment firewall, doing NAT, rdr, and standard pass/block and no changes were needed (that I have discovered). -Steve S. Bryan Irvine wrote: > I'm upgrading a 3.3 install to 3.4 tomorrow. The only part I'm > concerned with is getting pf back and running. I'm only using > standard pass/block, rdr, and antispoof. Is there any syntax changes > I need to know? Anywhere I can read up on changes to pf? > > --Bryan
RE: pf and smtp
Jay, You're a little off the mark - inbound email need never be blocked, outbound should only go to/through an ISP remailer to ensure that spamming isn't occurring. If a customer wants to directly _accept_ email from the net, who cares? They will get spam either way. If they want to sent it out the internet, the ISP has a moral duty to ensure that it's not spam - they are also in the position to immediately cut off that customer for breach of AUP. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay Moore Sent: Friday, December 26, 2003 8:05 PM To: Predrag Micakovic Cc: [EMAIL PROTECTED] Subject: Re: pf and smtp Predrag Micakovic said: > 1. Changed the rdr rule, did telnet to port 2025 from outside, > redirected to my server to port 25, works fine. Obviously, the ISP is > blocking port 25. Bad ISP. WRONG!... Good ISP - very, very good ISP. > 2. As for outgoing mail, I tried relaying to ISP smtp, works. Again, > ISP does not allow mail to be sent directly. You may not appreciate this yet, but your ISP is doing "the right thing". If all ISP's did as yours did, a significant part of the Internet's spam problem would be solved. > I must say, I do not like relaying to their mail server. I would > prefer to send mail directly. Why do you feel that way? Are you aware that the spam problem has forced many to block _all_ mail coming from dynamic IP addresses - regardless of whether they've ever sent spam or not. Using your ISP's mail server (assuming they are as responsible as they sound) will result in fewer blocked messages for you. Rgds, Jay Moore
RE: About using reassemble tcp/modulate state
Modulate state randomizes the sequence number generation. Sequence number generation technique and randomness is a dead giveaway for many Oses. So modulate state, for those OSes, is helps them look less like the OS they are, but this is NOT the purpose of modulate state. The purpose of modulate state is that poorly random sequence number generation is a vulnerability that can enable a hack to take over, close or spoof a TCP connection. In reality, there are many, many, many other ways to detect the OS, and properly randomising the seq. numbers only prevents one way. Modulate state is only recommended 'where required' because of the extra work and state that is required per connection, however to the credit of the OpenBSD team, I would recommend putting modulate state on all connections as it has been (mathematically) proved that OpenBSD has the best sequence number generation of any other OS, so the 'better' Oses can be raised up to the level of the best, OpenBSD :-) Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Wright Sent: Wednesday, December 24, 2003 4:06 PM To: [EMAIL PROTECTED] Subject: Re: About using reassemble tcp/modulate state I have a question about the statement below. Does the use of 'modulate state' really disguise the OS of computers behind your OpenBSD NAT/pf firewall box? I have not found this to be the case, but I don't know if this is because I'm using the FreeBSD port or not. Can someone clairify? Thanks for your time. Aaron > The sequence number generation on many OSes is poor, allowing for > easier attacks, and often OS guessing. With keep state PF keeps track > of the 'stage' of connection setup/teardown and also the CORRECT > sequence numbers midway through a connection, blocking inappropriate > packets. With modulate state PF translates the sequence numbers for > ones that are more random, making insertion and OS guessing more > difficult (in fact the OS will looks like the best one out there - > OpenBSD :-) )
RE: blocking nmap scans
Thanks Max, saved me some keystrokes.
I would say that for *host* Firewalling, like XP's builtin FW,
could be easily done with PF.
In fact writing such a tool is a pretty trivial, but very useful
ideae.g.
- block outbound echo-reply, unreachable and some other icmp.
- block outbound TCP RST packets ('closed port')
- allow outbound everything else, keeping state.
- allow inbound everything else, keeping state.
(this sounds back-to-front, but I this means that active ftp, and
other dirty protocol work fine, but portscanning is slw).
Does anyone know is TCP RST rate limiting (like ICMP) is possible
with 'stock' OpenBSD?
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Max Laier
Sent: Wednesday, December 17, 2003 3:42 PM
To: Afra, Ziad (London)
Cc: [EMAIL PROTECTED]
Subject: Re: blocking nmap scans
On Wednesday 17 December 2003 13:31, Afra, Ziad (London) wrote:
> So whats the syntax to block TCP connect() and SYN?
Okay, let's try to be a bit more polite ;)
If a service should be available to the internet, then you must not block a
(legal) TCP connect() to the port associated with this service, hence you
can not "block" a scanner using connect(). However, those scans will show up
in your logs. Additionally you can try to block portscanner by timeing, esp.
the new source tracking will assist you with that.
> Interesting that you say that given the fact that when I scan a linux
> redhat machine running iptables it doesn't report any ports open (when
> there are services running on ports < 1024).
No, iptables can not block portscanner and allow regular traffic at the same
time ...
And yes, building a firewall w/o (at least) basic knowledge of IP, TCP and
friends won't work - as long as you need something more then clicking
"enable firewall" in a fancy redhat or microsoft configuration tool, that
is.
--
Best regards, | [EMAIL PROTECTED]
Max Laier | ICQ #67774661
http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] #DragonFlyBSD
RE: blocking nmap scans
shutdown
:-)
Check the nmap documentation, then the pf.conf manual page.
You need to understand why what you are asking for isn't possible.
Also all the syntax is covered by "man pf.conf".
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Afra, Ziad (London)
Sent: Wednesday, December 17, 2003 12:32 PM
To: [EMAIL PROTECTED]
Subject: RE: blocking nmap scans
So whats the syntax to block TCP connect() and SYN?
Thanks
Z
-Original Message-
From: Tiago Pierezan Camargo [mailto:[EMAIL PROTECTED]
Sent: 17 December 2003 09:47
To: [EMAIL PROTECTED]
Subject: Re: blocking nmap scans
> block in log quick on $ext_if inet proto tcp from any to any flags
> FUP/FUP
> block in log quick on $ext_if inet proto tcp from any to any flags
> SF/SFRA
> block in log quick on $ext_if inet proto tcp from any to any flags
> /SFRA
Those rules only block FIN, Xmas and NULL scans. TCP connect() and
SYN scans work as usual.
--
Tiago Pierezan Camargo
(o_.' The boozy penguin says:
//\c{} "VI VI VI The editor of the beast."
V__)_
RE: best hardware for pf
Other people filter at close, or better than a gig with multiple NICs. With GigE NICs you are generally talking quality, and with quality NICs you get lots of freebie stuff - checksum generation, decent buffer sizes, efficient bus use etc. They know that their customers don't want cheap, they want fast - they don't want the backups to impact the customer experience for 2 hours, just for a measly extra $50. Recommendations: - Intel or other 'quality' manu. - dedicated 66mhz bus, if possible. CPU speed has little impact, though the little time that the frame is actually inside OpenBSD will be halved by doubling the clock speed. The thing is, PF is designed so that's not a large proportion of the time - if the NIC is any good. A search for "pf gigE Henning" is likely to bring up some interesting stuff. e.g. http://www.benzedrine.cx/pf/msg03147.html that has figs like: > No firewall:939 Mbits/sec throughput > Firewall: 785 Mbits/sec throughput But this 'problem' (17% PF slowdown) has plenty of possible solutions, including changing both NICs to Intel, using the device polling patch, etc. As so many factors count, it's prob best to get a test/loan box and then see what vmstat says while it's busy. Dom PS. "particularly DDoS-prone service" == online gambling ? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ben Sent: Tuesday, December 16, 2003 5:38 PM To: [EMAIL PROTECTED] Subject: best hardware for pf Hi, Anyone have experience with filtering at close to 1Gbit using pf? What would end up being the limiting factor in such a system? CPU, bus bandwidth or maybe something else? I'm looking to take some filtering load off of our routers for a particularly DDoS-prone service. Thanks, ben.
RE: Source Tracking in PF
Cheers Ryan!
This is a big step towards DDoS proofing OpenBSD!
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ryan McBride
Sent: Monday, December 15, 2003 12:24 AM
To: [EMAIL PROTECTED]
Subject: Source Tracking in PF
I just committed code which adds support to track stateful connections by
source IP address. This allows a user to:
- Ensure that clients get a consistent IP mapping with load-balanced
translation/routing rules
- Limit the number of simultaneous connections a client can make
- Limit the number of clients which can connect through a rule
As always, the more people who test this and provide feedback, the happier I
am. Read below for details.
-Ryan
SYNTAX:
The 'sticky-address' keyword applies to translation rules; the translation
address will be selected from the list, but once a client makes a
connection, all subsequent connections are translated the same way.
nat on $ext_if from $int_net to any -> \
{ 10.1.2.1, 10.1.2.3 } round-robin sticky-address
Similarly in the following case, connections to a server are mapped
randomly, but all connections from a client are mapped the same way.
rdr on $ext_if from any to $ext_if -> \
{ 192.168.0.4/30 } random sticky-address
In the case of tracking states per rule, the syntax is slightly different.
The 'source-track' state option is used to enable tracking, limits can also
be set there: 'max-src-states' limits how many states from a single source
can exist simultaneously and 'max-src-nodes'
limits how many source nodes can exist (effectively this is a limit on how
many clients can connect at once).
The following rule allows a maximum of 1000 source ip's to connect to a
webserver, each with a maximum of 3 simultaneous states:
pass in on $ext_if proto tcp to $webserver port www flags S/SA \
keep state (source-track, max-src-states 3, max-src-nodes 10)
By default, the source node is removed when all the states which reference
it are removed. However the timeout 'src.track' regulates how long the
source node is retained after all it's states have died.
set timeout src.track 900
A list of src nodes can be retrived with pfctl -sS, pfctl -vsS; pfctl -vsi
provides statistics on src-node useage (similar to the statistics provided
for states)
RE: About using reassemble tcp/modulate state
[ If playing with any of this the first thing to check is to read the pf.conf man page ] TCP connections have sequence numbers to prevent loss/duplication of data by the network, or insertion of data by a 3rd party. The sequence number generation on many OSes is poor, allowing for easier attacks, and often OS guessing. With keep state PF keeps track of the 'stage' of connection setup/teardown and also the CORRECT sequence numbers midway through a connection, blocking inappropriate packets. With modulate state PF translates the sequence numbers for ones that are more random, making insertion and OS guessing more difficult (in fact the OS will looks like the best one out there - OpenBSD :-) ) synproxy state is the next 'step' in this protection, as PF actually does the initial TCP handshake (SYN,SYN-ACK,-ACK) without involving the server, and only forwarding the (modulated) connection setup packets once the client complete the 3-way handshake with PF. Fydor's wrote and excellent paper on the whole thing, see http://insecure.org/nmap for the link. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Toni Riekkinen Sent: Friday, December 12, 2003 11:52 PM To: [EMAIL PROTECTED] Subject: About using reassemble tcp/modulate state I've read from archives that there has been some problems with using i.e: scrub on $ext_if all random-id reassemble tcp Is it safe to use this, or will I get some sort of connection problems from different clients (Suse, Windows..)? I can't use it in production environment if not knowing for sure and I just don't know how to test it. I'm using OpenBSD 3.4 as transparent bridge to protect DMZ (with email and webservers), and I'd like the idea about protecting my servers with timeout modulation to make it kind of harder to find out what OS's I'm using behind my fw. What is the difference between using "scrub all reassemble tcp" and using "modulate state" in incoming traffic rules, i.e for webserver in DMZ: pass in quick on $ext_if proto tcp from any to $webserver port 80 \ flags S/SA modulate state Best regards, ++Toni
RE: Anything approximating ipfw 'limit' mechanism
Hey Frank, you responded to my question along these lines a couple of weeks ago, small world :-) We're actually both right, because my original answer was incomplete: You _can_ have a rule per /15, and connection limit each rule. Currently you only have 1000 queues however :-( You're right because his real requirement (and mine!) would be solved much better if resource allocation (connection & bandwidth) could be defined with DDoS in mind. e.g.: "If the state table has >100 connections from anyhost/24:any to mysrv/32:80 do not allow any more that match this criteria." I guess this could be done by having a (smarter) userland configurable state management engine - performance impact of such resource protection I'd guess would be harsh, compared to normal lightning packet throughput, but I for one am convinced such protection is worth the higher memory/CPU drain. I think I'll start some kernel hacking when I'm done re-engineering devitto.com mail. PS. I don't believe that anything else can do this kind of thing either (maybe packeteer?) - in particular being able to cut the whole internet into class-Cs and fairly share the connections/bandwidth available. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RE: Anything approximating ipfw 'limit' mechanism
I know where you're heading with this, and every pass rule can
specify the number of connections, as well as other things.
man pf.conf for details, but this was taken right from it:
pass in proto tcp from any to any \
port www flags S/SA keep state \
(max 100, tcp.established 60, tcp.closing 5)
Enjoy.
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Yusuf Goolamabbas
Sent: Thursday, December 11, 2003 12:31 PM
To: [EMAIL PROTECTED]
Subject: Anything approximating ipfw 'limit' mechanism
Hi, Is there anything planned for pf or available right now which can
approximate FreeBSD's ipfw 'limit' mechanism
limit {src-addr | src-port | dst-addr | dst-port} N
The firewall will only allow N connections with the same set of
parameters as specified in the rule. One or more of source and
destination addresses and ports can be specified.
Nice to have, limits per /24. ie, N connections from any or defined /24
coming in
Regards, Yusuf
--
If you're not using Firebird, you're not surfing the web
you're suffering it
http://www.mozilla.org/products/firebird/why/
RE: pf <---> iptables
On the speed front, I've saw a PF user post complain that he can only get 980kb/s with PF and GigE interfaces. Henning, I believe pointed out that that is 98% of maximum for the media speed, and most other firewalls are *a lot* slower on the same hardware. Others have gotten > GigE filtering with the right hardware, but it's mostly about getting good interface cards on a good mobo and a moderately quick CPU. Interrupt load and bus bandwidth is almost always maxed out before the CPU gets anywhere near 100%. This is because Intel spend millions each year convincing us we need at least a 3GHz processor in order to write an emails... Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philipp Buehler Sent: Wednesday, December 10, 2003 7:08 AM To: Arno Hechenberger Cc: [EMAIL PROTECTED] Subject: Re: pf <---> iptables On 09/12/2003, Arno Hechenberger <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > Is anyone out there who knows real arguments for iptables or pf ? I > should evaluate a packet filter for acompany with 73 internet accesses > points where one of this should become suitable. > > Thanks in advance for "real" arguments. Use something one can understand a config file by simple reading - oh wait, iptables has no config file. And damn this non-obvious options.. 99% of all packetfilter-problems come from misconfigured filters - not from problems IN the filter. So get something one can understand. Performance? Oh well, at least for typical WAN packetrates "at home" or "medium sized company" (like up to T3) it's already difficult to buy something that's reliable and NOT bored to death :-). Maybe you get the point.. ciao -- pb@
RE: ALTQ/PF throttling?
(thanks so far all btw) Following on, after some playing around I can create 20,000 rules (!!!) but pfctl just hangs with 30,000 or more Anyone know what the max number of rules is, and how to change it? Obviously stuff like available RAM may be critical, but from the FAQ I'll know when I hit that limit when I get a panic :-) I read yesterday that only 1024 queues are available - and can check the change to bang this up, however I'm lost where the rule limit is. FYI, I want to cut up the entire net into (as small as possible) chunks with individual connection limits and bandwidth restrictions. Thanks in advance, Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jedi/Sector One Sent: Wednesday, November 19, 2003 5:58 PM To: Dom De Vitto Cc: [EMAIL PROTECTED] Subject: Re: ALTQ/PF throttling? On Tue, Nov 18, 2003 at 10:22:43PM -0000, Dom De Vitto wrote: > Does anyone know/have a way to throttle (delay or drop) on: > b) Limit the number of connections from a single host. > b) Bandwidth of 'any' individual client being greater than some value. Unfortunately I don't think PF is able to handle per-client rules yet. Or you have to create as many rules as possible client IP address (!). -- __ /*- Frank DENIS (Jedi/Sector One) <[EMAIL PROTECTED]> -*\ __ \ '/http://www.PureFTPd.Org/";> Secure FTP Server \' / \/ http://www.Jedi.Claranet.Fr/";> Misc. free software \/
ALTQ/PF throttling?
[ This is cross-posted to misc@ and pf@, as I'm open to non-PF ] [ solutions and I feel that both groups will benefit from any ideas ] Hi all, Does anyone know/have a way to throttle (delay or drop) on: a) Number of active connections matching a particular rule. b) Limit the number of connections from a single host. b) Bandwidth of 'any' individual client being greater than some value. Reasons: a) Is so that a web server never becomes flooded with more connections than it (or it's backend) can handle. b) Is so that a single client cannot use more than x% of (a). c) Is so I can limit the bandwidth any individual host can use. Any ideas folks? Can mod_throttle or anything else do some of this? Thanks, Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RE: High availability and load balancing!
-current, which will become 3.5. 3.4 is already on CDs! And if you pre-ordered you'll be getting/have got yours real soon. Everyone else has to wait until it hits the FTP servers on (around) the 1st Nov. The quickest way to play with this stuff is to wait for it to make the next snapshot and install that. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of amirm Sent: Sunday, October 19, 2003 1:22 AM To: [EMAIL PROTECTED] Subject: Re: High availability and load balancing! SA-WET!!!, So will this be 3.4 or 3.5 > Hi, > > I've just read this and I would like to share the news with PF fans. > Quoting from > http://www.deadly.org/article.php3?sid=20031018101733 > "Common Address Redundancy Protocol Allows multiple hosts to share an > IP address, providing high availability and load balancing." > Original and complete post by Ryan McBride (mcbride@) available at > http://marc.theaimsgroup.com/?l=openbsd-misc&m=106642790513590&w=2 > > Enjoy ! > > > Ed >
RE: PF and Snort Working together
IIRC Snort, tcpdump etc use the BPF interface, which COPIES the matching packets into buffers supplied by the application. PF (presumably) is "behind" the BPF interface in the order it gets the packets, so even when blocking all packets in PF, snort/tcpdump etc. still get to see a COPY of the packet first. The important bit is that the applications are only seeing copies of the packets, whereas PF has access to the original packet in kernel memory - so can modify or even delete the packet before it gets processed by the kernel. e.g. the order is: 1) Physical driver copies packet from the wire into kernel memory 2) BPF copies the packet into the application memory 3) PF plays with the packet or even deletes it totally. 4) the kernel then (if not deleted) routes etc. the packet. This my blurry view of how things happen. Dom Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, October 13, 2003 6:44 PM To: [EMAIL PROTECTED] Subject: PF and Snort Working together I have a question about running snort on openbsd 3.3 with pf and nat, and I have not got an answer back from the snort folks so I was hoping someone here might be able to give me guidance, here is the email below I sent to the snort list. So if anyone out there is running snort on their firewall I would appreciate the help I know this is not ideal and it really should be on a seperate box but this is on a home dsl link just so I can get experience with snort. I have just come across some articles stating that if you are running snort on your firewall as I am and monitoring the external interface. It all is setup correctly but just because of the way PF acts if you drop it at the external firewall interface snort never see's the packet can someone confirm this. I have seen a number of articles and email stating that snort see's all traffic before it is ever filtered by PF and now have come across others that say the exact opposite. Can someone clear this up?
RE: PF debugging
> > I'm looking for tips & tricks to write patches for PF. > > The biggest problem is debugging a live kernel. > > How do you do ? VMWare ? > > good 'ol printf and ddb '-) > Bah! Fancy stdio stuff? "Real Men" use write(2,) ...and that's only when you don't have access to /dev/kmem :-) Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RE: Speed issues with bridge firewall
Damn straight. That's 94% of wire speed! I believe the fastest appliance out there currently is the Cisco PIX535, coming in at a max of 1.7gb/s, but the other firewall appliances around are way behind that and are well sub-1gb/s. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henning Brauer Sent: Monday, September 01, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: Speed issues with bridge firewall On Mon, Sep 01, 2003 at 12:20:04PM -0500, Mathew Binkley wrote: > The firewall box is a SuperMicro 1U box with ServerWorks GC-LE > chipset, > dual 1.8 GHz Xeons, 1 GB RAM, 40 gig hard drive, and two gigabit NIC's > (one Intel, the other NatSemi 83820). OpenBSD doesn't support SMP, so > only one of the processors is being used. dmesg would help. my bet is on the nge(4), tho. at GigE - esp. when you run jumbo frame - it is not very efficient. I'd be interested in figures with a second em(4). > Results: > > No firewall:939 Mbits/sec thoroughput > Firewall: 785 Mbits/sec thoroughput that's already pretty impressive... check systat vmstat while doing the tests. I bet the interrupt #s kill you. check especially which device causes how many. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Looks like we've got a live one....
You'd better be blocking MS RPC PDQ! Oh, and expect a flood of downloads from ftp.openbsd.org once people figure Microsoft's definition of "Trusted Computing" :-) Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RE: pf and bridge question
Ok, lets go through this... > Hi, > > I have an OpenBSD 3.3 firewall which acts as a transparent bridge > between our network (not NATted) and a router giving access to the rest > of the world. The bridging interfaces are configured without IP address > and a third (management) NIC is configured with an IP address inside our > network's address space. A colleague of mine claims that this can lead > to confusion in the routing/bridging code of the firewall and possible > corruption of the arp table. He says that the management interface He is talking crap. PF (or any other firewall I know of) doesn't know anything about arp tables, or even arp packets. You _can_ get issues if you have two bridge interfaces, as PF only has one kernel table. > should never be in the same logical or physical network as one of the > two sides of the bridge, i.e. it should have an address in rfc1918 space > and be physically connected to different networking hardware. This is because most switches are not security oriented and should be considered dumb hubs on all ports, all vlans. If anyone says this isn't so I'll beat them with enough references to flood a STM64... > I have difficulty in understanding how this could be true and he cannot > give me an explanation other than that he has had trouble with this in > the past (running older versions of OpenBSD 3.2 with ipf). Can someone > here enlighten me as to whether this is really a possible problem and if > so how exactly some sort of corruption/glitch could happen? Magic? bad administration? If Henning or Daniel haven't seen this behaviour, I doubt it exists. > Thanks a lot, > > Marc > > P.S. Naturally I am aware of the fact that having the management > interface on a separate NATted network with it's own protection is a > good thing security-wise, so that's not really my question. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RE: Re[2]: pf and altq couple: before and after merge
I think an interesting example that people are fishing for below is
any ethernet broadcast packet going through an openbsd bridge,
one packet goes out many (all) interfaces.
Of course, which do you allow the reply from?
Even worse is when you have:
client->(bridge0)->router->(bridge1)->server
Now a packet can not only get replies from any interface in bridge0,
but can generate state *twice*, once per bridge.
ATM this doesn't work - bridge1 packets are dropped as dups.
So if PF needs to understand what i/f a reply can come from, it that
needs to also tag the state with the right bridge info.
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Alexey E. Suslikov
Sent: Tuesday, August 05, 2003 8:27 AM
To: Daniel Hartmeier
Cc: [EMAIL PROTECTED]
Subject: Re[2]: pf and altq couple: before and after merge
Tuesday, August 5, 2003, 12:36:02 AM, Daniel Hartmeier wrote:
> On Mon, Aug 04, 2003 at 11:35:13PM +0300, Alexey E. Suslikov wrote:
>> keepstated connection's packets silently pass all interfaces and all
>> directions, so we just can't REASSEMBLE the queue to take control
>> over them. the only controllable option is the connection's state.
>> but there are TOO MANY packets matching this STATE and they are
>> DIFFERENT.
> Given that there is no working multipath routing in OpenBSD, all
> packets of one forwarded connection usually enter through one
> interface and leave through one other interface. At least in my simple
> corner of the world :)
hmmm... you can dup-to them to multiple destinations.
> If you want, you can create state on both interfaces, there's nothing
> wrong or obscure about that. A forwarded packet will match one of the
> states on the incoming interface and the other on the outgoing. You
> can queue to two different queues (one for each interface) with those
> two states.
yes, i already heard previously: "it is possible to have multiple states
for the same connection". but this mechanics needed to be explained.
this is your "Prioritizing empty TCP ACKs with pf and ALTQ" example:
ext_if="kue0"
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def } queue q_pri
priority 7 queue q_def priority 1 priq(default) pass out on $ext_if
proto tcp from $ext_if to any flags S/SA \
keep state queue (q_def, q_pri) # 01
pass in on $ext_if proto tcp from any to $ext_if flags S/SA \
keep state queue (q_def, q_pri) # 02
"Both incoming and outgoing TCP connections will pass by those two
rules, create state, and all packets related to the connections will be
assigned to either the q_def or q_pri queues. Packets assigned to the
q_pri queue will have priority and will get sent before any pending
packets in the q_def queue". this is your statement.
assume we have incoming packet matching rule 02. after this we will have
"keepstated by the rule 02" connection which will not match any rules
lately, because it will silenty pass as of keepstated nature. this is my
statement. but this is wrong statement as i know what "it is possible to
have multiple states for the same connection". i just want to remove
this contradiction. please, explain.
> ALTQ doesn't queue incoming packets (they are processed immediately,
> as they arrive), so you can only queue outgoing packets on those two
> interfaces (that was true before the pf/altq merge, too).
just for example: incoming packet on some ext0 and outgoing on some int0
- the same packet. you can't queue it on the ext0, but can on the int0.
> You could split your packet filter and ALTQ setup into two separate
> machines, the first one doing the packet filtering statefully, the
> second one using pf completely statelessly just to do the ALTQ
> classification. It would be forced to create states and assign all
see PREFACE in my original post: there are no questions about stateless.
> Maybe (very likely, even) I'm just doing simple and naive
> classifications, can you give an example of setup that you wanted to
> do but would require splitting the stateful filtering and
> classification? Something with a real and common use, not some
> far-fetched theoretical example?
RE: stateful filters affect queue filters
Henning, Can you expand on "I consider this flags filtering stupid.", do you mean using S/SA is good, bad, or do you mean something else? Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henning Brauer Sent: Tuesday, July 22, 2003 2:43 PM To: [EMAIL PROTECTED] Subject: Re: stateful filters affect queue filters On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote: > Also note that most of your rules are a bit "loose" as far as TCP > goes. > The upside is that they'll pick up existing connections when you > reboot/reconfigure the firewall, but you may want to get more control > over which direction connections are initiated from by using "flags > S/SA" with all of them. It depends on your situation; this is just a > heads up. I consider this flags filtering stupid. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: Syntax problem with pf on 3.3-STABLE
I've had a really nasty "viral cold infection" all week, but this
posting really cheered me up!
Dom
"Some days you're the monument, some says the pigeon..."
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Wouter Clarie
Sent: Thursday, July 17, 2003 9:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Syntax problem with pf on 3.3-STABLE
On Thu, 17 Jul 2003, Alejandro G. Belluscio wrote:
> altq on $ext_if priq bandwidth 1Mb queue { q_pri, q_int, q_def, q_low
> } queue q_pri priority 5
> >queue q_int priotity 4
> queue q_def priority 3 priq(default)
> queue q_low priority 2
priority instead of priotity?
RE: Only one PF table for all connections?
Just to confirm: Q. Duplicate packets get dropped by PF ? Q. Are these duplicates logged somehow, or do they just not match the rules or the state table, and so get logged in your bottom "block in log all"? This is a dumb question, but. ...couldn't PF just pass duplicates, e.g. if it sees a SYN that's already in the table don't add it, and if it sees a SYNACK when the state says it's already seen a SYNACK, likewise. - I have a feeling there is a good reason for not doing this, but can't recall it! Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Hartmeier Sent: Thursday, July 03, 2003 5:07 PM To: Cedric Berger Cc: Dom De Vitto; [EMAIL PROTECTED] Subject: Re: Only one PF table for all connections? On Thu, Jul 03, 2003 at 05:52:48PM +0200, Cedric Berger wrote: > You're right, 2 bridges on the same machine cannot work with PF. That > was discussed before, without conclusive solution. I was in favor of > tying states to interfaces, but there was objections. Maybee we need a > keyword like "lock" or "attach" or "tie" to attach a state to a given > interface, which would solve your problem (and other problems) I agree it should be done, but we'll have to solve a couple of issues first. For instance, the NATLOOK ioctl would require the caller to pass the interface name for the state lookup (otherwise it might find the wrong state). There are several tools that use NATLOOK by now (ftp-proxy, the ssh patch, squid and other proxies in ports). We'll have to adjust them all. For instance, ftp-proxy would probably require a new command line switch to specify the interface name for the NATLOOK ioctl (it doesn't need to know the interface for anything else, and I see no way it could figure it out without an additional switch). IMO, it's well worth the effort, but it will be some effort :) Daniel
Only one PF table for all connections?
Problem
I've a filtering bridge, which connects in/out to another firewall
(yea, yea, paranoid I know) and the local lan.
I run snort on the various bits of network cable, watching the outside
and inside bridges, and cross-correlating.
My problem appears to be that there is only one state table in the
kernel for all PF connections, and so I need to ensure that only one
interface creates state table entries.
Hmmm. I'll explain by flow:
1) I send a tcp SYN from my PC to my PF-bridge on fxp0 (bridge0).
2) The bridge sends this to my firewall on fxp1 (bridge0).
3) The firewall sends this on to the PF-bridge on fxp2 (bridge1).
4) The bridge sends this to my gateway out of fxp3 (bridge1).
Now I can add pass rules, without keep state, on anywhere, but if I
put a keep state on an i/f on bridge0, naturally it sees the same
packet on bridge1 and drops it, because it's expecting a reply, not
a duplicate.
Does this sound "right", and does anyone know how I can get around
it? I'd like to keep state on all rules, if possible.
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Daniel Hartmeier
Sent: Thursday, July 03, 2003 12:39 AM
To: Adam Getchell
Cc: [EMAIL PROTECTED]
Subject: Re: Adaptive timeouts
I'm not sure I understand what you meant exactly. The age of a state
(the time since it was created) doesn't matter at all. Only the number
of states does.
The number of states (that exist at the given time) decides the scaling
factor. As long as the number is lower than adaptive.start, the factor
is 100%. If it reaches adaptive.end, the factor is 0%. In between, the
factor decreases linearly as the number of states increases. So, in the
example
> set timeout { adaptive.start 6000, adaptive.end 12000 }
states factor
1 100%
1000 100%
5000 100%
6000 100%
750075%
900050%
10500 25%
120000%
Each state entry uses a specific base timeout value, depending on
protocol and condition of the state (like, an established TCP connection
uses a base value of tcp.established, 86400 seconds by default). For
each state, its particular base value is multiplied by the factor
calculated above (same factor for all states).
If you specify adaptive.start/.end in a rule (as compared to the global
settings), the scaling for states created by that rule is based on the
number of existing states created by that rule and the specific start
and end values (and the total number of states and the global start/end
values are irrelevant for states created by the rule, only one scaling
factor gets applied, not both the global and per-rule one).
Maybe it's easier to understand if I describe the algorithm which
calculates when a given state entry expires (this is recalculated
whenever an input parameter changed):
1) does the rule that created the state have its own adaptive.start
and adaptive.end values?
a) if so, use those two values and the number of states that
currently exist that were created from the same rule
b) if not, use the global values, and the total number of
states that currently exist (created by any rule)
2) calculate the scale factor, based on the number of states, start
and end, either from a) or b)
3) check the protocol and condition of state entry to get the
base timeout value (tcp.first, tcp.opening, tcp.established,
etc.), note that a rule can also override the global timeout
values with its own, applying to all states created from the
rule
4) multiply the base value with the factor, this is the number
of seconds that the state entry is kept alive without matching
a packet
5) add this number to the last time a packet matched the state,
this is the time when the state should expire
6) if that time lies in the past, remove the state
So, the age of a state entry is irrelevant, what matters is the last
time a packet matched the state. And how many other states exist (scale
factor). And the base timeout value.
A flood of new connections can't kill existing established connections,
since they'll get the same scale factor, and tcp.first/tcp.opening is
much smaller than tcp.established. But additional new connections can
cause an established _idle_ connection to get removed earlier than it
would be without additional connections. But that's the point :)
HTH,
Daniel
RE: Distributed port scanning using OpenBSD's packet filter
I don't like to rain on such a neat breakdown/howto for PF
loadbalancing, but this is really macievellian, and means you can only
do state-respecting scans, no SFRU etc.
I'd also do:
set limit { states 10, frags 5 }
and diddle with the PF timeouts, in case the dest host is firewalled.
It would be easier (for TCP scanning) to:
- portscanner sends spoofed SYNs from x.x.x.a/c/b to whatever,
at your max upstream rate.
- PF passes the packets out WITHOUT keeping state.
- PF "block return-rst in log on $ext_if" 'SA' packets coming back in.
- You check the PF logs for ports that reply :-)
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Ste Jones
Sent: Saturday, June 28, 2003 12:09 AM
To: [EMAIL PROTECTED]
Subject: Distributed port scanning using OpenBSD's packet filter
Network Penetration
networkpenetration.com
Copyright (c) 2003 Ste Jones
[EMAIL PROTECTED]
Distributed port scanning using OpenBSD's packet filter (Another good
reason to use OpenBSD)
By using openBSD's packet filter pf one can utilize the NAT address
pools added into OpenBSD 3.3 to aid in distributed port scanning.
How it works
http://www.openbsd.org/faq/pf/pools.html#nat - NAT Address Pool
As the text explains NAT can be used in a large network to split
outgoing connections over multiple source IP addresses. Under normal
circumstances NAT is
normally used to hide a internal network behind a single external public
IP address. By using multiple external IP addresses a host on the
internal network
can port scan with multiple source IP's.
Technical Breakdown
::-
1. Port scan from internal network: send a SYN packet to a target to
initiate a connection. The packets source IP address for example
192.168.0.1.
2. Packet passes through NAT gateway: The packets source IP address is
now changed to the external IP assigned to the NAT gateway. Each new
connection passing
through the gateway has its source IP address translated to the one /
many IP addresses assigned to the NAT gateway. For example 1.1.1.*
3. The packet reaches the host and reply is returned to the NAT gateway.
The packet returned has a destination IP address of the external
interface on the NAT
gateway. So in this example 1.1.1.1
4. The NAT gateway translates this packets destination IP address back
to 192.168.0.1 and the packet is sent to the source.
OpenBSD 3.3 Pf setup
Replace your existing NAT rule for the one below. This enables PF to do
NAT translation over multiple source IP addresses. It has its problems
with things
such as web page connection tracking. Check the OpenBSD FAQ for more
info.
nat on $ext_if inet from any to any -> { x.x.x.a, x.x.x.b, x.x.x.c }
You will probably have to tweak some of your other rules to get it
working correctly
You will also need to edit your /etc/hostname.interface file
inet x.x.x.a 255.255.255.0 NONE
inet alias x.x.x.b 255.255.255.0 NONE
inet alias x.x.x.c 255.255.255.0 NONE
This is all performed by PF's stateful connection tracking thanks
guys
Note: I presume this would also work on a single machine running pf :)
Thanks to HacK of LuB for letting me abuse his firewall
original paper can be found at www.networkpenetration.com
RE: synproxy problems with bridge
> And even more thanks for an extraordinary packet filter. > I don't know what I would do without it. > > Kevin Here! Here! Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RE: pfsyncd ( WAS RE: )
http://www.greyhats.org/openbsd/openbsd.html#pfsyncd has all you need. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: OTERO Hernan Gustavo EDS [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 9:05 PM To: 'PUB: Dom De Vitto'; [EMAIL PROTECTED] Subject: RE: pfsyncd ( WAS RE: ) Is this in the current snapshot ?? -H -Original Message- From: PUB: Dom De Vitto [mailto:[EMAIL PROTECTED] Sent: Martes, 10 de Junio de 2003 04:58 p.m. To: 'OTERO Hernan Gustavo EDS'; [EMAIL PROTECTED] Subject: RE: pfsyncd would be a good place to start, I believe. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of OTERO Hernan Gustavo EDS Sent: Tuesday, June 10, 2003 7:24 PM To: '[EMAIL PROTECTED]' Subject: Guys, Some buddies and me want to put hand´s on making some type of table sharing in the PF code. Actually, it does not seem a too hard work , because pf code is really well done. But my actually question is, There is some work in progress in this area?. And in second place, if the sharing tables works fine, we are thinking to do some type of Firewall clustering, but that is really hard work so it must wait. Regards Hernán
RE:
pfsyncd would be a good place to start, I believe. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of OTERO Hernan Gustavo EDS Sent: Tuesday, June 10, 2003 7:24 PM To: '[EMAIL PROTECTED]' Subject: Guys, Some buddies and me want to put hand´s on making some type of table sharing in the PF code. Actually, it does not seem a too hard work , because pf code is really well done. But my actually question is, There is some work in progress in this area?. And in second place, if the sharing tables works fine, we are thinking to do some type of Firewall clustering, but that is really hard work so it must wait. Regards Hernán
FW: pf/altq on a fast link
"samt", [EMAIL PROTECTED] says (below) that etinc no longer supports OpenBSD, so http://nomoa.com/bsd/miscellania.htm is now incorrect - I guess? Can I suggest you remove the etinc bit and add a line about PF in r3.3 having ALTq built-in - the PF mailing list is mostly ALTq stuff! Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Sent: Sunday, June 01, 2003 2:20 PM To: [EMAIL PROTECTED] Subject: Re: pf/altq on a fast link [EMAIL PROTECTED] (Jason Houx) wrote in message news:<[EMAIL PROTECTED]>... > Good Day Anthony and pf list > > As everyone already covered some very good points and some good links. > I thought I would pass along something that would get you started. > Basically I work for a ISP/LEC and we have started using OpenBSD for > traffic shaping on customers that we will run some fiber to and put a > OpenBSD box at one end to regulate the traffic. IE GigE to a customer but > we cap their bandwidth as if they where buying T1's, DS3, ext (fiber > converters are nice!). This example does do some privatization and > regulates bandwidth. If you get serious about bandwidth management, take a look at something a bit more advanced at a very affordable price. Our software "sniffs out" p2p traffic no matter what port its running on, can manage 1000s of policies/hosts individually, automagically shapes TCP traffic (window reduction to reduce overall queue depth in the network), allows control of virtual hosts by name, has controlled burst definitions, bandwidth templates, etc. With a product like ours you can control the chaos of p2p with 1 rule (port limiting doesnt work, because the clients can run on any port now, in fact kazaa now defaults to port 80), and offer tiered services easily, creating new revenue streams in the process. All with a handy HTML interface and integrated Traffic Analysis tool. It pays for itself the first month. Its available as an add-on to Freebsd or as a standalone appliance. We used to support OpenBSD, but sadly there isnt enough market to justify the effort. www.etinc.com
RE: pf/altq on a fast link (etinc is not as good as freeware)
It's quite clear, from the prior discussion, that etinc is inferior. Anyone reading the archives will see this simply from the number of people on this list who have put it down, but only Dennis ([EMAIL PROTECTED] !!!) actually thinks it's any good. Nobody else does, everybody else thinks it's way too expensive for what it does. Now go away dennis, before you cause us to pick further holes in your product. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Sent: Thursday, June 05, 2003 5:25 PM To: [EMAIL PROTECTED] Subject: Re: pf/altq on a fast link [EMAIL PROTECTED] (Kent R. Spillner) wrote in message news:<[EMAIL PROTECTED]>... > Dennis wrote: > > "FREE" isnt really cheaper when you spend $1000's worth of your time > > to make it work, and then end up with an inferior solution when > > you're done. > > -1, Troll > > This is a pf list. pf does not require investing $1000s worth of your > time to "make it work." pf is not an inferior solution. > > Go peddle your "p2p sniffer" and your lies elsewhere. openbsd-pf is a good firewall. But as a bandwidth management tool it's quite inferior. Priority queuing is an archaic, inferior technology, if you can call it a technology. The subject here is "pf/altq" on a fast link. How does it perform on a gigabit wire with stats gathering and limits configured for 5000 hosts? How does granular, duration controlled bursting work? does it automatically pace traffic to reduce queue depths when a point of congestion is reached? There's nothing wrong with an open-source firewall. But an ISP need a separate bandwidth management box. Anyone that thinks they can do it with the free stuff is settling for a trivial solution that will cost them in the long run. The ethical thing to do, when someone asks about using pf/altq for a high-volume business, is to tell them the truth. They need something a bit better. DB etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc
RE: pf/altq on a fast link
[ Please bear in mind that this scathing rebuff of etinc, ] [ as well as the others will go into the archives "forever", and show ] [ up in google in a couple of days - ooops. ] If anyone even *thinks* about buying this, consider the statement: "It pays for itself the first month." Clearly this would depend on your bandwidth costs, but unless you run an ISP in ANTARCTICA, where I would expect 9600 to be expensive, this statement is obviously not always true. and this from the web site: "...there is absolutely no telephone support..." Hmmm, so your software/appliance dies on a Friday PM, so you have no choice but to remove the devices urgently and reconfigure your networking (all causing outages) and BOM, those kazaa users take 99% of your peer traffic and DoS your internet connectivity. You now need to phone each and every customer and ask them to shut down Kazaa, please. Still sound like a good investment? Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Sent: Sunday, June 01, 2003 2:20 PM To: [EMAIL PROTECTED] Subject: Re: pf/altq on a fast link [EMAIL PROTECTED] (Jason Houx) wrote in message news:<[EMAIL PROTECTED]>... > Good Day Anthony and pf list > > As everyone already covered some very good points and some good links. > I thought I would pass along something that would get you started. > Basically I work for a ISP/LEC and we have started using OpenBSD for > traffic shaping on customers that we will run some fiber to and put a > OpenBSD box at one end to regulate the traffic. IE GigE to a customer but > we cap their bandwidth as if they where buying T1's, DS3, ext (fiber > converters are nice!). This example does do some privatization and > regulates bandwidth. If you get serious about bandwidth management, take a look at something a bit more advanced at a very affordable price. Our software "sniffs out" p2p traffic no matter what port its running on, can manage 1000s of policies/hosts individually, automagically shapes TCP traffic (window reduction to reduce overall queue depth in the network), allows control of virtual hosts by name, has controlled burst definitions, bandwidth templates, etc. With a product like ours you can control the chaos of p2p with 1 rule (port limiting doesnt work, because the clients can run on any port now, in fact kazaa now defaults to port 80), and offer tiered services easily, creating new revenue streams in the process. All with a handy HTML interface and integrated Traffic Analysis tool. It pays for itself the first month. Its available as an add-on to Freebsd or as a standalone appliance. We used to support OpenBSD, but sadly there isnt enough market to justify the effort. www.etinc.com etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc etinc www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com www.etinc.com
RE: pf/altq on a fast link
Good point - but I still think that (in theory) even on unsaturated lines you get intermittent "bursty" traffic, where you want to put some packets out as soon as they arrive and always jump the queue. As I've done no testing on this, yet, it could be minor compared to other improvements. But if you're on a unsaturated 56k line, maybe it's worth doing... Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henning Brauer Sent: Saturday, May 31, 2003 10:22 PM To: [EMAIL PROTECTED] Subject: Re: pf/altq on a fast link On Sat, May 31, 2003 at 10:06:25PM +0100, Dom De Vitto wrote: > As usual, Henning is right, but I'd add that (assuming that the ALTQ+ > PF code is negligible) some protocols may be better, even with plenty > of available bandwidth. > > For example, you could say that TCP SYN,SYN+ACK and ACK packets > (connection setup) should have priority - as this would mean that web > servers could spawn handling processes earlier, in parallel with the > incoming HEAD/GET request. Of course this will add a small delay to > normal data, but overall, total wall-clock time to is decreased. they won't get out earlier even if you priorize them. as the line is not saturated there is no backlog worth talking about and thus there is nothing to give priority over. altq "re-sorts" stuff in the send queues on the network interfaces. if the lines aren't saturated these queues are always empty or close to empty thus nothing to resort. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: pf/altq on a fast link
As usual, Henning is right, but I'd add that (assuming that the ALTQ+ PF code is negligible) some protocols may be better, even with plenty of available bandwidth. For example, you could say that TCP SYN,SYN+ACK and ACK packets (connection setup) should have priority - as this would mean that web servers could spawn handling processes earlier, in parallel with the incoming HEAD/GET request. Of course this will add a small delay to normal data, but overall, total wall-clock time to is decreased. For similar reasons, DNS requests/replies would also have priority over everything. The bottom line is that even for unsaturated links, ALTQ can reduce wall-clock time by ordering packets to cause "blocking" packets to be sent earlier. Hmmm, time for some quantitive tests me thinks Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henning Brauer Sent: Saturday, May 31, 2003 8:33 PM To: [EMAIL PROTECTED] Subject: Re: pf/altq on a fast link On Sat, May 31, 2003 at 02:01:34AM -0700, Tony Faoro wrote: > > Good day, > > I operate a web-hosting/colocation/game server hosting company with a > generous amount of available banwidth. I have a OpenBSD bridge > firewalling my network but after reading about the 'Prioritizing empty > TCP ACKs with pf and ALTQ' I began to realize that there may be more I > can do to speed things up on my link. > > If anyone out there would be so kind as to share a pf.conf they are > using in a similar circumstance that would be great. I'm somewhat new > to the packet prioritizing world and would love some real world > examples you all have had success with. all traffic priorization has only real effects on saturated links. on non-saturated ones they can be used for bandwidth shaping, and, IMHO the most important thing, make sure that in case of saturation the important stuff does not get delayed too much. the tco ack priorization is mostky a ADSL thing. In theory it has effects elesewhere too, in practice it's mostly ADSL winning. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
