[ previous ] [ next ] [ threads ]
 
 From:  "Mitch \(WebCob\)" <mitch at webcob dot com>
 To:  "Falcor" <falcor at netassassin dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall] windows built in "ident"...
 Date:  Sat, 3 Jan 2004 21:03:41 -0800
Nope - sorry - I guess I wasn't clear...

indentd (no matter how spoofable) was originally supposed to give a user
name associated with a request, and in a CONTROLLED network environment, can
still be used for tracking user access, and even access control - certainly
logging, etc. as long as root is trusted - same as an NFS environment.

What I have seen working - not imagined - is a combination of software (on
windows PC's) and HARDWARE - linksys firewall / router which DENY's outgoing
access based on the presence of an active software firewall on the windows
box.

Regardless of the complexities here, there is a requirement for an
identd-like socket ownership resolver (which I have seen done with a windows
based TCP monitoring tool), my real interest was in controlling SYNC/ACK
processing based on a syncronous request to what ammounts to an
authentication mechanism.

The point, as I think I said before is to only allow access to the Internet
by certain client programs from authorized client stations. If someone has
physical access to a network, they can steal a MAC / IP and connect outbound
according to the firewall rules...

I was wondering about two things - 1 - does anyone know more about these
mechanisms for determining process and user account ownership of socket
handles on windows and - 2 - can the firewall (monowall) use an external
check to gate the filter based on some result code...

Hope that makes it clearer - nothing about spoofing uid's for irc servers or
anything like that.

Thanks.

m/

-----Original Message-----
From: Falcor [mailto:falcor at netassassin dot com]
Sent: Wednesday, December 31, 2003 5:38 AM
To: Mitch (WebCob)
Cc: Brandon Holland; m0n0wall at lists dot m0n0 dot ch
Subject: Re: [m0n0wall] windows built in "ident"...


Your thread was not "hijacked" perhaps you simply phrased your questions
wrong if you found no value in the answers.

What I read from your original post was:

1.) Can / is there something that m0n0wall can do to validate that HTML
traffic is indeed HTML traffic.
2.) Can you pass or run some kind of IDENTd check at the firewall.
3.) Is there some application that can validate if specific applications
are running on an internal host before allowing traffic from that host
to access the internet.

The answers were given; they are:
1.) No, this is not something a firewall generally does.  The over head
to do this would cause the firewall to suffer.  Use an IDS system which
is designed for this purpose.  As it will also be able to validate FTP,
HTTPS, HTTP, etc as well.
2.) Why?  Yes we all have a trick for doing this, but again this isn't
something a firewall does, or should do.  Most of us pass the identd
port to an internal host running some form of IDENT proxy.  Identd
should never be used to authenticate users to the firewall, it is far
too easy to spoof.  As there is no checksum for validation I could tell
it I am the Pope (no offence to anyone) and it would believe me.
3.) No.  Again, not something a typical firewall would do.  Yes some
systems like Linksys and the big boys like Checkpoint do this by
transparent proxy, then again they can do other things too like fork
HTML traffic to a proxy host, etc.   These are all nice things, but not
what a firewall should do if you followed RFCs .  They are all add-ons
to the principal of having a good firewall.  As I can force any Linksys
firewall to crash in a matter of seconds, thus DoSing the person using
it... I would say these specific features are not worth it to the customer.


They are all good ideas, and who knows some of them may end up in the
product.  I would like to see the ability to setup a transparent HTML
proxy, especially once I have kids and want to filter the content they
are able to access on the web.  Then again I wouldn't do this based on
Identd, I would do it based off of IP addresses that were hard set to
the MAC Address on the machines.  (You can do that with m0n0wall
currently.)  But I would want to keep IDS / Sniffer type applicatons on
seperate boxes and not make them part of the "firewall."


Mitch (WebCob) wrote:

>still wondering why you guys hijacked my thread?
>
>Start a new thread for new discussion please.
>
>Makes it harder for everyone to follow when you do this, and decreases the
>chance you will get a response.
>
>Thanks.
>
>m/
>
>-----Original Message-----
>From: Brandon Holland [mailto:brandon at cookssaw dot com]
>Sent: Tuesday, December 30, 2003 1:18 PM
>To: 'Falcor'
>Cc: m0n0wall at lists dot m0n0 dot ch
>Subject: RE: [m0n0wall] windows built in "ident"...
>
>
>Everything that examines a packet is potentially a security risk.
>
>Since I don't need to give an ident response (just a reset packet), I'd
>hate taking the (albeit minimal) risk.
>
>The PERL script or the interpreter could be flawed.  It also takes
>overhead to use and interpret it.
>
>To me, besides being a security risk it is a waste of my time (to
>configure and maintain), and server resources.  Besides, I don't have an
>"extra" server, and I wouldn't want to put a direct port forward (for
>perl or any program) straight to my main server.
>
>Port forwards should never go to your "GREEN" connection - only go to
>your DMZ.  (That'd defeat the purpose of DMZ)
>
>I'm just saying, I'd rather have the weakest link be the BSD tcp stack
>(which I hear is probably the best tcp implementation period) than
>something else.
>
>Ideally in my situation, only a select group of IP's get a RESET packet
>(IRC servers and the like) Everything else? It'd get dropped.
>
>If I had something that actually needed a "correct" ident response
>(maybe there are still some IRC servers out there that must "qualify"
>you?) maybe then, if those IRC servers were important, I'd do it. BUT: I
>still wouldn't want a port forward straight into my LAN.
>
>Ideally, in that case, it'd be its own separate server in the DMZ.
>Assuming your DMZ is well protected (and set up with performance
>counters and other "detection" algorithms), you now know, and have time
>to correct a flaw (and to kick out a hacker)
>
>I didn't mean to turn this into a rant :) but F.Y.I. even NTP servers as
>humble and simple as they are have fallen victim to hackers able to act
>upon a flaw in NTP.
>
>Still wanting "rejection,"
>Brandon
>
>-----Original Message-----
>From: Falcor [mailto:falcor at netassassin dot com]
>Sent: Tuesday, December 30, 2003 1:45 PM
>To: Brandon Holland
>Cc: 'Mitch (WebCob)'; m0n0wall at lists dot m0n0 dot ch
>Subject: Re: [m0n0wall] windows built in "ident"...
>
>I use a PERL application that mimics an IDENTd daemon.  I then forward
>all identd requests to that unix server.  All my internal clients then
>can access IRC and other identd based auth systems with no problems.
> And I don't risk much as the perl script simply replies with what I put
>
>in a text file as the ident info, and not a compramizable component on a
>
>windows box.
>
>Brandon Holland wrote:
>
>
>
>>You can allow IDENT based on certain IP's (say if you use a select
>>
>>
>group
>
>
>>of IRC servers)
>>
>>And if we can add a "REJECT" you don't even have to fully allow ident
>>anyway.  (Leave out your IRC app as a possibly hackable component)
>>
>>-----Original Message-----
>>From: Mitch (WebCob) [mailto:mitch at webcob dot com]
>>Sent: Tuesday, December 30, 2003 2:43 AM
>>To: m0n0wall at lists dot m0n0 dot ch
>>Subject: [m0n0wall] windows built in "ident"...
>>
>>this may not be in here yet... maybe it's not easy... but if someone
>>could
>>point me in the right direction that would be a start...
>>
>>Other firewalls support passing requests made by certain
>>
>>
>applications...
>
>
>>zone alarm or black ice for example - and the parts they have
>>
>>
>integrated
>
>
>>with linksys routers... can detect a bogus HTTP request generated by a
>>program OTHER THAN Internet Explorer (like by a virus or a messenger
>>program
>>trying to circumvent the firewall) and shut them down...
>>
>>They are able to detect the NAME of the application initiating the
>>request...
>>
>>I'm thinking this is parallel to identd, but seems to be built into
>>windows... Does anyone know what it's called or where the protocol is
>>defined? Could be an interesting addition... I'd like to poke around in
>>this
>>area, but can't find where to start.
>>
>>Thanks.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>
>>
>>
>>
>>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>
>