devil-linux-develop — developer discussions

Re: [Devil-linux-develop] config on USB

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:
>>I just checked in the first part of "configuration on USB device".
>>You can now store your etc.tar.bz2 + patches on the root of a FAT 
>>formatted USB device.
> 
> 
> Great timing!  The USB memory stick I ordered just arrived today!  :-)

I don't know when I try to put a entire DL on a USB stick. With a bit 
luck I try it this weekend.

>>NOTE: save-config doesn't support it yet, you have to do it by hand.
> 
> 
> How is the script going to know if it should save to floppy or USB?

I didn't decide this yet, so far I probably go this road:
  check for floppy, if not present check for USB memory device.
   if etc.tar.bz2 found, save
   otherwise offer to create new config, but list all available config 
  storage devices and make user select one


cya
   Heiko

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:
>>>>Add a comment to insert ones own rules _above_ the logging rules
>>>>and leave some more free lines in the script there so users really
>>>>see it.
>>>
>>>I figured if someone was knowledgeable enough to add their own rules,
>>>they would know where to add them.  Depending on what they want to do,
>>>they may need to add rules in other places too.  
>>>
>>>Is that really necessary?
>>
>>If we are preparing a script for beginners....
> 
> 
> Exactly.  Beginners should not be writing netfilter rules (IMO).
> Nobody without a good knowledge of the subject should be writing rules.
> They do so at their own risk.  Maybe we need a disclaimer in the script?
> 

It's a good idea to add one, "absolutely no warranty of any kind" or 
something similar.
The GPL *should* take care of this, but you never know...

Heiko

Re: [Devil-linux-develop] config on USB

[Bruce S. <bw...@ar...>]

> I just checked in the first part of "configuration on USB device".
> You can now store your etc.tar.bz2 + patches on the root of a FAT 
> formatted USB device.

Great timing!  The USB memory stick I ordered just arrived today!  :-)

> NOTE: save-config doesn't support it yet, you have to do it by hand.

How is the script going to know if it should save to floppy or USB?

 - BS

Re: [Devil-linux-develop] TERM bug?

[Bruce S. <bw...@ar...>]

> > Since upgrading to the 0.6beta releases, "vi" gives me garbage unless I
> > "export TERM=vt100" before hand (ssh'ed in as root).  I never had to do
> > that with 0.5.
>
> I wasn't aware of a problem there, but I'm a joe-user. ;-)
> Which release do you use? Is it already a glibc 2.3.2 one?
> Is the file /usr/share/terminfo/l/linux existing?

Yes, the terminfo files exists, TERM is set to "linux" by default.

However, I'm running a release before the new glibc.  I'll compile up a
new one and try it.  I'll let you know if there is still a problem.

 - BS

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Bruce S. <bw...@ar...>]

> >>Add a comment to insert ones own rules _above_ the logging rules
> >>and leave some more free lines in the script there so users really
> >>see it.
> > 
> > I figured if someone was knowledgeable enough to add their own rules,
> > they would know where to add them.  Depending on what they want to do,
> > they may need to add rules in other places too.  
> > 
> > Is that really necessary?
> 
> If we are preparing a script for beginners....

Exactly.  Beginners should not be writing netfilter rules (IMO).
Nobody without a good knowledge of the subject should be writing rules.
They do so at their own risk.  Maybe we need a disclaimer in the script?

> >>># Log invalid packets from DROP policy:
> >>>if [ -n "$LOGGING" ] ; then
> >>>    ${IPTABLES} -A INPUT -d 255.255.255.255 -j DROP # do not log broadcasts
> >>>    ${IPTABLES} -A INPUT -d 224.0.0.0/8 -j DROP # do not log Microsoft multicasts
> >>
> >>Why don't you just do the above always? Do just logging when we want
> >>logging.
> > 
> > Efficiency.  The only good these rules do is keep a bunch of extra crap
> > out of the logs, so they do absolutely no good unless we're logging. 
> > The packets are dropped anyway, along with everything else, the very
> > next thing because we are at the end of the chain (policy = drop).  
> > 
> > Why add the overhead of more rules when they don't do any good?
> 
> If someone manages to install rules after the logging rules those
> rules might interfere.
> 
> Have you got something like the expresssion
>   DAU = dümmster anzunehmender User
>       ~ the most stupid user to expect

