[IPCop-devel] Website update

[Mark Wormgoor <mark@wo...>]

Hi,

Just to let you know that I just updated the website to PostNuke 0.750 + 
  a fix for security advisory PNSA 2005-1.
If you find any problems, please let me know.

Kind regards,

Mark Wormgoor
-- 
*********************************************************************
* |\    /|      |  /|  /      E-mail: mark@...             *
* | \  / |      | / | /       Blog:   http://www.wormgoor.com/mark/ *
* |  \/  |ark   |/  |/ormgoor Web:    http://www.wormgoor.com/      *
*********************************************************************

[IPCop-devel] Re: IPCop support web site is back on line

[David W Studeman <davews@my...>]

Milan wrote:
>Just quick note: Site is back on line using new host.
>
>Regards,
>Milan
>
>  
 It is working on IPCops.com I see. Thanks!


Dave

Re: [IPCop-devel] Using squid to combat spyware and unauthorized

[David W Studeman <davews@my...>]

Ray Ellison wrote:
>------------------------------------------------><SNIP><
>---------------------------------------------------
>  
>>>A proxy is the heart of any good firewall and is more secure than just
>>>      
>masquerading. If you disable it and don't use cache, you may >>as well go
>buy a small firewall router at the computer store. If a proxy doesn't belong
>in a firewall, then where does it belong? 
>
>  
>>>Dave
>>>      
>
>FWIW General security consensus guidelines for best practice say the proxy
>should be installed on a bastion host in the network DMZ, however there are
>many take's on this. For example Microsoft have their ISA proxy in Small
>Business Server, and the audacity to call it a "firewall".
>
>I think that having Squid in IPcop is a small compromise between security
>and functionality that is justified. It sets the IPcop approach apart from
>the plethora of ADSL router/firewall devices hitting the market nowadays.
>
>Just my 2 cents worth...
>
>Ray 
>
> Ray Ellison 
>Microsoft Certified Systems Engineer
>PH: 0419 285 246
>email: Ray@...
>        
>  
 Squid is a real saviour for dialup users and that as well as other 
features definitely set it apart from the low power routers people 
usually use. It feels naked to not use a caching proxy after you have 
been doing it for a while. I get a kick out of doing updates on one 
machine and watching other machines get the same updates in seconds.


Dave

RE: [IPCop-devel] Using squid to combat spyware and unauthorized software

[Ray Ellison <Ray@EllisonFamily.net>]

------------------------------------------------><SNIP><
---------------------------------------------------
>> A proxy is the heart of any good firewall and is more secure than just
masquerading. If you disable it and don't use cache, you may >>as well go
buy a small firewall router at the computer store. If a proxy doesn't belong
in a firewall, then where does it belong? 

>>Dave

FWIW General security consensus guidelines for best practice say the proxy
should be installed on a bastion host in the network DMZ, however there are
many take's on this. For example Microsoft have their ISA proxy in Small
Business Server, and the audacity to call it a "firewall".

I think that having Squid in IPcop is a small compromise between security
and functionality that is justified. It sets the IPcop approach apart from
the plethora of ADSL router/firewall devices hitting the market nowadays.

Just my 2 cents worth...

Ray 

 Ray Ellison 
Microsoft Certified Systems Engineer
PH: 0419 285 246
email: Ray@...
        
Please send attachments using MIME encoding.
Public Key Available On Request.    
----------------------------------------------------------------------------
------------
How secure is your computer on the Internet?
When did you last run Windows Update?
Have you applied the MS Office servicepacks?
Is your Antivirus program up to date, and can it scan email before you read
it? 
Do you have a firewall installed?
It makes you think doesn't it.......
----------------------------------------------------------------------------
------------

Re: [IPCop-devel] Using squid to combat spyware and unauthorized software

[David W Studeman <davews@my...>]

Robert Kerr wrote:
>In message <6.2.1.2.0.20050225211139.02840638@...>
>          Scott Tregear <scottt@...> wrote:
>
>[snip]
>
>  
>>Using squid to log HTTP User-Agent headers allows you to centrally monitor,
>>detect, identify, and distinguish between "good" and "bad" agents that
>>connect through your web proxy. The results from log analysis can be used
>>and applied to build effective HTTP header filters that complement other
>>methods achieved with add-on programs for squid.
>>    
>
>  
>>If you have a counter-argument to my proposal, I'd like to hear it. Barring
>>that, I really hope the developers will recompile squid to support
>>User-Agent and Referer logging so I can get on with building appropriate
>>filters to protect my systems and networks from abuse. Thanks for reading
>>my post. :-)
>>    
>
>Obviously the more features you compile in, the more code, and the more code
>the more potential for bugs and security issues. This is probably a pretty
>flimsy argument given the number of issues in the core squid code already
>this year though. Given that you're advocating this not actually be enabled
>by default, just compiled in, I really can't see any reason not to do it. The
>features are rather simple and probably highly unlikely to introduce any bugs
>anyway.
>
>That said I've always advocated we remove squid entirely - I have no idea
>what it's doing on a firewall in the first place and never enable it myself.
>I suspect I'm in a minority here though, your mileage may vary.
>
>  
 A proxy is the heart of any good firewall and is more secure than just 
