RE: Linux vs Windows Firewalls

Take a loot at samhain (http://la-samhna.de/samhain/)  It appears to be
a more modern tripwire-like tool as well.

On Mon, 2003-09-22 at 09:44, Ridgeway, Alan wrote:
> >>a utility called Tripwire in Linux, yet earlier you were very unimpressed with it.
> 
> I don't remember stating I was unimpressed with TripWire.
> CAn you show me the quote ?
> 
> >>Has Tripwire improved to address your security concern or is the AIDE utility preferable?
> 
> Tripwire has an open source release (the original) and a commercial release (the modern version)
> If you are thinking of using the open source version, then AIDE is a better choice since it 
> took the ideas of Tripwire and worked to make it easier.
> 
> If you are looking for the commercial product, Tripwire is awesome. It has a version for various OSes
> and network devices (like Routers). It gives you the confidence that something actually did or did not change.
> If you known if something changed and what it is that did change, that's half the battle of troubleshooting.
> 
> Alan
> 
> 
> -----Original Message-----
> From: annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org
> [mailto:annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org]On Behalf Of PK Carlisle
> Sent: Friday, September 19, 2003 7:00 PM
> To: [email protected]
> Subject: RE: [Annoyances] Linux vs Windows Firewalls
> 
> 
> My apologies for taking so long to respond.
> 
> First, as this list is about Linux, but also issues with Linux, this 
> thread stands as a great example of the communication needed to 
> address any issue.  The authors of that book in the works should 
> cite it.  A question was asked, information exchanged and a 
> conclusion developed.  So often that middle step and all it can 
> contribute to the conclusion is missing when Linux questions are 
> asked.
> 
> Mr. Ridegeway, thank you, sir, for letting me pick your brain on this.  
> One more question if I may:  Your comparison mentions the 
> possibility of using a utility called Tripwire in Linux, yet earlier you 
> were very unimpressed with it.  Has Tripwire improved to address 
> your security concern or is the AIDE utility preferable?
> 
> Thus spake Ridgeway, Alan:
> 
> > From: "Ridgeway, Alan" <[email protected]>
> > To: <[email protected]>
> > Reply-To: [email protected]
> > 
> > OK, now that I have more info here is how I see what you have comapred
> > to Linux.
> > 
> > Your Computer:
> > 
> > Windows (I don't rememeber what version)
> > Tiny Firewall (Personal Firewall setup)
> >  Features:
> >   Dynamic port blocking
> >   Assign specific programs to be allowed open ports, deny the other
> >   programs to that port. MD5 signatures on the executables allowed to
> >   have open ports. Used to assure that the
> >    the binary named "FOO" really is "FOO" and not binary "BAR" with
> >    the name "FOO".
> > 
> > What could be done in Linux
> > NetFilter and (Tripwire or AIDE)
> >  Features: 
> >   Dynamic port blocking if you write the rules with the state table
> >   correctly Assign specific programs to be allowed open ports via
> >   PIDs. Needs a CRON job/script to
> >    get current PID (in-case it spawed a new PID and/or got restarted) 
> >   MD5 signatures on executables monitored by Tripwire or AIDE. This
> >   does not specificly
> >    interact with the firewall, but a script can be written to add a
> >    deny rule for an executable file which does not match the signature
> >    in the database.
> > 
> > So bottom line: Linux does have the same features as listed in the
> > Tiny Firewall. Are they as easy as Tiny firewall setup ? No. Does it
> > make Windows more secure then Linux? By default setup I would have to
> > give Tiny Firewall the edge. But Netfilter in the hands of someone
> > will to setup the rules, scripts and infrstructure has the advantage
> > in security. 
> > 
> > But the reality of Security is, you are only as secure as you are
> > willing to put in the effort. Hence if you put up a firewall, but
> > don't read the logs and review rules on a regular basis, then you are
> > not as secure as you think. So the real question is does Tiny Firewall
> > do a good job ? By what we talked about in this discussion, I would
> > say yes. 
> > 
> > Is Tiny Firewall better then Netfilter ?
> > 
> > If you want an easy personal firewall, then the answer is yes.
> > If you want a firewall with fantastic logging and flexible rules, then
> > the answer is no.
> > 
> > Alan
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org
> > [mailto:annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org]On Behalf Of PK Carlisle
> > Sent: Saturday, September 13, 2003 6:31 PM To:
> > [email protected] Subject: RE: [Annoyances] Linux vs
> > Windows Firewalls
> > 
> > 
> > Here's a bit more information on Tiny Personal Firewall including the
> > MD5 feature.  Also, from my own examination, the only thing I can find
> > in readable text is the activity log.  I also did not see anything in
> > the registry.  I cannot say  whether the MD5 data is specifically
> > encrypted or just written in a proprietary format, but ultimately a
> > sophisticated enough trojan made by someone with enough will and time
> > could probably detect what programs I run and crack and rewrite the
> > relevant MD5 database.  Still, that would require one heck of a
> > trojan.
> > 
> > http://www.hackfix.org/software/configure/tiny.html#config
> > 
> > Now, if I understand what you wrote (and I might not) PID filtering in
> > iptables is similar to filtering by (MD5 fingerprinted) program name
> > in my firewall.  If I understand process numbers correctly they are
> > assigned on the basis of occurrence, so a process number will vary,
> > and if so, can you isolate a process by name for iptables and filter
> > that way -- or how else would you work this?  Could you do this 'on
> > the fly'?
> > 
> > Or is Windows' firewall bad, Linux's better and my somewhat rare setup
> > better still?
> > 
> > BTW, thank you for engaging in civilized conversation in the face of
> > the flames this thread caused.  If I wanted to bash Linux I certainly
> > wouldn't have it installed (but I insist on asking the hard
> > questions).
> > 
> > > 
> > > Great now we can talk about real features with no assumptions.
> > > 
> > > First personal firewalls do tend to have extra features since they
> > > are run on that machine. Hence I would say the majority of people
> > > who run Netfilter use it as a firewall for a network of machines. 
> > > 
> > > As far as the allowing only specific programs to bind to a port, I
> > > thought this section of the user guide was interesting:
> > > 
> > > Page 20
> > > MD5 Signature
> > > 
> > > ...It is possible, however, for a trojan horse to spoof its
> > > identification so the user may see outlook.exe, for example, and
> > > permit it without realizing that outlook.exe may be a trojan horse
> > > application in disguise. (This is what I was saying in previous
> > > e-mails) To prevent this application spoofing, Tiny Personal
> > > Firewall includes MD5 signature authentication support. ... Each
> > > time the application requests to bind to a particular port, Tiny
> > > Personal Firewall can take a fingerprint of the application and
> > > compare it to the original fingerprint. (Sounds like an intersting
> > > feature. It's like having Tripwire (www.tripwire.com) built-in to
> > > the Firewall. It is virtually impossible to duplicate a fingerprint,
> > > so trojan horse applications don't stand a chace. (This is half
> > > true. MD5 are hard to reproduce on a different binary. But how does
> > > Tiny Firewall protect the signature ? If it only keeps a text file
> > > of the signature, then the trojan horse could replace the signature
> > > and get away with it. Now if the list of signatures were also
> > > hashed/signed then Tiny firewall could verify the list of hashes and
> > > then trust that the hases are correct.)
> > > 
> > > Can you verify how the MD5 hashes are storied ?
> > > 
> > > --------------------------------------------------------------------
> > > 
> > > As far as GID matching in Netfilter goes, I took a deeper look and
> > > found the following:
> > > (http://iptables-tutorial.frozentux.net/iptables-tutorial.html The
> > > best Netfilter document I ever found)
> > > 
> > > Match --uid-owner 
> > > Example iptables -A OUTPUT -m owner --uid-owner 500 
> > > Explanation This packet match will match if the packet was created
> > > by the given User ID (UID). This could be used to match outgoing
> > > packets based on who created them. One possible use would be to
> > > block any other user than root from opening new connections outside
> > > your firewall. Another possible use could be to block everyone but
> > > the http user from sending packets from the HTTP port.  
> > > 
> > > Match --gid-owner 
> > > Example iptables -A OUTPUT -m owner --gid-owner 0 
> > > Explanation This match is used to match all packets based on their
> > > Group ID (GID). This means that we match all packets based on what
> > > group the user creating the packets are in. This could be used to
> > > block all but the users in the network group from getting out onto
> > > the Internet or, as described above, only to allow members of the
> > > http group to create packets going out from the HTTP port. 
> > > 
> > > Match --pid-owner 
> > > Example iptables -A OUTPUT -m owner --pid-owner 78 
> > > Explanation This match is used to match packets based on the Process
> > > ID (PID) that was responsible for them. This match is a bit harder
> > > to use, but one example would be only to allow PID 94 to send
> > > packets from the HTTP port (if the HTTP process is not threaded, of
> > > course). Alternatively we could write a small script that grabs the
> > > PID from a ps output for a specific daemon and then adds a rule for
> > > it. For an example, you could have a rule as shown in the
> > > Pid-owner.txt example. 
> > > 
> > > Match --sid-owner 
> > > Example iptables -A OUTPUT -m owner --sid-owner 100 
> > > Explanation This match is used to match packets based on the Session
> > > ID used by the program in question. The value of the SID, or Session
> > > ID of a process, is that of the process itself and all processes
> > > resulting from the originating process. These latter could be
> > > threads, or a child of the original process. So, for example, all of
> > > our HTTPD processes should have the same SID as their parent process
> > > (the originating HTTPD process), if our HTTPD is threaded (most
> > > HTTPDs are, Apache and Roxen for instance). To show this in example,
> > > we have created a small script called Sid-owner.txt. This script
> > > could possibly be run every hour or so together with some extra code
> > > to check if the HTTPD is actually running and start it again if
> > > necessary, then flush and re-enter our OUTPUT chain if needed.
> > > 
> > > 
> > > Match --ttl 
> > > Example iptables -A OUTPUT -m ttl --ttl 60 
> > > Explanation This match option is used to specify the TTL value to
> > > match. It takes a numeric value and matches this value within the
> > > packet. There is no inversion and there are no other specifics to
> > > match. It could, for example, be used for debugging your local
> > > network - e.g. LAN hosts that seem to have problems connecting to
> > > hosts on the Internet - or to find possible ingress by Trojans etc.
> > > The usage is relatively limited, however; its usefulness really
> > > depends on your imagination. One example would be to find hosts with
> > > bad default TTL values (could be due to a badly implemented TCP/IP
> > > stack, or simply to misconfiguration).
> > > 
> > > So does Netfilter/Iptables have the same exact feature. No not that
> > > I know of. While the Tiny Honeypot feature is interesting, I would
> > > like to see a little more detail on how they implement it.
> > > 
> > > But really the best way to catch something like a Trojan horse is to
> > > use an MD5 database like Tripwire. 
> > > 
> > > Alan
> > > 
> > > 
> > > From: annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org
> > > [mailto:annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org]On Behalf Of PK Carlisle
> > 
> > > 
> > > OK, for clarity, I use my system only as a client. As you note, the
> > > one potential security flaw that I can see is a spawned application.
> > > I can (and do) to some degree avoid this and acheive security in
> > > depth in several ways:  I use less widely used (and coincidentally
> > > higher quality) applications -- Pegasus Mail instead of Outlook,
> > > Netscape instead of MSIE.  I do also scan the system for spyware
> > > regularly.  I do not allow Dial Up Networking to even have the
> > > password necessary to dial out, that is retained by another product
> > > entirely so that nothing can spoof another program and dial out,
> > > because nothing at all can dial out on its own. I do not have
> > > unnecessary protocols even installed in DUN.  This makes for an
> > > uncommmon configuration which would defeat quite a few attacks /
> > > exploitations based on a default configuration.
> > > 
> > > Also for clarity, I am definitely NOT talking about the firewall
> > > built into Windows XP. :-)    It also works on general concepts such
> > > as 'allow mail', and leaves the user to guess what that means with
> > > regard to what can access the internet.  That made me nervous when I
> > > first saw it in Windows and that is why the apparently similar
> > > approach in Linux made me wonder about the security aspect.  The
> > > firewall I use is Tiny Personal Firewall:
> > > 
> > > http://www.tinysoftware.com/tiny/files/docs/pf2.pdf
> > > 
> > > and a sample basic rule set runs thusly:
> > > 
> > > http://www.dslextreme.com/users/surferslim/tpf.txt
> > > 
> > > Not being familiar with nmap, and being never having set up a 
> > > network as complicated as your document describes (but I kept a copy
> > > to give me ideas, thank you), I cannot attempt a comparison with
> > > nmap, but I am going to say that my perception is this:  My firewall
> > > obviously cannot *prevent scanning* on any port, but if I am scanned
> > > on a disallowed port, or if access to a unallowed application even
> > > on an otherwise allowed port is attempted, that activity is simply
> > > dropped. 
> > > 
> > > I had assumed that this would be readily available in Linux.  I will
> > > have to look into GID matching for Linux.
> > > 
> > > Thus spake Ridgeway, Alan:
> > > 
> > > > 
> > > > It sounds like there may be some confusion here.
> > > > 
> > > > >it seems that if you accept packets on, for example, port 80,
> > > > >then -any program- can communicate on 
> > > > port 80
> > > > 
> > > > It sounds like you are talking about running a server (like a web
> > > > server) on port 80. If that is the case, then assigning a program
> > > > name does not give you anything extra. If the web server is
> > > > listening on port 80, then no other program on that machine can
> > > > listen on port 80. 
> > > > 
> > > > Now if you are talking about a client going over the Internet to
> > > > reach a server on port 80 then I think what you are saying is the
> > > > Windows firewall will only allow, IE to use port 80 as a
> > > > destination port. If that is what you are saying then, it seem
> > > > like you might have a point, until you realize that the spyware
> > > > could spawn itself as a web application using IE in the same
> > > > manner that web ad companies used to do so. Then I am not so sure
> > > > you have gained any security.
> > > > 
> > > > But security is about defense in depth. Hence adding intrusion
> > > > detection to the network and/or a web proxy with an active
> > > > blacklist for spyware will do a better job at defeating spyware.
> > > > 
> > > > I haven't used Windows Firewall much, but with Netfilter I can
> > > > write my rules in such a way that nmap in most cases is useless in
> > > > scanning my firewall for open ports. The only scans that are
> > > > useful are heavily logged. Can you write rules like this in
> > > > Windows Firewall ? See this the paper I wrote for the firewall
> > > > rules.
> > > > http://www.giac.org/practical/GCFW/Douglas_Ridgeway_GCFW.pdf
> > > > 
> > > > So please inform me about what I gain if I used Windows Firewall.
> > > > 
> > > > Alan
> > > > 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org
> > > > [mailto:annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org]On Behalf Of PK
> > > > Carlisle
> > > > 
> > > > I am new to playing with Linux so I admit that I could very well
> > > > be wrong about this...
> > > > 
> > > > Looking through the docs for the Linux firewall, it seems that if
> > > > you accept packets on, for example, port 80, then -any program-
> > > > can communicate on port 80, you cannot limit which programs can
> > > > communicate with the internet, so you could not automatically
> > > > block spyware, etc., that is, you cannot automatically block any
> > > > program not on a list approved to communicate with the internet.
> > > > 
> > > > OTOH, my Windows firewall lets me say that program X may 
> > > > communicate on port n and -only- that program may communicate that
> > > > way unless there's another rule specifically allowing another
> > > > program access on that port; registry checking assures that no
> > > > application masquerades as another.
> > > > 
> > > > Am I wrong or can it be that my Windows system is -significantly-
> > > > more secure online than Linux??
> > > > 
> > 
> 
> 
> _______________________________________________
> annoyances mailing list
> [email protected]
> http://michelangelo.renaissoft.com/mailman/listinfo/annoyances
> 
> 
> _______________________________________________
> annoyances mailing list
> [email protected]
> http://michelangelo.renaissoft.com/mailman/listinfo/annoyances
-- 
    Lawrence MacIntyre     865.574.8696     [email protected]
               Oak Ridge National Laboratory
High Performance Information Infrastructure Technology Group

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA/c2bdCNjP8rawCW4RAs1EAKCQpEBJS2dz+F7G7/E5I6Gbho9tEACaAuHC
xS7wg8s/YJaHb4ku2hduixs=
=EIEu
-----END PGP SIGNATURE-----