Yes, I've been working as a sysadmin for a long time, and have seen 
some pretty dumb things.

My main concern is providing a good secure script to start with.  
If someone breaks the script, they own all the pieces.  There is 
nothing we can do about that.

> That's what I always have in mind if you do wounder about my remarks -
> which sound so obvious to you that you think it's not important.

Understood.

 - BS

[Devil-linux-develop] config on USB

[Heiko Z. <he...@zu...>]

Hey

I just checked in the first part of "configuration on USB device".
You can now store your etc.tar.bz2 + patches on the root of a FAT 
formatted USB device.

NOTE: save-config doesn't support it yet, you have to do it by hand.

cya
   Heiko

Re: [Devil-linux-develop] patch-o-matic

[Heiko Z. <he...@zu...>]

Heiko Zuerker wrote:
> I downloaded the current version and will try it later.
> 

The new patch-o-matic compiled fine, I'm currently copying it to the FTP 
Server.

Heiko

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote:
>>Add a comment to insert ones own rules _above_ the logging rules
>>and leave some more free lines in the script there so users really
>>see it.
>=20
> I figured if someone was knowledgeable enough to add their own rules,
> they would know where to add them.  Depending on what they want to do,
> they may need to add rules in other places too. =20
>=20
> Is that really necessary?

If we are preparing a script for beginners....


>>># Log invalid packets from DROP policy:
>>>if [ -n "$LOGGING" ] ; then
>>>    ${IPTABLES} -A INPUT -d 255.255.255.255 -j DROP # do not log broad=
casts
>>>    ${IPTABLES} -A INPUT -d 224.0.0.0/8 -j DROP # do not log Microsoft=
 multicasts
>>
>>Why don't you just do the above always? Do just logging when we want
>>logging.
>=20
>=20
> Efficiency.  The only good these rules do is keep a bunch of extra crap
> out of the logs, so they do absolutely no good unless we're logging.=20
> The packets are dropped anyway, along with everything else, the very
> next thing because we are at the end of the chain (policy =3D drop). =20
>=20
> Why add the overhead of more rules when they don't do any good?


If someone manages to install rules after the logging rules those
rules might interfere.

Have you got something like the expresssion
  DAU =3D d=FCmmster anzunehmender User
      ~ the most stupid user to expect

That's what I always have in mind if you do wounder about my remarks -
which sound so obvious to you that you think it's not important.

--=20
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Bruce S. <bw...@ar...>]

> > I just uploaded my latest firewall script at:
> > 
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/devil-linux/build/config/etc/init.d/firewall.rules.2nic?rev=HEAD
> 
> Add a comment to insert ones own rules _above_ the logging rules
> and leave some more free lines in the script there so users really
> see it.

I figured if someone was knowledgeable enough to add their own rules,
they would know where to add them.  Depending on what they want to do,
they may need to add rules in other places too.  

Is that really necessary?

> > # Log invalid packets from DROP policy:
> > if [ -n "$LOGGING" ] ; then
> >     ${IPTABLES} -A INPUT -d 255.255.255.255 -j DROP # do not log broadcasts
> >     ${IPTABLES} -A INPUT -d 224.0.0.0/8 -j DROP # do not log Microsoft multicasts
> 
> Why don't you just do the above always? Do just logging when we want
> logging.

Efficiency.  The only good these rules do is keep a bunch of extra crap
out of the logs, so they do absolutely no good unless we're logging. 
The packets are dropped anyway, along with everything else, the very
next thing because we are at the end of the chain (policy = drop).  