masquerading. If you disable it and don't use cache, you may as well go 
buy a small firewall router at the computer store. If a proxy doesn't 
belong in a firewall, then where does it belong?

Dave

Re: [IPCop-devel] SNAT ?

[Dennis Freise <cat@fi...>]

On Fri, 25 Feb 2005 19:52:28 GMT
Robert Kerr <LittleThor@...> wrote:

> The problem you'll experience with the first part is DNAT is done in the
> prerouting chain and SNAT in the postrouting. So by the time you get to the
> point where you can SNAT the destination has been altered by the DNAT and you
> can't tell whether the traffic was headed for the the orange machine directly
> or to the red IP. The way to get round it is to use the mangle table with a
> MARK target to set a mark on the packets then do the SNAT based on this mark.

I liked that idea, so I implemented it :)

A patch to setportfw.c is attached to this mail. This should make both groups
happy, the ones hitting the red interface from green, and the ones like me who
don't want to be SNATed :)

I would be happy if this could be included in 1.4.3

Greetings,
-- 
Dennis Freise <cat@...>
GnuPG key: 2DE8 CCEF 6E20 11D4 3B27  21EC B0BA 1749 D2C8 38ED
Available at: http://www.final-frontier.ath.cx/?key-plain

Re: [IPCop-devel] Using squid to combat spyware and unauthorized software

[Robert Kerr <LittleThor@xs...>]

In message <6.2.1.2.0.20050225211139.02840638@...>
          Scott Tregear <scottt@...> wrote:

[snip]

> Using squid to log HTTP User-Agent headers allows you to centrally monitor,
> detect, identify, and distinguish between "good" and "bad" agents that
> connect through your web proxy. The results from log analysis can be used
> and applied to build effective HTTP header filters that complement other
> methods achieved with add-on programs for squid.

> If you have a counter-argument to my proposal, I'd like to hear it. Barring
> that, I really hope the developers will recompile squid to support
> User-Agent and Referer logging so I can get on with building appropriate
> filters to protect my systems and networks from abuse. Thanks for reading
> my post. :-)

Obviously the more features you compile in, the more code, and the more code
the more potential for bugs and security issues. This is probably a pretty
flimsy argument given the number of issues in the core squid code already
this year though. Given that you're advocating this not actually be enabled
by default, just compiled in, I really can't see any reason not to do it. The
features are rather simple and probably highly unlikely to introduce any bugs
anyway.

That said I've always advocated we remove squid entirely - I have no idea
what it's doing on a firewall in the first place and never enable it myself.
I suspect I'm in a minority here though, your mileage may vary.

-- 
 Robert Kerr

[IPCop-devel] Using squid to combat spyware and unauthorized software

[Scott Tregear <scottt@bu...>]

-------------------------------------------------------
Using squid to combat spyware and unauthorized software
-------------------------------------------------------
I wish to make a case for *why* it would be worthwhile to recompile squid 
with two extra configure options to support logging of User-Agent and 
Referer header fields. Before making that case, I thought I'd first 
summarize the changes that will be required by the developers:

(1) recompile squid with additional compile-time options
(2) modify /var/ipcop/proxy/acl
(3) modify /etc/logrotate.conf

In the first half of this post I include details on *how* to make each of 
these changes, of interest to developers. In the second half I discuss 
*why* these changes would be useful in practice, showing, by example, how 
information gleaned from the these logs could be applied effectively to 
combat spyware and unauthorized software, hopefully of interest to users 
and developers alike.

----------------------------------
Changes required by the developers
----------------------------------
The additional compile-time options are:
'--enable-useragent-log'
'--enable-referer-log'

The latest CVS (ipcop/ipcop/lfs/squid, Revision: 1.4.2.12) shows that 
Gilles has upgraded squid to v2.5.STABLE9. However, this binary--like all 
squid binaries included with IPCop in the past--was built without support 
for logging either of these two header fields. Could it be rebuilt (once 
again!) with these options included in time for the IPCop 1.4.3 release, or 
the release after that?

I want to emphasize at the outset that squid compiled with 
'--enable-useragent-log' doesn't mean squid will log the User-Agent header 
field! It merely means squid is *capable* of logging it. Same holds true 
when compiling squid with '--enable-referer-log'. To actually log the 
User-Agent and Referer header fields, one would *also* need to include 
lines like the following in /var/ipcop/proxy/acl (or equivalent):

