/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */
Hello Julian,
I've emailed Robert Novak @ www.indyramp.com if there is a masq-dev
archive. There is one for the main MASQ list.
Anyway, I'm curious if there will be a MASQ fix back ported
to the 2.0.x kernels as well. I'm amazed how many 2.0.x
kernel users are still out there.
--David
> Hello,
>
>On Tue, 4 Apr 2000, David A. Ranch wrote:
>
>>
>> > It seems that the following code is not useful:
>>
>> This isn't true at all!
>>
>> This code is very useful for people that play games behind MASQ servers.
>> I have already been in comunications with Juan Ciarlante, the current
>> MASQ code maintainer and several other Masq kernel gurus (Nigel, etc).
>>
>> In the 2.0.x kernels, this was configurable at compile time via the
>> Loose_UDP option. In the current 2.2.x kernels, it was enabled by
>> default. In future 2.2.x kernels, this code will be improved on to
>> be more intelligent and probably be disabled by DEFAULT
>> via an option in /proc. I will soon document this in the HOWTO when
>> people will need to enable this feature.
>>
>
> When I said not useful I meant that this is the problem.
>If you continue to read the next messages in the thread you will
>see where is the problem. The solution in 2.2.15pre17 is not good.
>Oh, god. Is the masq-dev threads indexed anywhere in the web? Find them,
>please. If the option is disabled NO_DADDR entries are created instead of
>DLOOSE. Don't hurry to document anything. We have to solve many problems
>including the UDP loose option. It seems that the ms->flags changes will
>go out of the ip_masq_new routine, so this code is not _useful_ there.
>It must be in ip_fw_masquerade but not in this form.
>
> With the new option enabled we are vulnarable to DoS. The
>tunnel can be hijacked and the internal host will never receive
>the first packet from the external dest it is talking to. Before pre17
>we still can receive this packet (and other packets too which many people
>think it is a problem).
>
> There are also some dark zones in the hash tables which must
>be corrected. Everyone experience problems when the dyn IP is changed.
>OK, we are going to solve these problems too with the more graceful
>transition to the new IP - for the UDP and TCP outgoing connections.
>
> And again, I still don't understand what hole we closed with the
>new option. We can say that every host in the internet is vulnerable when
>UDP is used. Known fact. Why this is a problem with the internal hosts.
>The spoofing can be dropped from the firewall. I still don't have an
>example for an internal service that can be fooled with such packets.
>Please, anyone to give examples.
>
>P.S. Is there an URL for the masq-dev threads? It seems they are
>masqueraded^H^H^H^H^H^H^H^H^H^H^H not visible to the world :)
>
>
>Regards
>
>--
>Julian Anastasov <[EMAIL PROTECTED]>
>
.----------------------------------------------------------------------------.
| David A. Ranch - Linux/Networking/PC hardware [EMAIL PROTECTED] |
!---- ----!
`----- For more detailed info, see http://www.ecst.csuchico.edu/~dranch -----'
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES
UNSUBSCRIBING!
or email to [EMAIL PROTECTED]
PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.