Why add the overhead of more rules when they don't do any good?

> >     ${IPTABLES} -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "INPUT policy: "
> >     ${IPTABLES} -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "OUTPUT policy: "
> >     ${IPTABLES} -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "FORWARD policy: "
> > fi
> 
> Logging are long enough, maybe just shorten the logging prefix to
> "FW-IN: ", "FW-OUT: " and "FW-FWD: ". Just my own preference YMMV.

Yeah, I could shorten that up some how.

 - BS

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote:
> I just uploaded my latest firewall script at:
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/devil-linux/build/config/etc/init.d/firewall.rules.2nic?rev=HEAD
> 

Add a comment to insert ones own rules _above_ the logging rules
and leave some more free lines in the script there so users really
see it.


> # Log invalid packets from DROP policy:
> if [ -n "$LOGGING" ] ; then
>     ${IPTABLES} -A INPUT -d 255.255.255.255 -j DROP # do not log broadcasts
>     ${IPTABLES} -A INPUT -d 224.0.0.0/8 -j DROP # do not log Microsoft multicasts

Why don't you just do the above always? Do just logging when we want
logging.

>     ${IPTABLES} -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "INPUT policy: "
>     ${IPTABLES} -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "OUTPUT policy: "
>     ${IPTABLES} -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "FORWARD policy: "
> fi

Logging are long enough, maybe just shorten the logging prefix to
"FW-IN: ", "FW-OUT: " and "FW-FWD: ". Just my own preference YMMV.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Bruce S. <bw...@ar...>]

> > I see the tutorial optionally loads "ipt_owner".  What is that?
> > Should I load it too?
> 
> I guess you can match if a local user generated the given packet, see
>    http://www.netfilter.org/documentation/pomlist/pom-combined.html#owner-socketlookup

I guess I'll leave that one commented out in the firewall script.  :-)

I just uploaded my latest firewall script at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/devil-linux/build/config/etc/init.d/firewall.rules.2nic?rev=HEAD

I think this has all changes suggested, including the limits on logging.
Does anything else need to be changed?

I haven't had a chance to go through all the other samples/suggestions
sent to me privately.  I'll get to them sometime, but for now I'm
getting a little sick of looking at iptables.  :-) 

So, I've been working on the setup script instead.  I hope to have a
copy of that uploaded for testing soon.  I'll probably stick a
stand-alone copy (will not modify real config files) of it on the FTP
server so people can play with it outside of the DL development system.

 - BS

Re: [Devil-linux-develop] patch-o-matic

[Heiko Z. <he...@zu...>]

Hey,

I downloaded the current version and will try it later.

Heiko

Friedrich Lobenstock wrote:
> Hi Heiko!
> 
> I guess we should be using the latest patch-o-matic from CVS from what I 
> read
> here:
> 
> -------- Original Message --------
> Subject: Re: [netfilter-core] iptables/conntrack in enterprise environment.
> Date: Thu, 29 May 2003 10:39:53 +0200
> From: Harald Welte <la...@ne...>
> To: "Preston A. Elder" <pr...@sr...>
> CC: net...@li..., 
> net...@li...,   cor...@ne...
> References: <200...@sr...>
> 
> On Thu, May 29, 2003 at 01:13:47AM -0400, Preston A. Elder wrote:
> 
>  > Hi,
>  >
>  > I am in an enterprise environment and I'm having some problems with 
> conntrack
>  > specifically.
> 
>  > They're running 2.4.20 kernels (mostly vanilla) with iptables 1.2.7a.
> 
> Do not use 2.4.20 if you want to use connection tracking.  2.4.20
> connection tracking is totally broken due to a change introduced in the
> core kernel.
> 
> Please do always use patch-o-matic from CVS.  The patch you want to
> apply for fixing this bug is 10_confirm_fix.patch
> 
> Also, considering
> 
>  > echo 524280 >/proc/sys/net/ipv4/ip_conntrack_max
> 
> without using a larger hash size (modprobe ip_conntrack hashsize=foo,
> wherer foo should be a prime number and in the range of 524280/2)
> 
>  > to be re-directed to a local port, which is achieved with the command:
>  > /sbin/iptables -t nat -A PREROUTING -j DNAT -i eth0 -p tcp -d <ip-range>
>  > - --destination-port 1024:65535 --to-destination <local_ip>:<local_port>
>  >
>  > Every inbound connection incurs an entry in the connection tracking
>  > table.  It seems, however, that we may be overloading the conntrack
>  > system.
> 
> I've seen systems with way more conntrack entries and higher bandwith.
> Using NAT however, might have a big performance impact.
> 
>  > The conntrack table itself very quickly grows - but it does not clean 
> itself
>  > up when the connection itself dissapears, instead it waits for some
>  > pre-determined timeout value,
> 
> With a non-broken kernel it is 2 minutes, that is TIME_WAIT of a TCP
> socket.
> 
>  > PreZ
>  > Systems Administrator
>  > Shadow Realm
> 

