Menu
▾
▴
devil-linux-develop
|
From: Bruce S. <br...@ar...> - 2003-05-28 15:03:06
|
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 Much of the code was originally based on a script from my 2nd favorite dedicated Linux firewall distribution. :-) -------------------------------------------- Bruce Smith br...@ar... System Administrator / Network Administrator Armstrong International, Inc. Three Rivers, Michigan 49093 USA http://www.armstrong-intl.com/ -------------------------------------------- |
|
From: Friedrich L. <fl...@fl...> - 2003-05-28 23:55:52
|
Bruce Smith wrote: > I added a simple iptables script that supports 2 NIC's w/masquerading. > Please take a look, and comment: OK, I added the script code to be able to comment on it. > #!/bin/bash > # > # $Source: /cvsroot/devil-linux/build/config/etc/init.d/firewall.rules.2nic,v $ > # $Revision: 1.1 $ > # $Date: 2003/05/28 14:53:18 $ > # > # http://www.devil-linux.org > # > # > # Basic Firewall rules for 2 NIC's and NAT > # > > # Path to IPTABLES executable > IPTABLES=/usr/sbin/iptables > > 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, ... > > echo "0" > /proc/sys/net/ipv4/ip_forward # stop forwarding while setting up. > > # 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 > > # Flush & Policy > ${IPTABLES} -F # flush all chains > # flush all tables: > for t in `cat /proc/net/ip_tables_names`; do ${IPTABLES} -F -t $t ; done > ${IPTABLES} -X # delete all user chains > ${IPTABLES} -Z # zero all counters > ${IPTABLES} -P INPUT DROP # Policy = DROP > ${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? > ${IPTABLES} -P FORWARD DROP # not specifically accepted. > > # Masquerading (aka NAT, PAT, ...) > ${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE > > # 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 But I would first add the state rules below and than add any new rules. > > # Allow connections to the internet. > #LOG# ${IPTABLES} -A FORWARD -m state --state NEW,INVALID -i ${OUT_DEV} -j LOG > ${IPTABLES} -A FORWARD -m state --state NEW,INVALID -i ${OUT_DEV} -j DROP > ${IPTABLES} -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > ${IPTABLES} -A FORWARD -m state --state NEW -i ${INT_DEV} -j ACCEPT > > # 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. > > # Allow our firewall to connect. > ${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > ${IPTABLES} -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT As above. I'd group those state related rules right after clearing the chains. > > # Allow Ping and friends. > ${IPTABLES} -A OUTPUT -p icmp -j ACCEPT > ${IPTABLES} -A INPUT -p icmp -j ACCEPT > > # We accept anything from the inside. > ${IPTABLES} -A INPUT -i ${INT_DEV} -j ACCEPT > ${IPTABLES} -A INPUT -i lo -j ACCEPT > ${IPTABLES} -A OUTPUT -o ${INT_DEV} -j ACCEPT > ${IPTABLES} -A OUTPUT -o lo -j ACCEPT As the lo is essential I'd move it right after the state related (EST/RELATED) rules. And tell the user to never ever remove them. > > # Fast reject for Ident to eliminate email delays. > ${IPTABLES} -A INPUT -p TCP --dport 113 -i ${OUT_DEV} -j REJECT --reject-with tcp-reset > > # make interactive sesions a bit more interactive under load > ${IPTABLES} -A PREROUTING -t mangle -p TCP --sport ssh -j TOS --set-tos Minimize-Delay > ${IPTABLES} -A PREROUTING -t mangle -p TCP --sport ftp -j TOS --set-tos Minimize-Delay > ${IPTABLES} -A PREROUTING -t mangle -p TCP --sport ftp-data -j TOS --set-tos Maximize-Throughput > > # 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!) Also "--log-prefix" would be nice. > > # enable dynamic IP address following > echo 7 > /proc/sys/net/ipv4/ip_dynaddr > > # stop some smurf attacks. > echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > > # Don't accept source routed packets. > echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route > > # Syncookies > echo "1" > /proc/sys/net/ipv4/tcp_syncookies > > # Stop IP spoofing, > for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do > echo "1" > $interface > done > > # Stop ICMP redirect > for interface in /proc/sys/net/ipv4/conf/*/accept_redirects; do > echo "0" > ${interface} > done > > # Enable bad error message protection. > /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses > > # Enabling IP forwarding. > echo "1" > /proc/sys/net/ipv4/ip_forward 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 -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-05-29 14:10:09
|
> > 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
|
|
From: Friedrich L. <fl...@fl...> - 2003-05-29 14:29:50
|
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...
____________________________________________________________________
|
|
From: Bruce S. <bw...@ar...> - 2003-05-29 15:46:28
|
> >>># 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
|
|
From: Friedrich L. <fl...@fl...> - 2003-05-29 20:11:10
|
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... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-05-30 17:46:18
|
> > 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 |
|
From: Friedrich L. <fl...@fl...> - 2003-05-30 21:25:42
|
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... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-05-30 21:37:16
|
> > 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 |
|
From: Friedrich L. <fl...@fl...> - 2003-05-30 21:47:40
|
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...
____________________________________________________________________
|
|
From: Bruce S. <bw...@ar...> - 2003-05-31 03:23:02
|
> >>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
|
|
From: Heiko Z. <he...@zu...> - 2003-05-31 12:35:26
|
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 |
|
From: Bruce S. <bw...@ar...> - 2003-05-29 17:26:38
|
> >>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
|
|
From: Friedrich L. <fl...@fl...> - 2003-05-29 20:03:02
|
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... ____________________________________________________________________ |
|
From: Bruce S. <br...@ar...> - 2003-05-29 19:51:00
|
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/ -------------------------------------------- |