---- cut ----
useragent_log      /var/log/squid/user_agent.log
referer_log        /var/log/squid/referer.log
---- cut ----

I suggest modifying the default '/var/ipcop/proxy/acl' file to include the 
following block of comments, inserted at the top.

---- cut ----
# Do not modify '/var/ipcop/proxy/squid.conf' directly since any changes
# you make will be overwritten whenever you resave proxy settings using the
# web interface! Instead, modify the file '/var/ipcop/proxy/acl' and then
# restart squid using the web interface. Changes made to the 'acl' file
# will propagate to the 'squid.conf' file at that time.
# [Scott Tregear, 22 Feb 2005]

# Uncomment the following line to enable logging of User-Agent header:
#useragent_log      /var/log/squid/user_agent.log

# Uncomment the following line to enable logging of Referer header:
#referer_log        /var/log/squid/referer.log
---- cut ----

As you can see, my recommended default behaviour for squid on IPCop is to 
*not* log these headers. Only if an IPCop user deliberately uncomments the 
appropriate line(s) will logging kick in. Another way of accomplishing the 
same thing would be to modify the proxy.cgi script (web interface), to 
provide *two* new check boxes (defaults: unchecked). One box to enable 
logging of User-Agent header, and one to enable logging of Referer header.

Importantly, the default behaviour of squid on an IPCop box will remain the 
same as in the past, with negligible (likely zero) impact on performance or 
security. File size and memory requirements of the recompilied squid binary 
will likely be only marginally larger so these factors shouldn't be much of 
a concern either.

However, an IPCop admin who wishes to enable logging either (or both) of 
these headers will now have the flexibility to do so. In this case, impact 
on performance will be higher than in the default case--but I wouldn't 
expect this to be very significant unless IPCop is installed on a very 
low-end system and a large number of users connect through it. Impact on 
security? I'm not aware of anything significant here except to point out 
that these logs should be rotated weekly, if they exist. To support this, I 
suggest modifying /etc/logrotate.conf as follows:

change the single line:
/var/log/squid/access.log {

to the single line:
/var/log/squid/access.log /var/log/squid/user_agent.log 
/var/log/squid/referer.log {

+-------------------------------------------------------+
| As far as I know those are all the changes required   |
| on IPCop 1.4.3 to support squid logging of User-Agent |
| and Referer header fields.                            |
+-------------------------------------------------------+

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

To justify *why* these changes would be useful in practice, I now present a 
practical example showing how the info contained in squid's User-Agent and 
Referer logs could be applied to combat spyware, Trojans, and other types 
of unauthorized software. This method is complementary to other filtering 
methods that you can do with squid using various add-on software such as 
squidguard, adzapper, squirm, and so on.

----------
Background
----------
Spyware programs typically have their own HTTP signature, which may be a 
URL pattern or the value of the HTTP "User-Agent" field, or both. Spyware 
from Gator (a.k.a. OfferCompanion, Trickler, or GAIN) uses the custom 
User-Agent HTTP header "Gator/x.xx" (or "Gator/x.x"), where "x.xx" is the 
version number of the Gator client. The eZula spyware program uses three 
specific User-Agent fields: "eZula", "mez", or "Wise", depending on the 
specific program version. I gleaned these facts (along with tons more) from 
an excellent paper:

"Measurement and Analysis of Spyware in a University Environment"
http://www.cs.washington.edu/homes/gribble/papers/spyware.pdf

Trojans, worms, and other nasties are also known to connect via HTTP; 
therefore, it may also be the case that at least some of these also have 
their own HTTP signature. Since these nasties may leak sensitive 
information to the outside world, or cause havoc in a variety of other 
ways, wouldn't it be nice to prevent them from doing so!

In addition, there are (possibly legitimate) programs responsible for 
auto-updating/auto-upgrading client software. Many of these connect via 
HTTP (or FTP) and have their own HTTP signature. Then there are the 
different web browsers (Firefox, MSIE, Opera, ... whatever) that everyone 
knows about. In your environment, some of these software programs (or a 
particular version!) may be considered unauthorized, in which case you 
might want to prevent users from using them and/or prevent the 
auto-updaters from fetching and installing updates until you've had time to 
test the update yourself.

Logging the User-Agent header field with squid would allow IPCop admins to 
monitor/detect which user-agents are connecting through it. Logging the 
Referer header field provides yet another method for information gathering, 
and another means of detecting various attacks that you may want to 
prevent. I won't specifically discuss how these Referer logs could be 
applied but the concept is analogous to what I will say next about 
User-Agent logs.

--------------------------------------------------------
Applying information gathered from squid User-Agent logs
--------------------------------------------------------
Analysis of User-Agent logs would make it possible (in at least some cases) 
to identify which agents are legitimate/authorized/required, and which ones 
are not, in your environment, according to their HTTP signature and your 
computer security policy definitions and objectives.

The results from the analysis could then be used to construct and implement 
HTTP header-filters appropriate in your environment. Applying these filters 
as part a defence-in-depth strategy may help enforce your computer security 
policy objectives.

As always with security, there are two main approaches you can use to 
implement your filters. The following outlines two strategies for filtering 
based on the HTTP User-Agent header field:

(1a) allow only the User-Agent headers you know are "good";
(1b) block all others (default deny policy)

-- or --

(2a) block only the User-Agent headers you know are "bad";
(2b) allow all others (default allow policy)

The first approach is arguably (much) better since the number of 
user-agents known to be "good", according to your definition of "good", is 
relatively small and probably changes fairly infrequently. All the other 
user-agents, the "bad" ones, will be blocked; you don't have to know about 
any of them in advance. If all your clients can be configured to use 
non-blank User-Agent headers, then your policy can deny any agent that 
leaves this HTTP header field blank; this will likely increase the 
effectiveness of this filter enormously.

The second approach requires that you maintain a list of (all) the "bad" 
User-Agent signatures in advance. This won't be an easy task and isn't 
practical in the general case. "Bad" agents number in the thousands (for 
spyware alone), and the signatures change constantly.

A blended approach is also possible, and can be used to your advantage. For 
an example, see:

"Using Squid to block Internet Explorer"
http://gaugusch.at/squid.shtml

-----------
Final words
-----------
Using squid to log HTTP User-Agent headers allows you to centrally monitor, 
detect, identify, and distinguish between "good" and "bad" agents that 
connect through your web proxy. The results from log analysis can be used 
and applied to build effective HTTP header filters that complement other 
methods achieved with add-on programs for squid.

If you have a counter-argument to my proposal, I'd like to hear it. Barring 
that, I really hope the developers will recompile squid to support 
User-Agent and Referer logging so I can get on with building appropriate 
filters to protect my systems and networks from abuse. Thanks for reading 
my post. :-)
--
Scott Tregear

[IPCop-devel] Masquerading on the Blue network

[Matt Breedlove <MattB@bl...>]

Thats makes perfect sense, however it would seem that even publicly=
 routable addresses off of for instance the orange network (or the blue)=
 would get masqueraded when in fact one does not want those masqueraded.
=0D
So is it just not possible to host public ips behind the ipcop box?=0D
=0D
Anyonelse have any clues as to why my blue network is not being masqueraded

___________
This communication is for the intended recipient only.  This communication=
 may contain=0D
information that is privileged, confidential and exempt from disclosure=
 under applicable=0D
law and constitutes an electronic communication within the meaning of the=
 Electronic=0D
Communications Privacy Act, 18 U.S.C. 2510.  Disclosure is strictly limited=
 to the=0D
recipient intended by the sender. This communication is intended for the=
 sole use of the=0D
intended recipient and receipt by anyone other than the intended recipient=
 does not=0D
constitute a loss of the confidential or privileged nature of the=
 communication. If you=0D
are not the intended recipient or agent responsible for delivery, you are=
 hereby notified=0D
that any unauthorized use, dissemination, distribution or copying of this=
 communication=0D
is strictly prohibited and may subject you to criminal or civil penalty. If=
 you have=0D
received this communication in error, please notify us immediately by=
 email, delete the=0D
message, and destroy any copies.=0D

Re: [IPCop-devel] missing file on 1.4.2 buld

[Nick Rout <nick@ro...>]

Just to say my own particular gcc problem seems to have been to do with a
lack of memory. I have 256M RAM and 256M swap. I had a particularly memory
hungry app running, which I stopped. gcc has now compiled.

Like Eric I have had to scratch around for a couple of files. Google tends
to find them, or the app's own homepage (like with logwatch that had
disappeared to a /old/ directory.

Old versions seem to go off mirrors pretty quickly, the app homepage often
has a repository of older stuff, not always replicated on the mirrors.



On Fri, February 25, 2005 11:05 pm, Eric Boniface said:
> Hello,
>
> so finally I found linux-2.4.27-frandom* in :
> http://www.linuxfromscratch.org/~robert/hlfs/current/hlfs-patches-20050106/linux-2.4.27-frandom-2.patch
>
> Pay attention that since yesterday, logwatch is now version 6.0.1
> (IPCop's make.sh wants 5.2.2 that has been removed from
> ftp://ftp.kaybee.org/pub/linux/).
> I found it here : ftp://ftp.kaybee.org/pub/old/linux/logwatch-5.2.2.tar.gz
>
> I put in attachment a patch file regarding the changes I made; don't
> know if this can help.
>
> Eric.
>
> On Thu, 24 Feb 2005 12:22:36 +0100, Gilles Espinasse <g.esp@...>
> wrote:
>> Selon Eric Boniface <eric.boniface@...>:
>>
>> > Hello all,
>> >
>> > After downloading the last CVS snapshot, I have just run a make.sh
>> > check and I had several errors :
>> >
>> > - firstly I had to increase the wget timeout from 10 to 30 seconds.
>> > Otherwise,  I get several errors in downloading files.
>> > - after that I still have the following errors :
>> > .
>> >
>> http://wiretapped.securax.org/security/host-security/shadow/old/shadow-4.0.4.1.tar.gz
>> > : the web site seems to be done. So I comment out the DL_FROM in the
>> > lfs/shadow file and it works fine.
>> > .
>> >
>> http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27-frandom-2.patch
>> > is missing (ERROR 404)
>> >
>> > For the last one do you have any idea ?
>> > Thanks in advance,
>> > Eric.
>> >
>> concerning the two files,you should find a alternate source with google.
>> The file md5sum is now checked after download, so it is secure.
>>
>> I read one of the lsf list and the author of frandom patch has enhanced
>> the
>> patch for 2.6 kernel but not yet backported for 2.4
>> I will include this patch in ipcop src/patches.
>>
>>
>> Gilles
>>
>

Re: [IPCop-devel] SNAT ?

[Robert Kerr <LittleThor@xs...>]

In message <20050225191535.00002fbb@...>
          Dennis Freise <cat@...> wrote:

> On Fri, 25 Feb 2005 13:26:53 +0000
> Robert Kerr <LittleThor@...> wrote:

> > There is one bug in this though, currently IPCop SNATs all traffic from
> > green to any port that has a port forward facing it. This includes
> > traffic going directly to server_ip:port as well as traffic that was
> > directed at red_ip:port and has been port forwarded. This basically
> > happens because it's a lot easier to code that way - but really the SNAT
> > should only be applied to traffic pointed at red_ip:port.

> I agree.

> > There should probably be an option to disable the SNAT entirely too.
> > I was meaning to start writing the code for this yesterday, but got
> > distracted by other things.

> That would be fantastic. Okay, since you sound busy, I'll give you a
> helping hand and have a look at setportfw.c, and see, if I can give it
> rules that only apply to traffic directed at the red interface. I'll send
> you my code as soon as it's ready - if you come up with a solution, I would
> be happy if you keep me in the loop :)

The problem you'll experience with the first part is DNAT is done in the
prerouting chain and SNAT in the postrouting. So by the time you get to the
point where you can SNAT the destination has been altered by the DNAT and you
can't tell whether the traffic was headed for the the orange machine directly
or to the red IP. The way to get round it is to use the mangle table with a
MARK target to set a mark on the packets then do the SNAT based on this mark.

Making SNAT optional on the otherhand ought to be comparatively easy, only
issue is there isn't really an appropriate page in the web interface to place
the option in. You could maybe put it in the port forward page I guess, or
alternatively just leave it as something that can only be toggled at a lower
level with a config edit. The latter may actually be preferable as explaining
to newbies what this does would be pretty complicated.

> > Best I can suggest as a temporary measure is to add a rule in rc.local
> > that deletes the reference to POSTPORTFW from the POSTROUTING chain.

> I guess that doesn't work when you add/delete/change portforward via the
> webinterface ? Well... I prefer permanent solutions, so I'll get to work
> right now ;)