Re: [Devil-linux-develop] TERM bug?

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:
> Since upgrading to the 0.6beta releases, "vi" gives me garbage unless I
> "export TERM=vt100" before hand (ssh'ed in as root).  I never had to do
> that with 0.5.
> 
> Is this a bug or a "feature"?  :-)
> 

I wasn't aware of a problem there, but I'm a joe-user. ;-)
Which release do you use? Is it already a glibc 2.3.2 one?
Is the file /usr/share/terminfo/l/linux existing?

Heiko

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote:
> I see the tutorial optionally loads "ipt_owner".  What is that?
> Should I load it too?

I guess you can match if a local user generated the given packet, see
   http://www.netfilter.org/documentation/pomlist/pom-combined.html#owner-socketlookup

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote:
> 
> Correct if I'm wrong, but since it's jumping to LOG, it's not preventing
> anything (LOG returns after logging the packet).  So it's only logging
> the over-limits, and not doing anything to stop DOS attacks.

The limit stops someone from doing a DOS attack on your syslog server.
If you do
   $IPTABLES -A FORWARD -j LOG --log-prefix "FORWARD: "

Then every user can bring your machine to its knees by sending a lot of
packets. You get the idea?


> I guess it's relying on the catch-all policy of DENY to stop anything
> that's not accepted (including DOS attacks).

DOS needs a service that can be abused so it eventually dieds and so
does the whole machine.


> So it really does no good in my script, other than maybe saving a few
> entries in the log.  Is that really needed?  Syslog normally combines
> duplicate entries anyway.

See above. Syslog will log _each_ packet, as each packet usually has
a uniq or at least different id tag. I actually would need two different
packets to doe the DOS - both having a different id tag (or sequence
number in TCP) and sending them alternating. Now way syslog can combine
those log entries.


> I have seen specific "--limit" iptable statements specific for different
> kind of DOS attacks, but I don't remember where I saw them off hand. 
> And now I'm not sure they are needed ...   Anyone?

Of course you can use limit not just with logging. But what you'll
have for now will do.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Bruce S. <br...@ar...>]

OK, my latest changes have been uploaded.  More comments?

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/devil-linux/build/config/etc/init.d/firewall.rules.2nic?rev=HEAD


--------------------------------------------
Bruce Smith                br...@ar...
System Administrator / Network Administrator
Armstrong International, Inc.
Three Rivers, Michigan  49093  USA
http://www.armstrong-intl.com/
--------------------------------------------

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Bruce S. <bw...@ar...>]

> >>For all the logging you might want to add limit options to not get into
> >>troubles when flouded with invalid or block packages (denial of service!)
> > 
> > Yes, I've seen those, ...  somewhere.  
> > Any idea where I "borrow" some samples?
> 
> See the iptables tutorial I referenced at the end of my last mail.

