RE: Linux vs Windows Firewalls

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


-----Original Message-----
From: annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org
[mailto:annoyances-admin-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org]On Behalf Of PK Carlisle
Sent: Thursday, September 11, 2003 8:24 PM
To: [email protected]
Subject: RE: [Annoyances] Linux vs Windows Firewalls


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
> Sent: Monday, September 08, 2003 8:30 PM To:
> [email protected] Subject: [Annoyances] Linux vs Windows
> Firewalls
> 
> 
> 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??
> 





------------------------ 

Mistresses are a direct function of the economy. -Divorce lawyer Raoul Felder


Earthlink, AOL, Yahoo & MSN/Hotmail IM: mrgoodbytesim  ICQ:13418006
PGP Public Key: http://home.earthlink.net/~mrgoodbytes/pkpubpgp.asc
VOX: 708-296-2466  FAX: 708-452-8594 


_______________________________________________
annoyances mailing list
[email protected]
http://michelangelo.renaissoft.com/mailman/listinfo/annoyances