Should work ok - the web interface will flush and recreate rules in the
POSTPORTFW chain, but if there's not a rule in POSTROUTING to redirect
traffic through POSTPORTFW it really doesn't matter what's in it. Of course I
could be missing something, but the base rules shouldn't change after a
reboot; it's only the separate chains that are rewritten by the web
interface, not the base ones.

-- 
 Robert Kerr

Re: [IPCop-devel] Masquerading on the Blue network

[Dennis Freise <cat@fi...>]

On Thu, 24 Feb 2005 10:40:08 -0800
"Matt Breedlove" <MattB@...> wrote:

> # Outgoing Masquerading
>=20
> /sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE

Masquerading is activated an the outgoing interface - the red interface. It
doesn't matter where the source-traffic is coming from. Green, orange and b=
lue
will all be masqueraded, because all traffic going out on the red interface=
 will
be masqueraded. (-o =3D out interface)

I have now idea why masq on blue doesn't work for you.

--=20
Dennis Freise <cat@...>
GnuPG key: 2DE8 CCEF 6E20 11D4 3B27  21EC B0BA 1749 D2C8 38ED
Available at: http://www.final-frontier.ath.cx/?key-plain

Re: [IPCop-devel] SNAT ?

[Dennis Freise <cat@fi...>]

On Fri, 25 Feb 2005 13:26:53 +0000
Robert Kerr <LittleThor@...> wrote:

> So in 1.4 we decided to SNAT from green (as described in the HOWTO) in
> order to allow people to access and test their port forwards from green.
> Unfortunately now a commonly asked question and reported bug is the SNAT
> obscuring addresses of browsers in green. You can't win :p

Ah, I see! Thanks for the explanation :)

> There is one bug in this though, currently IPCop SNATs all traffic from
> green to any port that has a port forward facing it. This includes
> traffic going directly to server_ip:port as well as traffic that was
> directed at red_ip:port and has been port forwarded. This basically
> happens because it's a lot easier to code that way - but really the SNAT
> should only be applied to traffic pointed at red_ip:port.

I agree.

> There should probably be an option to disable the SNAT entirely too.
> I was meaning to start writing the code for this yesterday, but got
> distracted by other things.

That would be fantastic. Okay, since you sound busy, I'll give you a helping
hand and have a look at setportfw.c, and see, if I can give it rules that o=
nly
apply to traffic directed at the red interface. I'll send you my code as so=
on as
it's ready - if you come up with a solution, I would be happy if you keep m=
e in
the loop :)

> Best I can suggest as a temporary measure is to add a rule in rc.local
> that deletes the reference to POSTPORTFW from the POSTROUTING chain.

I guess that doesn't work when you add/delete/change portforward via
the webinterface ? Well... I prefer permanent solutions, so I'll get to work
right now ;)

Greetings,
--=20
Dennis Freise <cat@...>
GnuPG key: 2DE8 CCEF 6E20 11D4 3B27  21EC B0BA 1749 D2C8 38ED
Available at: http://www.final-frontier.ath.cx/?key-plain

[IPCop-devel] [ ipcop-Bugs-1151873 ] Proxy on Blue and Green interfaces creates hole

[SourceForge.net <noreply@so...>]

Bugs item #1151873, was opened at 2005-02-25 09:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1151873&group_id=40604

Category: Security (Patches etc)
Group: 1.4.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Glenn Tofte (gtofte)
Assigned to: Darren Critchley (dpcritchley)
Summary: Proxy on Blue and Green interfaces creates hole

Initial Comment:
According to the documentation, by default the blue and
green networks are to be totally separate.  I have
found that enabling the transparent proxy for both of
the internal interfaces will allow someone on the blue
interface to browse to a web server on the green
network.  This happens on an install of 1.4.2 (without
any addons).  When I turn off the transparent proxy on
the blue interface and leave it running on the green
interface, it seems to resolve the problem (as a
temporary work around). 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1151873&group_id=40604

Re: [IPCop-devel] Squid crashes.

[Gilles Espinasse <g.esp@fr...>]

Selon Russ Johnson <russj@...>:

> Does this affect IPCop?
>
> Problem Description:
>
>  The squid developers discovered that a remote attacker could cause
>  squid to crash via certain DNS responses.
> ____________________________________________________________
>
>  References:
>
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCAN-2005-0446
>
>
>
>
Yes in v1.4.2
It is fixed in CVS since a few days with a patch.
I have upgraded squid to v2.5.STABLE9 today and should make an update for
testing tomorrow.
Final version will be released a few days after.

Gilles

Re: [IPCop-devel] SNAT ?

[Robert Kerr <LittleThor@xs...>]

On Fri, 2005-02-25 at 10:59, Dennis Freise wrote:

> My question: Why are the DNATed ports also SNATed from green ? That makes no
> sense to me (or I'm missing something important here) - and it makes writing
> access rules by IP on my servers in the DMZ much harder.

In the days of 1.3 the most frequently asked question we got was "why
don't my port forwards work from green" Many people attempted to test
their port forwards were working by hitting the red interface IP from
green and came to the conclusion port forwards don't work at all. The
problem was a question of routing, it's explained relatively well in the
iptables HOWTO:

http://howto.linuxkungfu.org/iptables/x2433.html#DNATTARGET

So in 1.4 we decided to SNAT from green (as described in the HOWTO) in
order to allow people to access and test their port forwards from green.
Unfortunately now a commonly asked question and reported bug is the SNAT
obscuring addresses of browsers in green. You can't win :p

There is one bug in this though, currently IPCop SNATs all traffic from
green to any port that has a port forward facing it. This includes
traffic going directly to server_ip:port as well as traffic that was
directed at red_ip:port and has been port forwarded. This basically
happens because it's a lot easier to code that way - but really the SNAT
should only be applied to traffic pointed at red_ip:port. There should
probably be an option to disable the SNAT entirely too. I was meaning to
start writing the code for this yesterday, but got distracted by other
things.

Best I can suggest as a temporary measure is to add a rule in rc.local
that deletes the reference to POSTPORTFW from the POSTROUTING chain.

-- 
 Robert Kerr

[IPCop-devel] Re: Permissions on /home/httpd/html ?

[Robert Kerr <LittleThor@xs...>]

On Fri, 2005-02-25 at 08:47, Robert Kerr wrote:
[snip]
> Does anyone know any particular reason why lfs/apache is doing:
> 
> 	chmod -R 755 /home/httpd/cgi-bin /home/httpd/html/index.cgi
> 
> Instead of:
> 
> 	chmod -R 755 /home/httpd/cgi-bin /home/httpd/html

And now I'm more awake I've thought of one - that'd give a whole bunch
of content that only need to be mode 644 an execute bit. Still, the
basic question remains, why does lfs/apache not set appropriate
permissions on /home/httpd/html? bug?

-- 
 Robert Kerr

[IPCop-devel] SNAT ?

[Dennis Freise <cat@fi...>]

Hi everyone,

I've setup an IPCop 1.4.2 some days ago. First things first: Great job! I h=
ad
to make some minor modifications (increase the conntrack limit, lower the
conntrack timeout, allow ICMP from orange), but it's way better than my
Smoothwall 2.0 was.

While looking through some logfiles on my webserver in the DMZ I discovered=
 that
traffic to ports in portforward on the IPCop-box are SNATed from green ->
orange.

My question: Why are the DNATed ports also SNATed from green ? That makes no
sense to me (or I'm missing something important here) - and it makes writing
access rules by IP on my servers in the DMZ much harder.

Greetings,
--=20
Dennis Freise <cat@...>
GnuPG key: 2DE8 CCEF 6E20 11D4 3B27  21EC B0BA 1749 D2C8 38ED
Available at: http://www.final-frontier.ath.cx/?key-plain

Re: [IPCop-devel] missing file on 1.4.2 buld

[Eric Boniface <eric.boniface@gm...>]

Hello,

so finally I found linux-2.4.27-frandom* in :
http://www.linuxfromscratch.org/~robert/hlfs/current/hlfs-patches-20050106/linux-2.4.27-frandom-2.patch

Pay attention that since yesterday, logwatch is now version 6.0.1
(IPCop's make.sh wants 5.2.2 that has been removed from
ftp://ftp.kaybee.org/pub/linux/).
I found it here : ftp://ftp.kaybee.org/pub/old/linux/logwatch-5.2.2.tar.gz

I put in attachment a patch file regarding the changes I made; don't
know if this can help.

Eric.

On Thu, 24 Feb 2005 12:22:36 +0100, Gilles Espinasse <g.esp@...> wrote:
> Selon Eric Boniface <eric.boniface@...>:
> 
> > Hello all,
> >
> > After downloading the last CVS snapshot, I have just run a make.sh
> > check and I had several errors :
> >
> > - firstly I had to increase the wget timeout from 10 to 30 seconds.
> > Otherwise,  I get several errors in downloading files.
> > - after that I still have the following errors :
> > .
> >
> http://wiretapped.securax.org/security/host-security/shadow/old/shadow-4.0.4.1.tar.gz
> > : the web site seems to be done. So I comment out the DL_FROM in the
> > lfs/shadow file and it works fine.
> > .
> >
> http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27-frandom-2.patch
> > is missing (ERROR 404)
> >
> > For the last one do you have any idea ?
> > Thanks in advance,
> > Eric.
> >
> concerning the two files,you should find a alternate source with google.
> The file md5sum is now checked after download, so it is secure.
> 
> I read one of the lsf list and the author of frandom patch has enhanced the
> patch for 2.6 kernel but not yet backported for 2.4
> I will include this patch in ipcop src/patches.
> 
> 
> Gilles
>

[IPCop-devel] Permissions on /home/httpd/html ?

[Robert Kerr <LittleThor@xs...>]

Hi,

I was playing round yesterday with building IPCop and installing it in
bochs. I've build IPCop many times before, but usually just copy changed
files from the build across to a standard install for testing. Yesterday
I actually installed the built ISO directly and found an interesting
issue - the permissions on /home/httpd/html were set to 700 and hence
apache couldn't display index.cgi. Investigating this it seems that
lfs/apache copies html/html directly into build/home/httpd/ and doesn't
set the permissions on it? Does anyone know any particular reason why
lfs/apache is doing:

	chmod -R 755 /home/httpd/cgi-bin /home/httpd/html/index.cgi

Instead of:

	chmod -R 755 /home/httpd/cgi-bin /home/httpd/html

-- 
 Robert Kerr

[IPCop-devel] libata.o module an busybox-1.00

[Enrique E. Martinez Cardenas <emartinez@li...>]

Hi, again in the hope this can help ipcop

I have been able to successfully build a iso to install in a hp dj7100 ( 
ata_piix ).

I need to change the busybox version to 1.00 and create a patch based on 
the previos one to manage gzipped modules.

Attached are the relevant files

busybox-1.00-gzip.patch ( ugly hack to manage gzipped modules but works! 
) -> $BASEDIR/src/patches
busybox10 ( the modified make file to build busybox-1.00 ) -> $BASEDIR/lfs
busybox.config.i386 ( the generated .config for busybox ) -> 
$BASEDIR/config/kernel

you need to modify the line in make.sh where
    installmake busybox -> installmake busybox10

remove the initrd target && rebuild.

hope this helps!!!!!

regards.
enmaca

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

[IPCop-devel] Squid crashes.

[Russ Johnson <russj@di...>]

Does this affect IPCop?

Problem Description:

 The squid developers discovered that a remote attacker could cause
 squid to crash via certain DNS responses.
____________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0446

[IPCop-devel] [ ipcop-Bugs-1151268 ] Proxy dies...can't figure out why.

[SourceForge.net <noreply@so...>]

Bugs item #1151268, was opened at 2005-02-24 10:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1151268&group_id=40604

Category: Web Proxy
Group: 1.4.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Shawn Clark (rulitz)
Assigned to: Darren Critchley (dpcritchley)
Summary: Proxy dies...can't figure out why.

Initial Comment:
Occasionally Squid dies on one of my IPCop boxes. It
was happening every month or two or so on versions
1.4.0 & 1.4.1.....then all of a sudden it has happened
3 times in the last 2 days, once was overnight when
there was no usage at all.

It is setup as a transparent proxy.

My disk space is fine:
Filesystem            Size  Used Avail Use% Mounted on
rootfs                4.7G  173M  4.3G   4% /
/dev/root             4.7G  173M  4.3G   4% /
/dev/harddisk1         16M  3.8M   11M  26% /boot
/dev/harddisk2         14G  709M   13G   6% /var/log

I am not seeing any evidence in syslog as to why this
is happening. When restarting Squid back up it doesn't
report anything wrong either.

I just now upgraded to 1.4.2, but I don't see anything
in the changelog that refers to any bugs in this area.

I noticed someone else on the mailing list was having
this problem as well.

Thanks.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1151268&group_id=40604

[IPCop-devel] Masquerading on the Blue network

[Matt Breedlove <MattB@bl...>]

It seems that there is some strange behavior going on when it comes to
Nat on the Blue interface.

The reason I say this is that when I try any sort of access to the red
network (internet, even pinging my cable modem or the modems default
gateway) if I look at the Connections pages it shows the Expected Dest
Ip and Port  being the the internal addressing scheme I am using on the
blue network, whereas connections from the green show the IP of Red
interface (public ip) as the expected DST IP.

The address space I am using on the blue is a standard RFC1918 space
192.168.x.x/24. The traffic is allowed out by IPcop, but obviously can't
return because masquerading is not happening for Blue, but works
properly with Green.

I am using IpCop 1.4.2. I have seen the line in the rc script that has
the comment:

# Outgoing Masquerading

/sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE=0D

, but it is not clear if this is the same line that enables masquerading
for the Blue network. How does Ipcop know whether to masquerade the Blue
network unless it is specifically looking for RFC1918 addresses off of
Blue?
Thanks in advance, Any clues?

-Matt


___________
This communication is for the intended recipient only.  This communication=
 may contain=0D
information that is privileged, confidential and exempt from disclosure=
 under applicable=0D
law and constitutes an electronic communication within the meaning of the=
 Electronic=0D
Communications Privacy Act, 18 U.S.C. 2510.  Disclosure is strictly limited=
 to the=0D
recipient intended by the sender. This communication is intended for the=
 sole use of the=0D
intended recipient and receipt by anyone other than the intended recipient=
 does not=0D
constitute a loss of the confidential or privileged nature of the=
 communication. If you=0D
are not the intended recipient or agent responsible for delivery, you are=
 hereby notified=0D
that any unauthorized use, dissemination, distribution or copying of this=
 communication=0D
is strictly prohibited and may subject you to criminal or civil penalty. If=
 you have=0D
received this communication in error, please notify us immediately by=
 email, delete the=0D
message, and destroy any copies.=0D

[IPCop-devel] EXPORT_SYMBOL_GPL and busybox

[Enrique E. Martinez Cardenas <emartinez@li...>]

Hi again,

The libata module uses EXPORT_SYMBOL_GPL, which its not reconized by
busybox-0.60.5.

are any reason to not use busybox 1.0?


Regards
enmaca

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.