The tutorial has lines like this at the END of each main chain
(INPUT, OUTPUT and FORWARD):

$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
        --log-level DEBUG --log-prefix "IPT FORWARD packet died: "

Those are the ONLY places it has any "--limit*" rules.

Correct if I'm wrong, but since it's jumping to LOG, it's not preventing
anything (LOG returns after logging the packet).  So it's only logging
the over-limits, and not doing anything to stop DOS attacks.

I guess it's relying on the catch-all policy of DENY to stop anything
that's not accepted (including DOS attacks).

So it really does no good in my script, other than maybe saving a few
entries in the log.  Is that really needed?  Syslog normally combines
duplicate entries anyway.

I have seen specific "--limit" iptable statements specific for different
kind of DOS attacks, but I don't remember where I saw them off hand. 
And now I'm not sure they are needed ...   Anyone?

 - BS

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Bruce S. <bw...@ar...>]

> >>># Prevent NetBIOS and Samba from leaking.
> >>>${IPTABLES} -t nat -A PREROUTING -p TCP --dport 137:139 -j DROP
> >>>${IPTABLES} -t nat -A PREROUTING -p UDP --dport 137:139 -j DROP
> >>>${IPTABLES} -t nat -A PREROUTING -p TCP --dport 445 -j DROP
> >>>${IPTABLES} -t nat -A PREROUTING -p UDP --dport 445 -j DROP
> >>
> >>Might want to consider Port 135 too.
> > 
> > The script I "borrowed" has 135:139 on the TCP chain and 137:139 on UDP.
> > 
> > How about using 135:139 on both lines?
> 
> Would not do this as Port 136 is not related to Windows and there
> might be a valid service using it.

Even the tutorial script blocks 135:139
 http://www.bec.at/support/iptables-tutorial/examplecode.html

136 must not be used very often, but I'll add the extra overhead not to
block it.

> So where are the ftp modules?

To be loaded in the next version of the script?  :-)

I see the tutorial optionally loads "ipt_owner".  What is that?
Should I load it too?

The kernel source code only says:

/* Kernel module to match various things tied to sockets associated with
   locally generated outgoing packets. */

Whatever that means ...

 - BS

[Devil-linux-develop] TERM bug?

[Bruce S. <br...@ar...>]

Since upgrading to the 0.6beta releases, "vi" gives me garbage unless I
"export TERM=vt100" before hand (ssh'ed in as root).  I never had to do
that with 0.5.

Is this a bug or a "feature"?  :-)

--------------------------------------------
Bruce Smith                br...@ar...
System Administrator / Network Administrator
Armstrong International, Inc.
Three Rivers, Michigan  49093  USA
http://www.armstrong-intl.com/
--------------------------------------------

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote:
>>I'm thinking of way so we could mark the interenal and external interface
>>in the network scripts ifcfg-ethX. But haven't made up for a desicion yet.
>>This way if would allow the firewall script to walk all installed
>>interfaces and reference them and their status being eg. external, dmz,
>>internal, ...
> 
> OK, let me know if/when that changes.

Ok, but currently I don't know if what is practicable at all and how
to do it then. Currently just an idea. But I will let you know.


>>># Prevent NetBIOS and Samba from leaking.
>>>${IPTABLES} -t nat -A PREROUTING -p TCP --dport 137:139 -j DROP
>>>${IPTABLES} -t nat -A PREROUTING -p UDP --dport 137:139 -j DROP
>>>${IPTABLES} -t nat -A PREROUTING -p TCP --dport 445 -j DROP
>>>${IPTABLES} -t nat -A PREROUTING -p UDP --dport 445 -j DROP
>>
>>Might want to consider Port 135 too.
> 
> The script I "borrowed" has 135:139 on the TCP chain and 137:139 on UDP.
> 
> How about using 135:139 on both lines?

Would not do this as Port 136 is not related to Windows and there
might be a valid service using it.


