RE: sequence number check in pf
Petr,
Here is one excellent example of why it is important to check sequence
numbers:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
For an excellent paper on TCP state checking, I like the following:
http://home.iae.nl/users/guido/papers/tcp_filtering.ps.gz
You might want to check out Daniel's PF Page (the lead developer of pf):
http://www.benzedrine.cx/pf.html
And of course the pf FAQ is one of the best Firewall FAQs on the 'Net:
http://www.openbsd.org/faq/pf/index.html
Jim
-Original Message-
Hi Gurus,
I had a disscusion with friend of mine who does use Linux ( and
therefore iptables ) for his firewall. I wonder, why is so
important for firewall to check for valid sequence number range
for whole life of connection ? As I do understand, iptables does
it only for handshake time and after connection enters ESTABLISHED
state it checks only for {source,destination} and {IP address,
port}. Pf on the other hand checks for valid sequence number all
the time.
If I send packet with invalid seq. number (with other atributes
valid) to host behind firewall and firewall don't check it ie.
let it through, destination host will drop it anyway doesn't it?
So in case of pf, pf will drop packet before it reach host, in
case of firewall that doesn't do check on seq. numbers,
destination host will drop it. Yes, nasty and not valid packets
will enter my network, taking resources from my server etc., but
is there anything else that I missed ?
I red lots of papers about TCP hijacking, IP spoofing and packet
injection, but I still somehow do not understand, how seq.
number check on firewall in whole connection's lifetime could help.
I could imagine only one situation - sending RST with valid
addresses and ports could change state on the firewall but host
will drop it, so firewall will close the connection (after some time)
but it still will look like established on both hosts.
Could someone put more light on it ?
Thanks a lot
RE: sequence number check in pf
BTW - You might be interested to know that tracking sequence numbers has
been deemed important in IPTables. The TCP Window Tracking patch checks
sequence numbers (as described in
http://home.iae.nl/users/guido/papers/tcp_filtering.ps.gz.ps.gz) and has
been submitted to be included in the mainline kernel for 2.6.9.
I have to say I was somewhat surprised, given all the praise I hear about
IPTables that many of the features I take for granted in pf are not in the
default Linux kernel or even available.
The OpenBSD and pf teams are not really given the credit they deserve. Even
CARP which was invented here is being used by the Netfilter team. Don't let
the seemingly simple interface of pf (at least compared to many other
firewalls) fool you, this firewall is profoundly powerful.
Jim
-Original Message-
Hi Gurus,
I had a disscusion with friend of mine who does use Linux ( and
therefore iptables ) for his firewall. I wonder, why is so
important for firewall to check for valid sequence number range
for whole life of connection ? As I do understand, iptables does
it only for handshake time and after connection enters ESTABLISHED
state it checks only for {source,destination} and {IP address,
port}. Pf on the other hand checks for valid sequence number all
the time.
If I send packet with invalid seq. number (with other atributes
valid) to host behind firewall and firewall don't check it ie.
let it through, destination host will drop it anyway doesn't it?
So in case of pf, pf will drop packet before it reach host, in
case of firewall that doesn't do check on seq. numbers,
destination host will drop it. Yes, nasty and not valid packets
will enter my network, taking resources from my server etc., but
is there anything else that I missed ?
I red lots of papers about TCP hijacking, IP spoofing and packet
injection, but I still somehow do not understand, how seq.
number check on firewall in whole connection's lifetime could help.
I could imagine only one situation - sending RST with valid
addresses and ports could change state on the firewall but host
will drop it, so firewall will close the connection (after some time)
but it still will look like established on both hosts.
Could someone put more light on it ?
Thanks a lot
RE: Brige, Traffic Shaping and FTP
In fact, even if it does not really matter to you in fact, I'm not talking about a kernel proxy here. I'm talking about something smart enough to tag packets related and so to pass them. A piece of kernel code smart enough to inspect packets comprising a partular protocol, and extract enough information to determine if they are, in fact related is exactly what Henning is referring to as a kernel proxy Having used many different firewalls, I think I see the argument here. Traditionally a proxy is something that would block the flow of traffic. The packets would terminate at the proxy, the proxy would inspect them up to the application layer/Layer 7. The proxy would then initiate the conversation to the outside on behalf of the client. I believe what is being requested is a kind of state engine that is smart enough to modify packets on the fly and recognize related packets. This is common in many commercial firewalls and also in SunScreen and Netfilter/IPTables. I would argue that this is not quite the same as a proxy. However, now-a-days, the difference between a stateful/NAT firewall and a Proxy is a fine line and somewhat subjective. If we go on with FTP, a piece of code that attach data connexions to the command connexion initiated before. In case of a bridge, I clearly do not need (and do not want !) a proxy, nor NAT support. Yes. Since the kernel sees traffic a packet at a time, it essentially has to fake the statefulness of TCP in order to track these things. It's a layer violation. It's also next to impossible, without re- implementing TCP. This is EXACTLY why the decision to make these kinds of per-protocol decision was relegated to userland in the first place: because TCP will handle the state issues, before userland sees the packets. This is very interesting to me. Perhaps I just don't know enough to understand what you are saying. I have done some socket and kernel programming, but I'm no Daniel or Henning. What I don't get, is if what you are saying is true, how do commercial firewall products work? They don't have access to the O/S source code and manage. What am I missing? How is it a layer violation? Can't you link in with a callback or something? Why do you have to re-implement TCP? I do think if you were going to do something like this, a framework would have to be agreed upon. Perhaps it could be a userland framework although you'd have to look at performance and scalability. Think fragment attacks. Think of the attacks against IPF's ftp kernel code. Think of EVERY ambiguity that scrub was intended to help correct. We had this debate long ago. The kernel way is the WRONG way. Writing a userland proxy for a particular protocol is by definition easier than writing the kernel equivalent, since you don't have to figure out what the TCP will do with ambiguities. It is definitely true that the more kernel code you have, the higher the risks are. The traditional problem with userland programs (from my understanding) is that they don't scale. That seems to be a big part of why proxies are slow. That's why many people are trying to cache web pages in the kernel--it's faster. Don't get me wrong, I'm not necessarily advocating this position. It's a trade off between performance and security. I'm sure Henning is pulling his hair out reading this... :) In the end, I think Daniel is right. It sounds like a cool feature, but someone would have to step up or help fund it. Perhaps some day, I'll learn enough to be able to contribute... Jim
RE: [idea] permit state
It's an interesting idea. It's kind of a philosophical issue. Do you only allow what's most secure, or do you setup a framework that allows more risks to be taken if desired. I tend to like the latter, but setting up and maintaining an entire framework is a lot of work... It would definitely have to be a framework though, because each protocol (e.g. ftp) needs tweaking to work with NAT and certain firewall provisions. The other option would be to lobby for IPv6. Jim -Original Message- On 29/02/2004, Ed White [EMAIL PROTECTED] wrote To [EMAIL PROTECTED]: Until the state created by the above rule is in the table, PF will behave like if the following rule had been added. pass in inet proto tcp from $server to $user this is like 'related' in iptables, tho those ppl try to do a smart approximation about that is related to certain protocols. I dont like that. Doesnt buy you a real thing - only holes. Start thinking of bad guys behind your firewall, instead of featurisms for 'only good users' behind it. Short: i dont like it
RE: PF Logging FAQ clarification
Jim, If you have a cable broadband connection, this is probably nothing to be concerned about. Many cable broadband providers, including mine, initially give you a private IP address (10.x.x.x) via DHCP, and then later switch you to a public IP (typically 24.x.x.x if you are in North America). If you block external traffic, you will constantly see DHCP traffic like this. It's usually nothing to worry about, just block it and don't log it, or log it to a separate file. Jim -Original Message- From: Jim Mays [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 11:18 PM To: [EMAIL PROTECTED] Subject: Re: PF Logging FAQ clarification Wow, that's what I'm afraid of. The log files are filled with rejects from 10.180.160.1.67. Is 67 the port number? Why am I getting hammered from a non-routable address? Jim - Original Message - From: Daniel Polak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 29, 2003 9:45 PM Subject: Re: PF Logging FAQ clarification Jim, I wrote that particular part of the PF FAQ and you are right that the instruction to touch /var/log/pflog.txt is missing. Sorry about that. If I remember correctly syslog will just not log to a file that does not already exist which is why you need a special touch :-) Enter the following to see what the number for each rule is: pfctl -v -v -s rules | grep @ | more Daniel Original message from Jim Mays at 30-12-2003 3:06 In the /var/log directory I entered touch pflog.txt and now it works fine. I can't believe this it won't create the file if it isn't already there. I have run both the scripts by hand that are listed in the FAQ and they both run fine. I looked through the new ascii log files and I have one more question. What constitutes a rule? If something matches rule 4, does that include a scrub line and a nat line? Or is it only lines that start with pass or block? Thanks Jim - Original Message - From: Jim Mays [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 29, 2003 7:09 PM Subject: PF Logging FAQ clarification I am trying to get PF to log in ASCII format so I followed the FAQ page on PF Logging to the letter. When it gets to the line that says # kill -HUP $(cat /var/run/syslog.pid) I get an error that says: /var/log/pflog.txt: No such file or directory I also get this error when I reboot the system. Why am I getting this error? Shouldn't it just create the file? The man page doesn't say anything about the file having to exist already. Jim
RE: PF Logging FAQ clarification
Jim,
I think the theory is that if you have/get cable in you
house/apartment/condo/etc... that you can't just hook up a broadband
splitter, plugin your computer, and surf the net. Instead, you must call
your cable provider and have them activate your connection (something to
do with splitter???) so you get a public/routable IP. I believe this is
similar with many hotels. Your hotel room has an RJ45 jack, you plugin your
laptop and fire up your browser. After agreeing to pay X amount per day,
you are then allowed to get out to the Internet...
Of course this is just a guess on my part from what I gleaned from talking
with my cable company. When I tried to explain the difference between a
public and private IP address, their eyes glazed over, so I didn't push for
more info...
Anyone working for an ISP/Broadband provider, please feel free to jump in
and correct me.
Jim
-Original Message-
From: Jim Mays [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 30, 2003 7:58 AM
To: [EMAIL PROTECTED]
Subject: Re: PF Logging FAQ clarification
I am on broadband, and my IP is on 24.x.x.x currently. When do I have a
10.x.x.x address and when do they switch me to the 24.x.x.x? Why do they
do this?
I do block all such traffic with a rule that is:
NoRouteIPs {127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8}
block in log quick on $ExtIf from $NoRouteIPs to any
I'll take the log out of this rule and not worry about it. Now I know
why
the activity light on the cable modem constantly flashes, even when all
computers are turned off. I'm just interested in understanding what is
going on and why.
Thanks.
Jim
- Original Message -
From: Small, Jim [EMAIL PROTECTED]
To: Jim Mays [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, December 30, 2003 5:51 AM
Subject: RE: PF Logging FAQ clarification
Jim,
If you have a cable broadband connection, this is probably nothing to be
concerned about. Many cable broadband providers, including mine,
initially
give you a private IP address (10.x.x.x) via DHCP, and then later switch
you
to a public IP (typically 24.x.x.x if you are in North America). If you
block external traffic, you will constantly see DHCP traffic like this.
It's usually nothing to worry about, just block it and don't log it, or
log
it to a separate file.
Jim
-Original Message-
From: Jim Mays [mailto:[EMAIL PROTECTED]
Sent: Monday, December 29, 2003 11:18 PM
To: [EMAIL PROTECTED]
Subject: Re: PF Logging FAQ clarification
Wow, that's what I'm afraid of. The log files are filled with rejects
from
10.180.160.1.67. Is 67 the port number? Why am I getting hammered
from
a
non-routable address?
Jim
- Original Message -
From: Daniel Polak [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, December 29, 2003 9:45 PM
Subject: Re: PF Logging FAQ clarification
Jim,
I wrote that particular part of the PF FAQ and you are right that
the
instruction to touch /var/log/pflog.txt is missing. Sorry about
that.
If I remember correctly syslog will just not log to a file that does
not
already exist which is why you need a special touch :-)
Enter the following to see what the number for each rule is:
pfctl -v -v -s rules | grep @ | more
Daniel
Original message from Jim Mays at 30-12-2003 3:06
In the /var/log directory I entered touch pflog.txt and now it
works
fine.
I can't believe this it won't create the file if it isn't already
there.
I
have run both the scripts by hand that are listed in the FAQ and
they
both
run fine. I looked through the new ascii log files and I have one
more
question. What constitutes a rule? If something matches rule 4,
does
that
include a scrub line and a nat line? Or is it only lines that
start
with pass or block?
Thanks
Jim
- Original Message -
From: Jim Mays [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, December 29, 2003 7:09 PM
Subject: PF Logging FAQ clarification
I am trying to get PF to log in ASCII format so I followed the FAQ
page
on
PF Logging to the letter. When it gets to the line that says
# kill -HUP $(cat /var/run/syslog.pid)
I get an error that says:
/var/log/pflog.txt: No such file or directory
I also get this error when I reboot the system. Why am I getting
this
error? Shouldn't it just create the file? The man page doesn't
say
anything about the file having to exist already.
Jim
RE: pf with any l7 patches or ability?
I agree that trying to do too much in a firewall can be bad and even
dangerous. However, Layer 7 Filtering/Proxying can be extremely useful. I
believe the key is to use a layered approach. You would have a border
firewall and then you could have a l7/proxy server behind it.
L7/Proxy servers have become extremely important because of tunneling.
Pretty much anything can run over http/80 or https/443. A firewall is no
longer sufficient by itself. You need something peering into the packets
and deciding if it's really http or it's gnutella, Kazaa, AIM, etc...
This is especially important with IM and P2P apps which are often not
written with security in mind (to put it nicely) and left running all the
time. Essentially these provide a back door into your network and if you
leave the http port open...
Henning is right though. Trying to put too many features into pf would be
bad. Better to have add on patches like with Netfilter/IPTables or even
better a separate project.
Two worth looking at for OpenBSD are:
Hogwash: http://sourceforge.net/projects/hogwash
-and-
http_filter: http://glob.com.au/http_filter/
(Warning--written in perl so not for high performance)
Of course many plugins can also be found for squid.
I would also be curious if anyone has heard of other L7 filters that work
well with pf. You see Daniel and Henning, we're so spoiled by pf, OpenBSD,
and OpenSSH that we're hoping there's an L7 filter project like that...
Jim
-Original Message-
From: Henning Brauer [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 06, 2003 6:03 AM
To: [EMAIL PROTECTED]
Subject: Re: pf with any l7 patches or ability?
l7 filtering is basically just a buzzword.
you have it since years - it's called proxy.
what they mean by the new buzzword is integrating the config, and
perhaps doing this in kernel land.
to get an idea why l7 stuff in kernel is a bad bad bad bad idea, look
at ipf - search bugtraq for the problems it had with its in-kernel
ftp-proxy.
or look at netfilter, they've just been bitten by their in-kernel
connection tracking for ftp and irc as well. bugtraq is your friend
here too ;-)
I don't believe paketeer or anything else is doing any better. it's
simply a design fault.
On Wed, Nov 05, 2003 at 10:05:36PM -0600, Nick Buraglio wrote:
I don't necessarily disagree. I had a feeling I was chasing a ghost,
but I have a need for a packeteer-ish appliance without the price. The
reason I was looking at openbsd was that I like the bridge code. It
works well, it's not hard to configure and best of all pf is there.
The real problem is that in the locations I need to put these
theoretical devices the owners are too cheap to buy good equipment that
could perform the job so I search for a hack to do a similar job.
worst case is that I use linux with the l7 patches. I'd just prefer to
use a BSD, not necessarily pf, I figured that people on this list may
have some idea.
Thanks again.
nb
On Nov 5, 2003, at 7:51 PM, Laurent Cheylus wrote:
Hi,
Quoting Nick Buraglio [EMAIL PROTECTED]:
I'm looking for anyone that knows of a bsd project that does something
similar to to the Linux Layer 7 filter project. Details found here:
http://l7-filter.sourceforge.net/ I'm more or less hoping that
someone
has a *BSD project that can classify packets based on application data
in the connections they belong to or that there is a patch for pf to
do
this. Is there anything in the works that anyone knows of?
If you read the recent archives of ths list, you could see that
'official' PF
devs (Daniel, Henning) don't want work on data payload inspection (bad
performances to do things like that in kernel space).
In my opinion, classify packets based on application data is a (very)
bad idea
for security. If you decide to block or accept packet with rule only
based on
app data and a too simple grammar for classification, it's too easy to
fake your
ruleset.
I don't really want to block or pass, just shape.
Exemple :
- pass in on $EXT from any to POP3_SERVER app POP3 ('app' is a new
keyword for
classification based on app data)
- the grammar for POP3 protocol of L7-filter project
- by sending a packet with payload 'pop3', your packet is accepted
even if it's
not a packet for POP3 exchange
A++ Foxy
--
Laurent Cheylus [EMAIL PROTECTED] OpenPGP ID 0x5B766EC2
--
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 with any l7 patches or ability?
Daniel, I actually had the chance to meet Harald Welte, one of the core members of the Netfilter/IPTables team at the Linux Symposium this year. I think in large part he agrees with you and Henning. When I spoke with him about string matching and TCP stream reassembly/filtering, he most definitely did not care for these approaches. The whole problem is that the RFCs are pretty much guidelines so it's almost impossible to have a solid L7/Proxy system. There are an almost hopeless amount of extensions to practically all protocols, and to make matters worse, many of the extensions are proprietary or poorly/undocumented. However, in the Enterprise, with the constant barrage of worms and the given that Windows based systems are everywhere, I believe that something, especially a layered solution is better than nothing. Sheesh, it's gotten so bad in the last couple years; that even company Intranets have to be treated as hostile networks. Too bad there's not a pf for Windows, don't even ask me about host based Windows firewalls... I also had the pleasure of talking with Marty Roesch recently. There's a lot of cool things going on at SourceFire and then being put into snort. Something like Hogwash--adaptive (N)IDS is interesting although IDS still has quite a ways to go. You might be surprised though how effective IDS signatures can be at selectively blocking traffic. I don't want to get too far off on a tangent though. Despite the significant issues with IDS, tell me a better alternative. Personally though I think you and Henning are doing an awesome job. For security products especially, quality far outweighs quantity. The biggest problem with security products is exactly what you are saying--people are looking for a quick fix instead of developing a clean and robust system. Jim -Original Message- From: Daniel Hartmeier [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 11:09 AM To: Small, Jim Cc: [EMAIL PROTECTED] Subject: Re: pf with any l7 patches or ability? On Thu, Nov 06, 2003 at 10:14:36AM -0500, Small, Jim wrote: I would also be curious if anyone has heard of other L7 filters that work well with pf. You see Daniel and Henning, we're so spoiled by pf, OpenBSD, and OpenSSH that we're hoping there's an L7 filter project like that... If someone shows me how to do it correctly, that might even convince me to try to implement it in pf. But what I've seen so far were horrible kludges in the sense that I can immediately predict a dozen ways it will raise false alarms or be easily circumvented by a moderately clever tool. What I'd want is a scheme that I myself could trust. For instance, I personally dislike the idea of 'search for substring HTTP/1.1 in the payload and assume protocol HTTP when found' or anything inaccurate like that. Would this very email be blocked by some firewalls because they see the string in the (SMTP) payload? Searching payload of individual packets independantly is just guesswork. Even if many people consider that 'good enough' and 'helpful in some cases', I find it too ugly to invest time. I rather pick something else I can do properly. Daniel
TCP/IP filtering concepts presentation
I'm going to do a presentation on TCP/IP filtering concepts in March. In fact, if anyone near Detroit, Michigan in the States is interested... http://www.mug.org/meeting_location.php The presentation will be around an hour. I'm looking for ideas on what to present. Here's what I'm thinking: o Run through the IP, UDP, and TCP headers o Cover TCP flags (including valid/invalid combinations) o Run through sequence numbers to explain how statefullness works o Run through ICMP including the various types, including which types are necessary for the Internet to function correctly o Explain how NAT works including PAT and IP to IP mapping o Quickly walk through port forwarding, redirection, and bouncing o Finally I'm thinking of running through some of the major firewall products including of course OpenBSD/pf. I have a lot of good sources to draw on including Stevens TCP/IP Illustrated series and O'reilly's Building Internet Firewalls. Does anyone have any recommendations, suggestions, or ideas that I am missing? Also, if anyone has any material or sites they think would be helpful, I'd be grateful. Thanks, Jim
RE: how stupid is this?
A DNS query will use UDP by default since it has less overhead. However, the standard limits the size of a UDP query to 512 bytes. If the query is more than 512 bytes, the TC (TrunCation) bit is set in the return query. Typically the resolver will then retry the query using a TCP connection. The firewall wizards list has been discussing this and showing examples. See RFC 1035/Standard 13 and O'reilly's DNS BIND book. How does humble pie taste? ;-) Jim -Original Message- How stupid are YOU !??!?!? DNS uses tcp/53 for zone transfers regarding slave servers, not big packets ! - Original Message - matter that I run dns mail on my firewall. My pf rules are pretty standard, a default deny + allow in UDP on port 53 TCP on 25. I also allow in SSH, WWW but only from my work IP address, so that shouldn't affect things POP but only from internal hosts. DNS sometimes also uses TCP on port 53 for large packets, so you probably want to allow that as well.
Patching Firewalls
I'm curious, How does everyone maintain their firewalls when patching them? Do you use cvs or a manual patch? Or do you compile things on a separate system and do binary patch on the firewall? It would seem that CVS (tracking -stable) is the best way. The problem with this though is you have to put the compiler on the firewall. Ideally you want your firewall stripped down. But since you need to compile patches, it seems hard to avoid. Comments? Apologies as I realize this is not technically a pf question, but I am interested in the case of a firewall, not a general purpose machine. Jim
RE: newbie question
Peter, If you want to learn about TCP/IP, especially in regards to UNIX, the best book on the market is: TCP/IP Illustrated, Volume 1 by W. Richard Stevens You might even be able to get it in Slovakian as it is widely translated. This book thoroughly dissects TCP/IP. An excellent general book on Firewalls is: Building Internet Firewalls, 2nd Edition by Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman After you've read this, another good book is: Network Intrusion Detection, 3rd Edition by Stephen Northcutt and Judy Novak This is a good book to learn about security internals as you have to really understand how things work to effectively implement a Network Intrusion Detection system. Of course, if Daniel decides to write a book, I would recommend that... Otherwise, the OpenBSD Networking FAQ is also a good place to look: http://www.openbsd.org/faq/faq6.html Jim -Original Message- May I ask you something before I ask you something? If I want to learn more about TCP/IP and that kind of stuff to better understand firewalling, are there any (there are many I know, but that's the problem (: ) 'good' tutorials or FAQs or documentation on 'the net' I should study before I send some questions here? You know what I mean. :) About flags, attacks, sniffers, port scans and so on. I spend 70% of my time allocated to learn more about this only by searching for some good documentation. So would you be please so kind and direct me to some links where I can find 'the knowldege'? :o) Thank you very much. Peter Hunr CCh FChPT STU
RE: TCP Flags question
Thanks to everyone for an excellent discussion of TCP flags! I'm going to have to re-read all those TCP chapters in Stevens' book. I used to think I was a knowledgeable networking person until I started listening to you guys. Maybe if I lurk enough I'll get there... Jim -Original Message- From: Henning Brauer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 8:02 AM To: [EMAIL PROTECTED] Subject: Re: TCP Flags question On Tue, Dec 10, 2002 at 10:27:02PM -0600, James Nobis wrote: I use to use S/SA without much of a thought to it and nmap -O happily said I was running Openbsd with scrub in all. Upon changing my rule to a S/SAFPRU you can nmap -O till you are blue in the face and nmap is clueless. I think that a decent advantage. If you are just writing a rule for inbound connections ie a webserver and you keep state then S/SAFPRU will make detection of the os difficult if not impossible (assuming you block all other ports that aren't open.) It all falls upon how paranoid you are I suppose. oh wow, a real advantage. if someone wants to know I'm running OpenBSD he just needs to read our website. -- 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: TCP Flags question
Thanks Henning. So if you add just flags S/SA, that does allow ECN, right? May I ask why you prefer S/SAFR vs. S/SA or S/SAFPRU? Does anyone else have other flag combinations they like? Daniel? Jim -Original Message- On Mon, Dec 09, 2002 at 06:06:03PM -0500, Small, Jim wrote: I have a question about TCP flags. I read through the FAQ (see, it actually *is* useful!) and it cleared it up somewhat. So, if you add a TCP-based rule with flags S/SA, it will allow an initial SYN packet, but deny an initial packet with both the SYN and ACK flags set? yup. e.g. pass in on $ExtIF inet proto tcp from any to any port $Services \ flags S/SA keep state (From the FAQ) If this is correct, then once a SYN packet is sent, a state entry is set up (with a timeout) that allows the corresponding SYN-ACK back (from the target) and then the final SYN-ACK from the session initiator to establish the TCP session? Is this right? yup. Also, is flags S/SAFPRU better than flags S/SA? I don't buy that. S/SAFR perhaps. I think the advantage of filtering on flags is overestimated. Why is using flags S by itself so bad? because you filter connection attempts from ECN capable hosts (E bit set). What is modulate state? tcp sequence numbers are replaced. it's to protect machines/apllicances with weak sequence numbers.