>>># Log invalid packets:
>>>#LOG# ${IPTABLES} -A INPUT -d 255.255.255.255 -j DROP # do not log broadcasts
>>>#LOG# ${IPTABLES} -A INPUT -j LOG
>>>#LOG# ${IPTABLES} -A FORWARD -j LOG
>>
>>For all the logging you might want to add limit options to not get into
>>troubles when flouded with invalid or block packages (denial of service!)
> 
> 
> Yes, I've seen those, ...  somewhere.  
> Any idea where I "borrow" some samples?

See the iptables tutorial I referenced at the end of my last mail.


>>Also "--log-prefix" would be nice.
> 
> 
> To identify where it was logged in the script?

Exactelly. See iptables tutorial.


>>You might want to take a look at the example script of the IP-Tables
>>tutorial http://iptables-tutorial.frozentux.net/

As the site seems to have connectivety problems see
   http://www.bec.at/support/iptables-tutorial/
   http://www.bec.at/support/iptables-tutorial/examplecode.html



>>You are missing the loading of modules, eg.
>>$MODPROBE ip_conntrack > /dev/null 2>&1
>>$MODPROBE ip_conntrack_ftp > /dev/null 2>&1
>>$MODPROBE ip_nat_ftp > /dev/null 2>&1
> 
> They don't seem to be necessary in DL.
> 
> My running firewall.rules ONLY probes "ipt_LOG", and it works fine.
> When I do a lsmod on my DL firewall (pre 0.6), I get all of these:
> 
> ipt_TOS                 1048   3  (autoclean)
> iptable_mangle          2168   1  (autoclean)
> ipt_REJECT              3192   1  (autoclean)
> ipt_state                568   7  (autoclean)
> ipt_MASQUERADE          1368   1  (autoclean)
> iptable_nat            17464   1  (autoclean) [ipt_MASQUERADE]
> ip_conntrack           19360   2  (autoclean) [ipt_state ipt_MASQUERADE
> iptable_nat]
> iptable_filter          1740   1  (autoclean)
> ipt_LOG                 3384   4
> ip_tables              12152  10  [ipt_TOS iptable_mangle ipt_REJECT 
>             ipt_state ipt_MASQUERADE iptable_nat iptable_filter ipt_LOG]

So where are the ftp modules?

> 
> So it appears they get loaded automatically, or some other script is
> loading them.  (I think it's automatic because of the "autoclean")

The ftp modules will not get loaded automatically, so active ftp will
not work, just passive ftp.

There are also some other modules, eg. for IRC, ....
see /lib/modules/KERNEL-VERSION/kernel/net/ipv4/netfilter

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Bruce S. <bw...@ar...>]

> > INT_DEV=eth1	# internal/protected network.
> > OUT_DEV=eth0	# Internet
> 
> I'm thinking of way so we could mark the interenal and external interface
> in the network scripts ifcfg-ethX. But haven't made up for a desicion yet.
> This way if would allow the firewall script to walk all installed
> interfaces and reference them and their status being eg. external, dmz,
> internal, ...

OK, let me know if/when that changes.

> > # Uncomment ALL lines starting with #LOG# to log rejected packets
> > #LOG# modprobe ipt_LOG
> 
> Would that be much easier for the user:
> # Uncomment the following line to enable logging
> # LOGGING="yes"
> 
> and you'd put such lines everywhere in the script:
> [ -n "$LOGGING" ] && ...command that does the logging

Good idea, it also allows it to be sent as a parameter.  Will do.

> > ${IPTABLES} -P OUTPUT DROP	#  Drop all packets that are
> 
> Hmmm...wouldn't do that with OUTPUT because then I guess you'd have to enable
> the some specific ICMP messages. Comments on that?

I have the basic setup in my home firewall, with that output policy of 
drop, and pings work find through the firewall (forward), and from the 
firewall itself.  I don't know about other ICMP message types.

I'd leave it as drop to be safe, unless we can find something that
doesn't work.

> > # uncomment/modify next 3 lines to forward a service to an internal IP.
> > # SERVER=192.168.1.1	# Internal IP of server.
> > # PORT=22		# 22 = SSH.  Change to 80 for web server, etc.
> > # ${IPTABLES} -A PREROUTING -i ${OUT_DEV} -t nat -p TCP --dport $PORT -j DNAT --to ${SERVER}:$PORT
> 
> I had to add an additional
> $IPTABLES -A FORWARD -m state --state NEW -p tcp -i ${OUT_DEV} -o ${IN_DEV} -d ${SERVER} --dport ${PORT} -j ACCEPT

Yes, I dropped that line by mistake.  Good catch.

> > # Prevent NetBIOS and Samba from leaking.
> > ${IPTABLES} -t nat -A PREROUTING -p TCP --dport 137:139 -j DROP
> > ${IPTABLES} -t nat -A PREROUTING -p UDP --dport 137:139 -j DROP
> > ${IPTABLES} -t nat -A PREROUTING -p TCP --dport 445 -j DROP
> > ${IPTABLES} -t nat -A PREROUTING -p UDP --dport 445 -j DROP
> 
> Might want to consider Port 135 too.

The script I "borrowed" has 135:139 on the TCP chain and 137:139 on UDP.

How about using 135:139 on both lines?

> > # Log invalid packets:
> > #LOG# ${IPTABLES} -A INPUT -d 255.255.255.255 -j DROP # do not log broadcasts
> > #LOG# ${IPTABLES} -A INPUT -j LOG
> > #LOG# ${IPTABLES} -A FORWARD -j LOG
> 
> For all the logging you might want to add limit options to not get into
> troubles when flouded with invalid or block packages (denial of service!)

Yes, I've seen those, ...  somewhere.  
Any idea where I "borrow" some samples?

> Also "--log-prefix" would be nice.

To identify where it was logged in the script?

> You might want to take a look at the example script of the IP-Tables
> tutorial http://iptables-tutorial.frozentux.net/
> 
> You are missing the loading of modules, eg.
> $MODPROBE ip_conntrack > /dev/null 2>&1
> $MODPROBE ip_conntrack_ftp > /dev/null 2>&1
> $MODPROBE ip_nat_ftp > /dev/null 2>&1

They don't seem to be necessary in DL.

My running firewall.rules ONLY probes "ipt_LOG", and it works fine.
When I do a lsmod on my DL firewall (pre 0.6), I get all of these:

ipt_TOS                 1048   3  (autoclean)
iptable_mangle          2168   1  (autoclean)
ipt_REJECT              3192   1  (autoclean)
ipt_state                568   7  (autoclean)
ipt_MASQUERADE          1368   1  (autoclean)
iptable_nat            17464   1  (autoclean) [ipt_MASQUERADE]
ip_conntrack           19360   2  (autoclean) [ipt_state ipt_MASQUERADE
iptable_nat]
iptable_filter          1740   1  (autoclean)
ipt_LOG                 3384   4
ip_tables              12152  10  [ipt_TOS iptable_mangle ipt_REJECT 
            ipt_state ipt_MASQUERADE iptable_nat iptable_filter ipt_LOG]

So it appears they get loaded automatically, or some other script is
loading them.  (I think it's automatic because of the "autoclean")

I'll make some changes, including the re-ordering you suggested, and
upload my changes.

 - BS

[Devil-linux-develop] patch-o-matic

[Friedrich L. <fl...@fl...>]

Hi Heiko!

I guess we should be using the latest patch-o-matic from CVS from what I read
here:

-------- Original Message --------
Subject: Re: [netfilter-core] iptables/conntrack in enterprise environment.
Date: Thu, 29 May 2003 10:39:53 +0200
From: Harald Welte <la...@ne...>
To: "Preston A. Elder" <pr...@sr...>
CC: net...@li..., net...@li...,   cor...@ne...
References: <200...@sr...>

On Thu, May 29, 2003 at 01:13:47AM -0400, Preston A. Elder wrote:

 > Hi,
 >
 > I am in an enterprise environment and I'm having some problems with conntrack
 > specifically.

 > They're running 2.4.20 kernels (mostly vanilla) with iptables 1.2.7a.

Do not use 2.4.20 if you want to use connection tracking.  2.4.20
connection tracking is totally broken due to a change introduced in the
core kernel.

Please do always use patch-o-matic from CVS.  The patch you want to
apply for fixing this bug is 10_confirm_fix.patch

Also, considering

 > echo 524280 >/proc/sys/net/ipv4/ip_conntrack_max

without using a larger hash size (modprobe ip_conntrack hashsize=foo,
wherer foo should be a prime number and in the range of 524280/2)

 > to be re-directed to a local port, which is achieved with the command:
 > /sbin/iptables -t nat -A PREROUTING -j DNAT -i eth0 -p tcp -d <ip-range>
 > - --destination-port 1024:65535 --to-destination <local_ip>:<local_port>
 >
 > Every inbound connection incurs an entry in the connection tracking
 > table.  It seems, however, that we may be overloading the conntrack
 > system.

I've seen systems with way more conntrack entries and higher bandwith.
Using NAT however, might have a big performance impact.

 > The conntrack table itself very quickly grows - but it does not clean itself
 > up when the connection itself dissapears, instead it waits for some
 > pre-determined timeout value,

With a non-broken kernel it is 2 minutes, that is TIME_WAIT of a TCP
socket.

 > PreZ
 > Systems Administrator
 > Shadow Realm

-- 
- Harald Welte <la...@ne...>             http://www.netfilter.org/
============================================================================
   "Fragmentation is like classful addressing -- an interesting early
    architectural error that shows how much experimentation was going
    on while IP was being designed."                    -- Paul Vixie


-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Update question.

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:
> Bruce Smith wrote:
> 
>>
>> Is there a better/easier way that I'm overlooking?
> 
> 
> None that I know of. Sorry ;-(
> 

That's the way I do it, too.

Heiko

Re: [Devil-linux-develop] Firewall script for 2 NIC's & NAT.

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:
>>>I added a simple iptables script that supports 2 NIC's w/masquerading.
>>>Please take a look, and comment:
>>>
>>>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/devil-linux/build/config/
>>>etc/init.d/firewall.rules.2nic?rev=HEAD
>>
>>I wouldn't fix the interface to interna=eth1 and external=eth0 .
>>Let the user choose it.
> 
> 
> I'm trying to come up with script(s) that I can copy to firewall.rules
> in my new setup script.  I need to default them to something.  I'm happy
> to switch them around if you like that better.
> 
> Also, in my experience, the numbering of ethernet interfaces is very
> arbitrary.  Even if the cards use two different drivers, I don't know
> how to tell which is which without examining the MAC addresses or trying
> them.  The output of "ifconfig" doesn't say which driver it's using.  
> 
> Asking a newbie if they want eth0 or eth1 connected to the internet
> isn't going to mean anything to them, unless I can tell them which card
> is which.
> 
> So, my instructions would be to plug one NIC into your cable/DSL modem,
> and the other into your internal LAN.  If it doesn't work, switch the
> cables, reboot DL & modem, and try again.
> 
> I'd appreciate advice, if there is a better way.

You're right, do it if nobody comes up with a better idea.

Heiko

[Devil-linux-develop] [ devil-linux-Bugs-745290 ] replace ucd-snmp with net-snmp

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

Bugs item #745290, was opened at 2003-05-28 21:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410643&aid=745290&group_id=34096

Category: Package
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace ucd-snmp with net-snmp

Initial Comment:
ucd-snmp doesn't seem to like openssl 0.9.7 and at some
point we need to update anyway.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410643&aid=745290&group_id=34096