Search This Blog

Saturday, January 31, 2009

Re: portmap by default (Re: my debian does not read my own iptables script)

Yes, I apologize.. I was referring to specific applications.. for instance Shorewall etc. as well as what services to turn off initially on an Ubuntu install.. But thanks for the link.. The rest of the hardening is obviously useless if the OS is not patched!

On Sat, Jan 31, 2009 at 7:48 PM, Paolo <oopla@users.sf.net> wrote:
On Sat, Jan 31, 2009 at 07:08:16PM -0500, TzAR wrote:

>    that statement. Does anyone have a link or site recommendation
>    regarding Securing a Debian or Debian-based distro (namely Ubuntu)!

did you already check eg. http://www.debian.org/security/ ?


--
paolo


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Re: portmap by default (Re: my debian does not read my own iptables script)

On Sat, Jan 31, 2009 at 07:08:16PM -0500, TzAR wrote:

> that statement. Does anyone have a link or site recommendation
> regarding Securing a Debian or Debian-based distro (namely Ubuntu)!

did you already check eg. http://www.debian.org/security/ ?


--
paolo


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: portmap by default (Re: my debian does not read my own iptables script)



>These remind me of a question I forgot to ask somewhere else: why is portmap installed (and enabled!) by default? I just installled a >fresh lenny, with the web server task, and portmap was installed and enabled by default. I believe nfs-common was also pulled together, >and none was called for during the install procedure. IMHO it's a very dangerous default.
regards
FF

Felipe and Group,
I am inclined to agree with you from what I have been able to locate online pertaining to portmap and nfs-common. Quick question regarding that statement. Does anyone have a link or site recommendation regarding Securing a Debian or Debian-based distro (namely Ubuntu)!


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


[SECURITY] [DSA 1716-1] New vnc4 packages fix remote code execution

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ------------------------------------------------------------------------
Debian Security Advisory DSA-1716-1 security@debian.org
http://www.debian.org/security/ Steffen Joeris
January 31, 2009 http://www.debian.org/security/faq
- ------------------------------------------------------------------------

Package : vnc4
Vulnerability : integer overflow
Problem type : remote
Debian-specific: no
CVE ID : CVE-2008-4770
Debian Bug : 513531

It was discovered that xvnc4viewer, a virtual network computing client
software for X, is prone to an integer overflow via a malicious
encoding value that could lead to arbitrary code execution.

For the stable distribution (etch) this problem has been fixed in
version 4.1.1+X4.3.0-21+etch1.

For the unstable (sid) distribution this problem has been fixed in
version 4.1.1+X4.3.0-31.

For the testing (lenny) distribution this problem will be fixed soon.

We recommend that you upgrade your vnc4 packages.

Upgrade instructions
- --------------------

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 4.0 alias etch
- -------------------------------

Source archives:

http://security.debian.org/pool/updates/main/v/vnc4/vnc4_4.1.1+X4.3.0-21+etch1.diff.gz
Size/MD5 checksum: 50904 55c92400d7949023c3488dcec680d613
http://security.debian.org/pool/updates/main/v/vnc4/vnc4_4.1.1+X4.3.0.orig.tar.gz
Size/MD5 checksum: 31536534 b28c43385fe574d612ddbd0b645082f7
http://security.debian.org/pool/updates/main/v/vnc4/vnc4_4.1.1+X4.3.0-21+etch1.dsc
Size/MD5 checksum: 696 0d0f0e7f58c6440481b8bfa83af8cd63

alpha architecture (DEC Alpha)

http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_alpha.deb
Size/MD5 checksum: 19868 56d083c639e24961fcbbf98cec86dd11
http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_alpha.deb
Size/MD5 checksum: 172424 ec5afb4bf93d6988859e0dca63b922a4
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_alpha.deb
Size/MD5 checksum: 2682410 e2ad2547dda085010c318900786ee935

amd64 architecture (AMD x86_64 (AMD64))

http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_amd64.deb
Size/MD5 checksum: 2169248 27b31d7391acb4b7d4e98a97a341bcf3
http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_amd64.deb
Size/MD5 checksum: 144462 097687a2626960fcda86fa8df3831151
http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_amd64.deb
Size/MD5 checksum: 18778 68843484c257b04314e141a1bc370443

hppa architecture (HP PA RISC)

http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_hppa.deb
Size/MD5 checksum: 181264 ca3758fa85fb049fdd8f965d3e67ed40
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_hppa.deb
Size/MD5 checksum: 2294922 00482f651a2008cd66f4588ac403cba2
http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_hppa.deb
Size/MD5 checksum: 19490 07ac277452d42f3f5ac8144700109c06

i386 architecture (Intel ia32)

http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_i386.deb
Size/MD5 checksum: 2015342 a1e67da97e85e0ca290e3644b551c686
http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_i386.deb
Size/MD5 checksum: 18640 27cf156a68540519f9efd4b81fd51dff
http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_i386.deb
Size/MD5 checksum: 147628 9cedf57dd52455c76332f585f6c52dc8

ia64 architecture (Intel ia64)

http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_ia64.deb
Size/MD5 checksum: 20850 1bc4cf4b52eae3f4df103ef36b13f156
http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_ia64.deb
Size/MD5 checksum: 210896 9f611bbc3397c02056f51b7f3dc7a190
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_ia64.deb
Size/MD5 checksum: 3436446 a80497194bfa083efc7abb605d63e8e5

mips architecture (MIPS (Big Endian))

http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_mips.deb
Size/MD5 checksum: 167956 a675e51fa9e97a06161aa1a39a0a40e0
http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_mips.deb
Size/MD5 checksum: 19334 ba9c0e77f3127023fb804771bbc02be1
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_mips.deb
Size/MD5 checksum: 2219206 26797854e72b6e37ae36b3ab25fe9f81

mipsel architecture (MIPS (Little Endian))

http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_mipsel.deb
Size/MD5 checksum: 166658 f65eb37aac9e5999bfe8357cc5fa6d1a
http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_mipsel.deb
Size/MD5 checksum: 19364 8756098357f1d940067ba336f5fd2412
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_mipsel.deb
Size/MD5 checksum: 2216976 511790cec54a6fbb4d82b7264faa828c

powerpc architecture (PowerPC)

http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_powerpc.deb
Size/MD5 checksum: 18964 dc9aaf61e3ed3af75ec6721a34837e91
http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_powerpc.deb
Size/MD5 checksum: 150726 72aec061f31ca36cde5de15155566267
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_powerpc.deb
Size/MD5 checksum: 2175212 dd3910238f15e0b3e5217156fb7a82b1

s390 architecture (IBM S/390)

http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_s390.deb
Size/MD5 checksum: 146930 3944bd5e31b674d5f61df09bf559da7a
http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_s390.deb
Size/MD5 checksum: 18962 9be75dac3eb47ad7fcd3cdf2f791ef29
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_s390.deb
Size/MD5 checksum: 2037162 90f5428057526f8ddd3597b68640278a

sparc architecture (Sun SPARC/UltraSPARC)

http://security.debian.org/pool/updates/main/v/vnc4/xvnc4viewer_4.1.1+X4.3.0-21+etch1_sparc.deb
Size/MD5 checksum: 140638 8c079b90ee4f3fe80b2ce7eac796b2d0
http://security.debian.org/pool/updates/main/v/vnc4/vnc4server_4.1.1+X4.3.0-21+etch1_sparc.deb
Size/MD5 checksum: 1976152 695f3eca91cd7f4a8b15546fb9f53e97
http://security.debian.org/pool/updates/main/v/vnc4/vnc4-common_4.1.1+X4.3.0-21+etch1_sparc.deb
Size/MD5 checksum: 18334 b5aa41215f8d4d90849bd7e17e6f3720


These files will probably be moved into the stable distribution on
its next update.

- ---------------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: debian-security-announce@lists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJJhMIiAAoJEL97/wQC1SS+BIAH/ipPRaeinnmPvVCyw3BO/Efq
hMxAIaJrm+DJL+KoaDimilf6ZQKg7KKoMJ9E8+WWuXtoQTxoipJqsoKeM3OeRglG
O31n3Q5QmA2J1V5H9pwjniyE54J3On1FeXqgc3zAlHZ6Ec6SjQAXQ4OUJXs2ZDci
jnBRcECSeLPlUujM3P6V8IOesFfSFiTb1+7di3CGrJFOCzjnZtgSUzmkWAY8soYq
fn4LXpTUCAkpRTwd/U8y7FPR5DKHtYrb15TE84yixoFRO6E5ynjfllw1az0a6BPO
/0yxdVLDioFIYoyZSmmVayyHWdCpD8KUyUrpNA5mM3467kaHA0fhMoxBgkdafzc=
=BUkF
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-security-announce-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

portmap by default (Re: my debian does not read my own iptables script)

Em Sáb, 2009-01-31 às 02:41 +0100, Ansgar Wiechers escreveu:

> There seems to be a misunderstanding about the nature of ports here.
> Ports don't magically turn "open", because you don't filter them on the
> firewall. A port is only in the state "open" if some daemon has a
> listening socket bound to it. For instance, port 111/tcp on your machine
> is probably open, because you're running the portmap daemon.

> Besides, why is your firewall running port-mapper, identd and print
> spooler anyway? A firewall is a security device and should be running as
> little services as possible. I also strongly recommend running a custom
> (stripped-down) kernel.

These remind me of a question I forgot to ask somewhere else: why is
portmap installed (and enabled!) by default? I just installled a fresh
lenny, with the web server task, and portmap was installed and enabled
by default. I believe nfs-common was also pulled together, and none was
called for during the install procedure. IMHO it's a very dangerous
default.

regards
FF


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

On 2009-01-31 Kinglok, FONG wrote:
> # Enable IP forwarding since it is disabled by default
> echo 1 > /proc/sys/net/ipv4/ip_forward
[...]
> # Remove any existing rules from all chains
> $IPT --flush
> $IPT -t nat --flush
> $IPT -t mangle --flush
> $IPT -X
> $IPT -t nat -X
> $IPT -t mangle -X
> $IPT --policy INPUT ACCEPT
> $IPT --policy OUTPUT ACCEPT
> $IPT --policy FORWARD ACCEPT
> $IPT -t nat --policy PREROUTING ACCEPT
> $IPT -t nat --policy OUTPUT ACCEPT
> $IPT -t nat --policy POSTROUTING ACCEPT
> $IPT -t mangle --policy PREROUTING ACCEPT
> $IPT -t mangle --policy OUTPUT ACCEPT

At this point both your firewall and your LAN are completely open to the
world. NEVER EVER DO THAT!

> if [ "$1" = "stop" ]; then
> echo "Firewall completely stopped! WARNING: THIS HOST HAS NO FIREWALL RUNNING
> exit
> fi

If you want to be able to stop your firewall entirely (for whatever
reason), do the respective commands INSIDE the if-statement.

----8<----
function cleanup_chains() {
$IPT -F
$IPT -t nat -F
$IPT -t mangle -F

$IPT -X
$IPT -t nat -X
$IPT -t mangle -X
}

function set_policies() {
if [ "$1" = "open" ]; then
$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT
else
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
fi

$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT

$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P INPUT ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT
$IPT -t mangle -P FORWARD ACCEPT
$IPT -t mangle -P POSTROUTING ACCEPT
}

if [ "$1" = "stop" ]; then
set_policies open
cleanup_chains
echo "Firewall disabled!"
exit 0
fi

set_policies
cleanup_chains
---->8----

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

On 2009-01-31 Bastian Blank wrote:
> On Sat, Jan 31, 2009 at 02:41:47AM +0100, Ansgar Wiechers wrote:
>> I also strongly recommend running a custom (stripped-down) kernel.
>
> Can you please explain why? As the distribution kernels are heavy
> modularized you won't get much less kernel code, which is one attack
> vector.

Basically for three reasons:

- I don't trust any distributor to have compiled everything except for
the absolute core functionality as modules.
- I don't trust any distributor to have disabled automatic module
loading by default.
- I don't trust any distributor to have included all the modules I need
for my firewall.

Yes, I could read their .config to understand what is or isn't included,
but frankly, by the time I have done that, I have rolled my own kernel
as well.

> The second one is also unchanged, priviledged userspace access and
> kernel code injection via /dev/mem or are a changed kernel binary.

Access to /dev/mem can be restricted with a custom kernel. As for the
"changed kernel binary": I'm not sure what you mean by that. An attacker
with root privileges could of course exchange the kernel binary, but
once an attacker gained root privileges it's "game over" anyway.

> On the other side you loose any security support for this.

Ummm... what kind of security support do you get for a self-made Linux
firewall?

>> Second problem. Don't set policies to ACCEPT without a good reason.
>
> This applies to the filter chains only. Don't set it on the nat or
> mangle tables.

Correct. I should have mentioned that I was talking about the filter
table only there. My bad.

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

On 2009-01-31 Patrik Hasibuan wrote:
> --- Pada Sab, 31/1/09, Ansgar Wiechers <lists@planetcobalt.net> menulis:
>> Besides, why is your firewall running port-mapper, identd and print
>> spooler anyway? A firewall is a security device and should be running
>> as little services as possible.
>
> I installer ftp-proxy and dnsmasq, and then everything suddenly works.

Did you understand what I wrote about running services on a firewall?

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

On Sat, Jan 31, 2009 at 02:41:47AM +0100, Ansgar Wiechers wrote:
> I also strongly recommend running a custom
> (stripped-down) kernel.

Can you please explain why? As the distribution kernels are heavy
modularized you won't get much less kernel code, which is one attack
vector. The second one is also unchanged, priviledged userspace access
and kernel code injection via /dev/mem or are a changed kernel binary.

On the other side you loose any security support for this.

> Second problem. Don't set policies to ACCEPT without a good reason.

This applies to the filter chains only. Don't set it on the nat or
mangle tables.

Bastian

--
First study the enemy. Seek weakness.
-- Romulan Commander, "Balance of Terror", stardate 1709.2


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

Dear my generous friend, Kinglok.

Thank you very much for your help.

You helped me a lot. Thank you thousand times..... You solved my problem.


--- Pada Sab, 31/1/09, Kinglok, FONG <busywater@gmail.com> menulis:

> Dari: Kinglok, FONG <busywater@gmail.com>
> Topik: Re: my debian does not read my own iptables script
> Kepada: patrikhasibuan@ymail.com, debian-firewall@lists.debian.org
> Tanggal: Sabtu, 31 Januari, 2009, 6:51 AM
> Hi,
>
> I have rewritten your script as follows.
>
> 1. Ensure there is nothing like selinux running in your
> machine.
> 2. Telnet is not recommend since it transmit in plain text
> including your password. Use SSH instead.
> 3. ICMP message control, source address spoofing and
> logging are not included in the script.
> 4. I prefer the route setting-up is done through rc.local
> instead of the firewall script and the default gateway
> should be defined in /etc/network/interfaces
> 5. I have not tested the script.
>
> Kinglok, FONG.
>
> ----------------------------------Start------------------------------------------
> #!/bin/bash
>
> ###############################################################
> # Adding default gateway
> /sbin/route add default gateway 202.155.0.1
>
> ###############################################################
> # Initialize some parameter
> INET_INTERFACE="eth5"
> LAN_INTERFACE="eth2"
> LOOPBACK_INTERFACE="lo"
>
> IPT="/sbin/iptables"
> INET_ADDR="202.155.0.1"
> LAN_ADDR="192.168.23.2"
> LAN_SSH="192.168.23.20" # SSH server in LAN
> LAN_ADDRESSES="192.168.23.0/24" # LAN Addresses
> range
> LAN_DNS="" # Please specify your DNS server in
> LAN
>
> FTPPORT="21"
> SSHPORT="22"
> TELNETPORT="23"
> DNSPORT="53"
> UNPRIVPORTS="1024:65535" # unprivileged port
> range
>
> ###############################################################
> # Enable connection tracking for FTP
>
> /sbin/modprobe ip_conntrack_ftp
> /sbin/modprobe ip_nat_ftp
>
> ###############################################################
> # Initialization
>
> # Enable IP forwarding since it is disabled by default
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> # Enable broadcast echo Protection (default: 1)
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
>
> # Disable Source Routed Packets (default: 0)
> for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
> echo 0 > $f
> done
>
> # Enable TCP SYN Cookie Protection (default: 1)
> echo 1 > /proc/sys/net/ipv4/tcp_syncookies
>
> # Disable ICMP Redirect Acceptance (default: 0)
> for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
> echo 0 > $f
> done
>
> # Do not send Redirect Messages (default: 0)
> for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
> echo 0 > $f
> done
>
> # Drop Spoofed Packets coming in on an interface, which if
> replied to, would
> # result in the reply going out a different interface.
> (default: 1)
> for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
> echo 1 > $f
> done
>
> # Log packets with impossible addresses. (default: 1)
> for f in /proc/sys/net/ipv4/conf/*/log_martians; do
> echo 0 > $f
> done
>
> ###############################################################
> # Remove any existing rules from all chains
> $IPT --flush
> $IPT -t nat --flush
> $IPT -t mangle --flush
> $IPT -X
> $IPT -t nat -X
> $IPT -t mangle -X
> $IPT --policy INPUT ACCEPT
> $IPT --policy OUTPUT ACCEPT
> $IPT --policy FORWARD ACCEPT
> $IPT -t nat --policy PREROUTING ACCEPT
> $IPT -t nat --policy OUTPUT ACCEPT
> $IPT -t nat --policy POSTROUTING ACCEPT
> $IPT -t mangle --policy PREROUTING ACCEPT
> $IPT -t mangle --policy OUTPUT ACCEPT
> if [ "$1" = "stop" ]; then
> echo "Firewall completely stopped! WARNING: THIS HOST
> HAS NO FIREWALL RUNNING."
> exit
> fi
>
> # Unlimited traffic on the loopback interface
> $IPT -A INPUT -i $LOOPBACK_INTERFACE -j ACCEPT
> $IPT -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT
>
> # Set the default policy to drop
> $IPT --policy INPUT DROP
> $IPT --policy OUTPUT DROP
> $IPT --policy FORWARD DROP
>
> ###############################################################
> # NAT rules
> # Opening port 23 (telnet) to internet is not recommended,
> open port 22 for SSH instead
> $IPT -t nat -A PREROUTING -p tcp -i $INET_INTERFACE -p tcp
> --sport $UNPRIVPORTS -d $INET_ADDR --dport $SSHPORT -j DNAT
> --to-destination $LAN_SSH
>
> # There is no need for NAT inside LAN
> #$IPT -t nat -I PREROUTING -p tcp -i $LAN_INTERFACE -s
> $LAN_ADDRESSES -d 192.168.23.2 --dport 23 -j DNAT
> --to-destination 192.168.23.20:23
>
> # NAT rules for Reaching Internet Space
> $IPT -t nat -A POSTROUTING -p tcp -o $INET_INTERFACE -s
> $LAN_ADDRESSES -j SNAT --to-source $INET_ADDR
> #$IPT -t nat -A POSTROUTING -p tcp -o $LAN_INTERFACE -d
> $LAN_ADDRESSES -j SNAT --to-source 192.168.23.2 # There is
> no need for NAT to reach other addresses situated in LAN
>
> # It is not recommended to allow all icmp messages
> #$IPT -t nat -I POSTROUTING -p icmp -o $INET_INTERFACE -d
> 0/0 -j SNAT --to-source 202.155.0.1
> #$IPT -t nat -I POSTROUTING -p icmp -o $LAN_INTERFACE -d
> $LAN_ADDRESSES -j SNAT --to-source 192.168.23.2
>
> ###############################################################
> # Using Connection State to By-pass Rule Checking
> $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j
> ACCEPT
>
> ###############################################################
> # Open needed ports
> $IPT -A INPUT -i $LAN_INTERFACE -s $LAN_ADDRESSES -p icmp
> --icmp-type echo-request -m state --state NEW -j ACCEPT
> #$IPT -A INPUT -i $INET_INTERFACE -s 0/0 -p icmp
> --icmp-type echo-request -m state --state NEW -j ACCEPT #
> Not recommended
>
> $IPT -A OUTPUT -o $LAN_INTERFACE -d $LAN_ADDRESSES -p icmp
> --icmp-type echo-reply -m state --state NEW -j ACCEPT
> $IPT -A OUTPUT -o $INET_INTERFACE -p icmp --icmp-type
> echo-reply -m state --state NEW -j ACCEPT
>
> $IPT -A INPUT -i $LAN_INTERFACE -p tcp --dport $FTPPORT -m
> state --state NEW -j ACCEPT
> $IPT -A INPUT -i $LAN_INTERFACE -p tcp --dport $SSHPORT -m
> state --state NEW -j ACCEPT
> $IPT -A INPUT -i $LAN_INTERFACE -p tcp --dport $TELNETPORT
> -m state --state NEW -j ACCEPT
> $IPT -A INPUT -i $LAN_INTERFACE -p udp --dport $DNSPORT -m
> state --state NEW -j ACCEPT
>
> $IPT -A INPUT -i $INET_INTERFACE -p tcp --dport $FTPPORT -m
> state --state NEW -j ACCEPT
> $IPT -A INPUT -i $INET_INTERFACE -p tcp --dport $SSHPORT -m
> state --state NEW -j ACCEPT
> # $IPT -A INPUT -i $INET_INTERFACE -p tcp --dport 23 -j
> ACCEPT # Not recommended
> $IPT -A INPUT -i $INET_INTERFACE -p udp --dport $DNSPORT -m
> state --state NEW -j ACCEPT
>
> $IPT -A OUTPUT -o $LAN_INTERFACE -p tcp --dport $FTPPORT -m
> state --state NEW -j ACCEPT
> $IPT -A OUTPUT -o $LAN_INTERFACE -p tcp --dport $SSHPORT -m
> state --state NEW -j ACCEPT
> $IPT -A OUTPUT -o $LAN_INTERFACE -p tcp --dport $TELNETPORT
> -m state --state NEW -j ACCEPT
> $IPT -A OUTPUT -o $LAN_INTERFACE -p udp --dport $DNSPORT -m
> state --state NEW -j ACCEPT
>
> $IPT -A OUTPUT -o $INET_INTERFACE -p tcp --dport $FTPPORT
> -m state --state NEW -j ACCEPT
> $IPT -A OUTPUT -o $INET_INTERFACE -p tcp --dport $SSHPORT
> -m state --state NEW -j ACCEPT
> $IPT -A OUTPUT -o $INET_INTERFACE -p tcp --dport
> $TELNETPORT -m state --state NEW -j ACCEPT
> $IPT -A OUTPUT -o $INET_INTERFACE -p udp --dport $DNSPORT
> -m state --state NEW -j ACCEPT
>
> $IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES
> -o $INET_INTERFACE --dport $FTPPORT -m state --state NEW -j
> ACCEPT
> $IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES
> -o $INET_INTERFACE --dport $SSHPORT -m state --state NEW -j
> ACCEPT
> $IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES
> -o $INET_INTERFACE --dport $TELNETPORT -m state --state NEW
> -j ACCEPT
> $IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES
> -o $INET_INTERFACE --dport $DNSPORT -m state --state NEW -j
> ACCEPT
>
> $IPT -A FORWARD -p tcp -i $INET_INTERFACE -o $LAN_INTERFACE
> -d $LAN_ADDRESSES --dport $FTPPORT -m state --state NEW -j
> ACCEPT
> $IPT -A FORWARD -p tcp -i $INET_INTERFACE -o $LAN_INTERFACE
> -d $LAN_ADDRESSES -d $LAN_SSH --dport $SSHPORT -m state
> --state NEW -j ACCEPT
> # $IPT -A FORWARD -p tcp -i $INET_INTERFACE -s 0/0 -o
> $LAN_INTERFACE -d $LAN_ADDRESSES --dport 23 -m state --state
> NEW -j ACCEPT # Not recommended
> $IPT -A FORWARD -p tcp -i $INET_INTERFACE -o $LAN_INTERFACE
> -d $LAN_ADDRESSES -d $LAN_DNS --dport $DNSPORT -m state
> --state NEW -j ACCEPT
>
> -------------------------------------------------End-------------------------------------------
>
> ----- Original Message ----- From: "Patrik
> Hasibuan" <patrikhasibuan@ymail.com>
> To: <debian-firewall@lists.debian.org>
> Sent: Wednesday, January 28, 2009 3:36 PM
> Subject: my debian does not read my own iptables script
>
>
> Dear my friends,
>
> I am building a firewall with Debian Sarge on my internet
> gateway. But lookslike my debian does not read my iptables
> script after I run my own iptables script.
>
> This is the result of the firewall on my debian-box.
> '192.168.23.0' is the subnet of my internal LAN.
> eth2 faces my internal LAN whose IP '192.168.23.2'
> and eth5 faces my ISP whose IP '202.155.0.1':
> ==
> nmap 192.168.23.2
>
> Starting Nmap 4.20 ( http://insecure.org ) at 2009-01-28
> 15:12 WIT
> Interesting ports on 192.168.23.2:
> Not shown: 1692 closed ports
> PORT STATE SERVICE
> 22/tcp open ssh
> 25/tcp open smtp
> 111/tcp open rpcbind
> 113/tcp open auth
> 515/tcp open printer
>
> Nmap finished: 1 IP address (1 host up) scanned in 13.029
> seconds
> ==
> nmap 202.155.0.1
>
> Starting Nmap 4.20 ( http://insecure.org ) at 2009-01-28
> 15:12 WIT
> Interesting ports on 202.155.0.1:
> Not shown: 1693 closed ports
> PORT STATE SERVICE
> 22/tcp open ssh
> 111/tcp open rpcbind
> 113/tcp open auth
> 515/tcp open printer
>
> Nmap finished: 1 IP address (1 host up) scanned in 14.010
> seconds
> ==
> I haven't open the rpcbind,auth,printer. And the
> 21,23,53 are not opened by my iptables. Where is the
> mistake? Please tell me. I am new in debian and iptables.
> Usually I use OpenSuSE and SuSEfirewall2 and I configure the
> firewall with YaST2 so easily. But now I want to get close
> to debian too. And I am stucked on this case.
> ==
> here is my script
> ==
> #!/bin/bash
> #Zero...zero...from beginning
> iptables -F
>
> route add default gateway 202.155.0.1
>
> #Log....them
> iptables -I INPUT -j LOG
> iptables -I OUTPUT -j LOG
> iptables -I FORWARD -j LOG
>
> #Open needed ports
> iptables -I INPUT -i eth2 -s 192.168.23.0/24 -p icmp
> --icmp-type echo-request -j ACCEPT
> iptables -I INPUT -i eth5 -s 0/0 -p icmp --icmp-type
> echo-request -j ACCEPT
> iptables -I OUTPUT -o eth2 -d 192.168.23.0/24 -p icmp
> --icmp-type echo-reply -j ACCEPT
> iptables -I OUTPUT -o eth5 -d 0/0 -p icmp --icmp-type
> echo-reply -j ACCEPT
>
> iptables -I INPUT -i eth2 -p tcp --dport 21 -j ACCEPT
> iptables -I INPUT -i eth2 -p tcp --dport 22 -j ACCEPT
> iptables -I INPUT -i eth2 -p tcp --dport 23 -j ACCEPT
> iptables -I INPUT -i eth2 -p udp --dport 53 -j ACCEPT
>
> iptables -I INPUT -i eth5 -p tcp --dport 21 -j ACCEPT
> iptables -I INPUT -i eth5 -p tcp --dport 22 -j ACCEPT
> iptables -I INPUT -i eth5 -p tcp --dport 23 -j ACCEPT
> iptables -I INPUT -i eth5 -p udp --dport 53 -j ACCEPT
>
> iptables -I OUTPUT -o eth2 -p tcp --dport 21 -j ACCEPT
> iptables -I OUTPUT -o eth2 -p tcp --dport 22 -j ACCEPT
> iptables -I OUTPUT -o eth2 -p tcp --dport 23 -j ACCEPT
> iptables -I OUTPUT -o eth2 -p udp --dport 53 -j ACCEPT
>
> iptables -I OUTPUT -o eth5 -p tcp --dport 21 -j ACCEPT
> iptables -I OUTPUT -o eth5 -p tcp --dport 22 -j ACCEPT
> iptables -I OUTPUT -o eth5 -p tcp --dport 23 -j ACCEPT
> iptables -I OUTPUT -o eth5 -p udp --dport 53 -j ACCEPT
>
> iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o
> eth5 -d 0/0 --dport 21 -j ACCEPT
> iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o
> eth5 -d 0/0 --dport 22 -j ACCEPT
> iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o
> eth5 -d 0/0 --dport 23 -j ACCEPT
> iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o
> eth5 -d 0/0 --dport 53 -j ACCEPT
>
> iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d
> 192.168.23.0/24 --dport 21 -j ACCEPT
> iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d
> 192.168.23.0/24 --dport 22 -j ACCEPT
> iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d
> 192.168.23.0/24 --dport 23 -j ACCEPT
> iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d
> 192.168.23.0/24 --dport 53 -j ACCEPT
>
> iptables -t nat -I POSTROUTING -p icmp -o eth5 -d 0/0 -j
> SNAT --to-source 202.155.0.1
> iptables -t nat -I POSTROUTING -p icmp -o eth2 -d
> 192.168.23.0/24 -j SNAT --to-source 192.168.23.2
>
> iptables -t nat -I POSTROUTING -p tcp -o eth5 -d 0/0 -j
> SNAT --to-source 202.155.0.1
> iptables -t nat -I POSTROUTING -p tcp -o eth2 -d
> 192.168.23.0/24 -j SNAT --to-source 192.168.23.2
>
> iptables -t nat -I PREROUTING -p tcp -i eth5 -s 0/0 -d
> 202.155.0.1 --dport 23 -j DNAT --to-destination
> 192.168.23.20:23
> iptables -t nat -I PREROUTING -p tcp -i eth2 -s
> 192.168.23.0/24 -d 192.168.23.2 --dport 23 -j DNAT
> --to-destination 192.168.23.20:23
>
>
> Selalu bersama teman-teman di Yahoo! Messenger.
> Tambahkan mereka dari email atau jaringan sosial Anda
> sekarang! http://id.messenger.yahoo.com/invite/
>
>
> -- To UNSUBSCRIBE, email to
> debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
> -- To UNSUBSCRIBE, email to
> debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org


___________________________________________________________________________
Nama baru untuk Anda!
Dapatkan nama yang selalu Anda inginkan di domain baru @ymail dan @rocketmail.
Cepat sebelum diambil orang lain!
http://mail.promotions.yahoo.com/newdomains/id/


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

Dear Ansgar,

You are absolutely correct.

I installer ftp-proxy and dnsmasq, and then everything suddenly works.

Thank you very much. You've saved me.


--- Pada Sab, 31/1/09, Ansgar Wiechers <lists@planetcobalt.net> menulis:

> Dari: Ansgar Wiechers <lists@planetcobalt.net>
> Topik: Re: my debian does not read my own iptables script
> Kepada: debian-firewall@lists.debian.org
> Tanggal: Sabtu, 31 Januari, 2009, 1:41 AM
> On 2009-01-31 Patrik Hasibuan wrote:
> > Firstly, thank you very much for you reply.
>
> You're welcome.
>
> > It still does not give any change. So I start from a
> very simple,
> > namely: "Just opening some ports I need".
> But which opened are not
> > mentioned in my script.
> >
> > But the port of 21,23,53,10883 are always close. I
> don't mention port
> > of 111,113 and 515 in my iptables-script and I want
> they're be closed
> > but in fact they are stay open. Sigh...!!!
>
> There seems to be a misunderstanding about the nature of
> ports here.
> Ports don't magically turn "open", because
> you don't filter them on the
> firewall. A port is only in the state "open" if
> some daemon has a
> listening socket bound to it. For instance, port 111/tcp on
> your machine
> is probably open, because you're running the portmap
> daemon.
>
> If you want port 21/tcp to be open, you have to run a
> service listening
> on that port (usually an FTP server). On port 23/tcp
> you'd normally run
> a telnet server (although I'd strongly recommend
> against doing so, since
> SSH is a far better option). On ports 53/tcp and 53/udp
> you'd normally
> be running your DNS server, and so on.
>
> Besides, why is your firewall running port-mapper, identd
> and print
> spooler anyway? A firewall is a security device and should
> be running as
> little services as possible. I also strongly recommend
> running a custom
> (stripped-down) kernel.
>
> [...]
> > This is my complete script:
> > #!/bin/bash
> > #Zero...zero...from beginning
> > iptables -F
> > iptables -t nat -F
> > iptables -t mangle -F
> >
> > iptables -X
> > iptables -t nat -X
> > iptables -t mangle -X
> >
> > echo "0" > /proc/sys/net/ipv4/ip_forward
> >
> > #route add default gateway 219.83.114.177
> >
> > #Basic policy
> > iptables -P INPUT DROP
> > iptables -P FORWARD ACCEPT
> > iptables -P OUTPUT ACCEPT
>
> First problem. Never flush your chains before setting the
> default
> policies. If you do, you have a (however short) period of
> time where
> your firewall may be wide open. Always initialize your
> firewall in the
> order I lined out in my previous posting.
>
> Second problem. Don't set policies to ACCEPT without a
> good reason.
> Setting the OUTPUT chain to ACCEPT is arguably okay,
> because as long as
> your firewall isn't compromised, the traffic
> originating from it can be
> considered trustworthy. And if it becomes compromised you
> have bigger
> problems than some outbound connections. However, this
> reasoning does
> *not* apply to the FORWARD chain. That chain handles all
> packets that
> your firewall transfers between your LAN and the Internet.
> Set the
> policy to ACCEPT and your LAN is wide open to the world.
> Don't do that.
>
> > iptables -A INPUT -m state --state INVALID -j DROP
> > iptables -A INPUT -p tcp -m state --state
> NEW,ESTABLISHED -j ACCEPT
>
> This is the actual culprit. You're accepting all
> inbound TCP connections
> to any port. Don't do that.
>
> > iptables -A OUTPUT -p tcp -m state --state
> NEW,ESTABLISHED -j ACCEPT
>
> This rule is pointless, since you're accepting
> everything in the OUTPUT
> chain anyway.
>
> > iptables -A FORWARD -p tcp -m state --state
> NEW,ESTABLISHED -j ACCEPT
>
> Same as with the INPUT chain. Only worse. Never allow all
> inbound TCP
> connections to your LAN. Ever. That's a big no-no.
>
> You probably meant to write these rules instead of the
> three above:
>
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j
> ACCEPT
>
> These will allow all traffic belonging to already
> established
> connections, but won't allow to actually establish any
> connection. You
> do that by accepting NEW connections to particular ports.
>
> > iptables -t nat -P PREROUTING ACCEPT
> > iptables -t nat -P POSTROUTING ACCEPT
> > iptables -t nat -P OUTPUT ACCEPT
> >
> > echo "1" > /proc/sys/net/ipv4/ip_forward
> >
> > #Log....them
> > iptables -A INPUT -j LOG
> > iptables -A OUTPUT -j LOG
> > iptables -A FORWARD -j LOG
>
> Because your ruleset is already accepting all traffic at
> this point,
> incoming/outgoing packets will never reach these rules, so
> they won't
> log anything.
>
> > iptables -A INPUT -p tcp -m multiport --source-port
> 20,22,23,53,10883 -j ACCEPT
> > iptables -A INPUT -p udp -m multiport --source-port
> 20,22,23,53,10883 -j ACCEPT
> > iptables -A INPUT -p tcp -m multiport --sport 21 -j
> ACCEPT
> > iptables -A INPUT -p udp -m multiport --sport 21 -j
> ACCEPT
> >
> > iptables -A OUTPUT -p tcp -m multiport
> --destination-port 20,22,23,53,10883 -j ACCEPT
> > iptables -A OUTPUT -p udp -m multiport
> --destination-port 20,22,23,53,10883 -j ACCEPT
> > iptables -A OUTPUT -p tcp -m multiport --dport 21 -j
> ACCEPT
> > iptables -A OUTPUT -p udp -m multiport --dport 21 -j
> ACCEPT
>
> Thes rules will allow your users to establish connections
> (you should
> add "-m state --state NEW" to them, though).
> However, it looks to me
> like you got your perspective wrong. Why are you accepting
> inbound
> connections TO your firewall with those source ports? And
> why outbound
> connections FROM your firewall TO those destination ports
> on some other
> server?
>
> Also your FORWARD chain seems rather useless. You don't
> seem to be
> passing any particular traffic between a LAN and the
> Internet, and your
> not NATing the traffic either.
>
> Perhaps you should elaborate a little on your setup and
> what you
> actually want to achieve.
>
> Regards
> Ansgar Wiechers
> --
> "The Mac OS X kernel should never panic because, when
> it does, it
> seriously inconveniences the user."
> --http://developer.apple.com/technotes/tn2004/tn2118.html
>
>
> --
> To UNSUBSCRIBE, email to
> debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org


Menambah banyak teman sangatlah mudah dan cepat. Undang teman dari Hotmail, Gmail ke Yahoo! Messenger sekarang! http://id.messenger.yahoo.com/invite/


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Friday, January 30, 2009

Re: my debian does not read my own iptables script

Hi,

I have rewritten your script as follows.

1. Ensure there is nothing like selinux running in your machine.
2. Telnet is not recommend since it transmit in plain text including your
password. Use SSH instead.
3. ICMP message control, source address spoofing and logging are not
included in the script.
4. I prefer the route setting-up is done through rc.local instead of the
firewall script and the default gateway should be defined in
/etc/network/interfaces
5. I have not tested the script.

Kinglok, FONG.

----------------------------------Start------------------------------------------
#!/bin/bash

###############################################################
# Adding default gateway
/sbin/route add default gateway 202.155.0.1

###############################################################
# Initialize some parameter
INET_INTERFACE="eth5"
LAN_INTERFACE="eth2"
LOOPBACK_INTERFACE="lo"

IPT="/sbin/iptables"
INET_ADDR="202.155.0.1"
LAN_ADDR="192.168.23.2"
LAN_SSH="192.168.23.20" # SSH server in LAN
LAN_ADDRESSES="192.168.23.0/24" # LAN Addresses range
LAN_DNS="" # Please specify your DNS server in LAN

FTPPORT="21"
SSHPORT="22"
TELNETPORT="23"
DNSPORT="53"
UNPRIVPORTS="1024:65535" # unprivileged port range

###############################################################
# Enable connection tracking for FTP

/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp

###############################################################
# Initialization

# Enable IP forwarding since it is disabled by default
echo 1 > /proc/sys/net/ipv4/ip_forward

# Enable broadcast echo Protection (default: 1)
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets (default: 0)
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 > $f
done

# Enable TCP SYN Cookie Protection (default: 1)
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance (default: 0)
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo 0 > $f
done

# Do not send Redirect Messages (default: 0)
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo 0 > $f
done

# Drop Spoofed Packets coming in on an interface, which if replied to, would
# result in the reply going out a different interface. (default: 1)
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done

# Log packets with impossible addresses. (default: 1)
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 0 > $f
done

###############################################################
# Remove any existing rules from all chains
$IPT --flush
$IPT -t nat --flush
$IPT -t mangle --flush
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X
$IPT --policy INPUT ACCEPT
$IPT --policy OUTPUT ACCEPT
$IPT --policy FORWARD ACCEPT
$IPT -t nat --policy PREROUTING ACCEPT
$IPT -t nat --policy OUTPUT ACCEPT
$IPT -t nat --policy POSTROUTING ACCEPT
$IPT -t mangle --policy PREROUTING ACCEPT
$IPT -t mangle --policy OUTPUT ACCEPT
if [ "$1" = "stop" ]; then
echo "Firewall completely stopped! WARNING: THIS HOST HAS NO FIREWALL
RUNNING."
exit
fi

# Unlimited traffic on the loopback interface
$IPT -A INPUT -i $LOOPBACK_INTERFACE -j ACCEPT
$IPT -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT

# Set the default policy to drop
$IPT --policy INPUT DROP
$IPT --policy OUTPUT DROP
$IPT --policy FORWARD DROP

###############################################################
# NAT rules
# Opening port 23 (telnet) to internet is not recommended, open port 22 for
SSH instead
$IPT -t nat -A PREROUTING -p tcp -i $INET_INTERFACE -p tcp --sport
$UNPRIVPORTS -d $INET_ADDR --dport $SSHPORT -j DNAT --to-destination
$LAN_SSH

# There is no need for NAT inside LAN
#$IPT -t nat -I PREROUTING -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES -d
192.168.23.2 --dport 23 -j DNAT --to-destination 192.168.23.20:23

# NAT rules for Reaching Internet Space
$IPT -t nat -A POSTROUTING -p tcp -o $INET_INTERFACE -s $LAN_ADDRESSES -j
SNAT --to-source $INET_ADDR
#$IPT -t nat -A POSTROUTING -p tcp -o $LAN_INTERFACE -d $LAN_ADDRESSES -j
SNAT --to-source 192.168.23.2 # There is no need for NAT to reach other
addresses situated in LAN

# It is not recommended to allow all icmp messages
#$IPT -t nat -I POSTROUTING -p icmp -o $INET_INTERFACE -d 0/0 -j
SNAT --to-source 202.155.0.1
#$IPT -t nat -I POSTROUTING -p icmp -o $LAN_INTERFACE -d $LAN_ADDRESSES -j
SNAT --to-source 192.168.23.2

###############################################################
# Using Connection State to By-pass Rule Checking
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

###############################################################
# Open needed ports
$IPT -A INPUT -i $LAN_INTERFACE -s $LAN_ADDRESSES -p icmp --icmp-type
echo-request -m state --state NEW -j ACCEPT
#$IPT -A INPUT -i $INET_INTERFACE -s 0/0 -p icmp --icmp-type echo-request -m
state --state NEW -j ACCEPT # Not recommended

$IPT -A OUTPUT -o $LAN_INTERFACE -d $LAN_ADDRESSES -p icmp --icmp-type
echo-reply -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -o $INET_INTERFACE -p icmp --icmp-type echo-reply -m
state --state NEW -j ACCEPT

$IPT -A INPUT -i $LAN_INTERFACE -p tcp --dport $FTPPORT -m state --state
NEW -j ACCEPT
$IPT -A INPUT -i $LAN_INTERFACE -p tcp --dport $SSHPORT -m state --state
NEW -j ACCEPT
$IPT -A INPUT -i $LAN_INTERFACE -p tcp --dport $TELNETPORT -m state --state
NEW -j ACCEPT
$IPT -A INPUT -i $LAN_INTERFACE -p udp --dport $DNSPORT -m state --state
NEW -j ACCEPT

$IPT -A INPUT -i $INET_INTERFACE -p tcp --dport $FTPPORT -m state --state
NEW -j ACCEPT
$IPT -A INPUT -i $INET_INTERFACE -p tcp --dport $SSHPORT -m state --state
NEW -j ACCEPT
# $IPT -A INPUT -i $INET_INTERFACE -p tcp --dport 23 -j ACCEPT # Not
recommended
$IPT -A INPUT -i $INET_INTERFACE -p udp --dport $DNSPORT -m state --state
NEW -j ACCEPT

$IPT -A OUTPUT -o $LAN_INTERFACE -p tcp --dport $FTPPORT -m state --state
NEW -j ACCEPT
$IPT -A OUTPUT -o $LAN_INTERFACE -p tcp --dport $SSHPORT -m state --state
NEW -j ACCEPT
$IPT -A OUTPUT -o $LAN_INTERFACE -p tcp --dport $TELNETPORT -m state --state
NEW -j ACCEPT
$IPT -A OUTPUT -o $LAN_INTERFACE -p udp --dport $DNSPORT -m state --state
NEW -j ACCEPT

$IPT -A OUTPUT -o $INET_INTERFACE -p tcp --dport $FTPPORT -m state --state
NEW -j ACCEPT
$IPT -A OUTPUT -o $INET_INTERFACE -p tcp --dport $SSHPORT -m state --state
NEW -j ACCEPT
$IPT -A OUTPUT -o $INET_INTERFACE -p tcp --dport $TELNETPORT -m
state --state NEW -j ACCEPT
$IPT -A OUTPUT -o $INET_INTERFACE -p udp --dport $DNSPORT -m state --state
NEW -j ACCEPT

$IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES -o
$INET_INTERFACE --dport $FTPPORT -m state --state NEW -j ACCEPT
$IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES -o
$INET_INTERFACE --dport $SSHPORT -m state --state NEW -j ACCEPT
$IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES -o
$INET_INTERFACE --dport $TELNETPORT -m state --state NEW -j ACCEPT
$IPT -A FORWARD -p tcp -i $LAN_INTERFACE -s $LAN_ADDRESSES -o
$INET_INTERFACE --dport $DNSPORT -m state --state NEW -j ACCEPT

$IPT -A FORWARD -p tcp -i $INET_INTERFACE -o $LAN_INTERFACE -d
$LAN_ADDRESSES --dport $FTPPORT -m state --state NEW -j ACCEPT
$IPT -A FORWARD -p tcp -i $INET_INTERFACE -o $LAN_INTERFACE -d
$LAN_ADDRESSES -d $LAN_SSH --dport $SSHPORT -m state --state NEW -j ACCEPT
# $IPT -A FORWARD -p tcp -i $INET_INTERFACE -s 0/0 -o $LAN_INTERFACE -d
$LAN_ADDRESSES --dport 23 -m state --state NEW -j ACCEPT # Not recommended
$IPT -A FORWARD -p tcp -i $INET_INTERFACE -o $LAN_INTERFACE -d
$LAN_ADDRESSES -d $LAN_DNS --dport $DNSPORT -m state --state NEW -j ACCEPT

-------------------------------------------------End-------------------------------------------

----- Original Message -----
From: "Patrik Hasibuan" <patrikhasibuan@ymail.com>
To: <debian-firewall@lists.debian.org>
Sent: Wednesday, January 28, 2009 3:36 PM
Subject: my debian does not read my own iptables script


Dear my friends,

I am building a firewall with Debian Sarge on my internet gateway. But
lookslike my debian does not read my iptables script after I run my own
iptables script.

This is the result of the firewall on my debian-box. '192.168.23.0' is the
subnet of my internal LAN. eth2 faces my internal LAN whose IP
'192.168.23.2' and eth5 faces my ISP whose IP '202.155.0.1':
==
nmap 192.168.23.2

Starting Nmap 4.20 ( http://insecure.org ) at 2009-01-28 15:12 WIT
Interesting ports on 192.168.23.2:
Not shown: 1692 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
113/tcp open auth
515/tcp open printer

Nmap finished: 1 IP address (1 host up) scanned in 13.029 seconds
==
nmap 202.155.0.1

Starting Nmap 4.20 ( http://insecure.org ) at 2009-01-28 15:12 WIT
Interesting ports on 202.155.0.1:
Not shown: 1693 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
113/tcp open auth
515/tcp open printer

Nmap finished: 1 IP address (1 host up) scanned in 14.010 seconds
==
I haven't open the rpcbind,auth,printer. And the 21,23,53 are not opened by
my iptables. Where is the mistake? Please tell me. I am new in debian and
iptables. Usually I use OpenSuSE and SuSEfirewall2 and I configure the
firewall with YaST2 so easily. But now I want to get close to debian too.
And I am stucked on this case.
==
here is my script
==
#!/bin/bash
#Zero...zero...from beginning
iptables -F

route add default gateway 202.155.0.1

#Log....them
iptables -I INPUT -j LOG
iptables -I OUTPUT -j LOG
iptables -I FORWARD -j LOG

#Open needed ports
iptables -I INPUT -i eth2 -s 192.168.23.0/24 -p icmp --icmp-type
echo-request -j ACCEPT
iptables -I INPUT -i eth5 -s 0/0 -p icmp --icmp-type echo-request -j ACCEPT
iptables -I OUTPUT -o eth2 -d 192.168.23.0/24 -p icmp --icmp-type
echo-reply -j ACCEPT
iptables -I OUTPUT -o eth5 -d 0/0 -p icmp --icmp-type echo-reply -j ACCEPT

iptables -I INPUT -i eth2 -p tcp --dport 21 -j ACCEPT
iptables -I INPUT -i eth2 -p tcp --dport 22 -j ACCEPT
iptables -I INPUT -i eth2 -p tcp --dport 23 -j ACCEPT
iptables -I INPUT -i eth2 -p udp --dport 53 -j ACCEPT

iptables -I INPUT -i eth5 -p tcp --dport 21 -j ACCEPT
iptables -I INPUT -i eth5 -p tcp --dport 22 -j ACCEPT
iptables -I INPUT -i eth5 -p tcp --dport 23 -j ACCEPT
iptables -I INPUT -i eth5 -p udp --dport 53 -j ACCEPT

iptables -I OUTPUT -o eth2 -p tcp --dport 21 -j ACCEPT
iptables -I OUTPUT -o eth2 -p tcp --dport 22 -j ACCEPT
iptables -I OUTPUT -o eth2 -p tcp --dport 23 -j ACCEPT
iptables -I OUTPUT -o eth2 -p udp --dport 53 -j ACCEPT

iptables -I OUTPUT -o eth5 -p tcp --dport 21 -j ACCEPT
iptables -I OUTPUT -o eth5 -p tcp --dport 22 -j ACCEPT
iptables -I OUTPUT -o eth5 -p tcp --dport 23 -j ACCEPT
iptables -I OUTPUT -o eth5 -p udp --dport 53 -j ACCEPT

iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o eth5 -d 0/0 --dport
21 -j ACCEPT
iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o eth5 -d 0/0 --dport
22 -j ACCEPT
iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o eth5 -d 0/0 --dport
23 -j ACCEPT
iptables -I FORWARD -p tcp -i eth2 -s 192.168.23.0/24 -o eth5 -d 0/0 --dport
53 -j ACCEPT

iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d 192.168.23.0/24 --dport
21 -j ACCEPT
iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d 192.168.23.0/24 --dport
22 -j ACCEPT
iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d 192.168.23.0/24 --dport
23 -j ACCEPT
iptables -I FORWARD -p tcp -i eth5 -s 0/0 -o eth2 -d 192.168.23.0/24 --dport
53 -j ACCEPT

iptables -t nat -I POSTROUTING -p icmp -o eth5 -d 0/0 -j SNAT --to-source
202.155.0.1
iptables -t nat -I POSTROUTING -p icmp -o eth2 -d 192.168.23.0/24 -j
SNAT --to-source 192.168.23.2

iptables -t nat -I POSTROUTING -p tcp -o eth5 -d 0/0 -j SNAT --to-source
202.155.0.1
iptables -t nat -I POSTROUTING -p tcp -o eth2 -d 192.168.23.0/24 -j
SNAT --to-source 192.168.23.2

iptables -t nat -I PREROUTING -p tcp -i eth5 -s 0/0 -d 202.155.0.1 --dport
23 -j DNAT --to-destination 192.168.23.20:23
iptables -t nat -I PREROUTING -p tcp -i eth2 -s 192.168.23.0/24 -d
192.168.23.2 --dport 23 -j DNAT --to-destination 192.168.23.20:23


Selalu bersama teman-teman di Yahoo! Messenger. Tambahkan mereka dari
email atau jaringan sosial Anda sekarang!
http://id.messenger.yahoo.com/invite/


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

On 2009-01-31 Patrik Hasibuan wrote:
> Firstly, thank you very much for you reply.

You're welcome.

> It still does not give any change. So I start from a very simple,
> namely: "Just opening some ports I need". But which opened are not
> mentioned in my script.
>
> But the port of 21,23,53,10883 are always close. I don't mention port
> of 111,113 and 515 in my iptables-script and I want they're be closed
> but in fact they are stay open. Sigh...!!!

There seems to be a misunderstanding about the nature of ports here.
Ports don't magically turn "open", because you don't filter them on the
firewall. A port is only in the state "open" if some daemon has a
listening socket bound to it. For instance, port 111/tcp on your machine
is probably open, because you're running the portmap daemon.

If you want port 21/tcp to be open, you have to run a service listening
on that port (usually an FTP server). On port 23/tcp you'd normally run
a telnet server (although I'd strongly recommend against doing so, since
SSH is a far better option). On ports 53/tcp and 53/udp you'd normally
be running your DNS server, and so on.

Besides, why is your firewall running port-mapper, identd and print
spooler anyway? A firewall is a security device and should be running as
little services as possible. I also strongly recommend running a custom
(stripped-down) kernel.

[...]
> This is my complete script:
> #!/bin/bash
> #Zero...zero...from beginning
> iptables -F
> iptables -t nat -F
> iptables -t mangle -F
>
> iptables -X
> iptables -t nat -X
> iptables -t mangle -X
>
> echo "0" > /proc/sys/net/ipv4/ip_forward
>
> #route add default gateway 219.83.114.177
>
> #Basic policy
> iptables -P INPUT DROP
> iptables -P FORWARD ACCEPT
> iptables -P OUTPUT ACCEPT

First problem. Never flush your chains before setting the default
policies. If you do, you have a (however short) period of time where
your firewall may be wide open. Always initialize your firewall in the
order I lined out in my previous posting.

Second problem. Don't set policies to ACCEPT without a good reason.
Setting the OUTPUT chain to ACCEPT is arguably okay, because as long as
your firewall isn't compromised, the traffic originating from it can be
considered trustworthy. And if it becomes compromised you have bigger
problems than some outbound connections. However, this reasoning does
*not* apply to the FORWARD chain. That chain handles all packets that
your firewall transfers between your LAN and the Internet. Set the
policy to ACCEPT and your LAN is wide open to the world. Don't do that.

> iptables -A INPUT -m state --state INVALID -j DROP
> iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

This is the actual culprit. You're accepting all inbound TCP connections
to any port. Don't do that.

> iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

This rule is pointless, since you're accepting everything in the OUTPUT
chain anyway.

> iptables -A FORWARD -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

Same as with the INPUT chain. Only worse. Never allow all inbound TCP
connections to your LAN. Ever. That's a big no-no.

You probably meant to write these rules instead of the three above:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

These will allow all traffic belonging to already established
connections, but won't allow to actually establish any connection. You
do that by accepting NEW connections to particular ports.

> iptables -t nat -P PREROUTING ACCEPT
> iptables -t nat -P POSTROUTING ACCEPT
> iptables -t nat -P OUTPUT ACCEPT
>
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> #Log....them
> iptables -A INPUT -j LOG
> iptables -A OUTPUT -j LOG
> iptables -A FORWARD -j LOG

Because your ruleset is already accepting all traffic at this point,
incoming/outgoing packets will never reach these rules, so they won't
log anything.

> iptables -A INPUT -p tcp -m multiport --source-port 20,22,23,53,10883 -j ACCEPT
> iptables -A INPUT -p udp -m multiport --source-port 20,22,23,53,10883 -j ACCEPT
> iptables -A INPUT -p tcp -m multiport --sport 21 -j ACCEPT
> iptables -A INPUT -p udp -m multiport --sport 21 -j ACCEPT
>
> iptables -A OUTPUT -p tcp -m multiport --destination-port 20,22,23,53,10883 -j ACCEPT
> iptables -A OUTPUT -p udp -m multiport --destination-port 20,22,23,53,10883 -j ACCEPT
> iptables -A OUTPUT -p tcp -m multiport --dport 21 -j ACCEPT
> iptables -A OUTPUT -p udp -m multiport --dport 21 -j ACCEPT

Thes rules will allow your users to establish connections (you should
add "-m state --state NEW" to them, though). However, it looks to me
like you got your perspective wrong. Why are you accepting inbound
connections TO your firewall with those source ports? And why outbound
connections FROM your firewall TO those destination ports on some other
server?

Also your FORWARD chain seems rather useless. You don't seem to be
passing any particular traffic between a LAN and the Internet, and your
not NATing the traffic either.

Perhaps you should elaborate a little on your setup and what you
actually want to achieve.

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: my debian does not read my own iptables script

Dear Ansgar,

Firstly, thank you very much for you reply.

It still does not give any change. So I start from a very simple, namely: "Just opening some ports I need". But which opened are not mentioned in my script.

But the port of 21,23,53,10883 are always close. I don't mention port of 111,113 and 515 in my iptables-script and I want they're be closed but in fact they are stay open. Sigh...!!!

But this is the output of my iptables script:
patrik@debbylap:~$ nmap 219.83.114.180

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-01-31 06:31 WIT
Interesting ports on 219.83.114.180:
Not shown: 1676 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
113/tcp open auth
515/tcp open printer

Nmap finished: 1 IP address (1 host up) scanned in 9.345 seconds
======
This is my complete script:
#!/bin/bash
#Zero...zero...from beginning
iptables -F
iptables -t nat -F
iptables -t mangle -F

iptables -X
iptables -t nat -X
iptables -t mangle -X

echo "0" > /proc/sys/net/ipv4/ip_forward

#route add default gateway 219.83.114.177

#Basic policy
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

echo "1" > /proc/sys/net/ipv4/ip_forward

#Log....them
iptables -A INPUT -j LOG
iptables -A OUTPUT -j LOG
iptables -A FORWARD -j LOG

iptables -A INPUT -p tcp -m multiport --source-port 20,22,23,53,10883 -j ACCEPT
iptables -A INPUT -p udp -m multiport --source-port 20,22,23,53,10883 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --sport 21 -j ACCEPT
iptables -A INPUT -p udp -m multiport --sport 21 -j ACCEPT

iptables -A OUTPUT -p tcp -m multiport --destination-port 20,22,23,53,10883 -j ACCEPT
iptables -A OUTPUT -p udp -m multiport --destination-port 20,22,23,53,10883 -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dport 21 -j ACCEPT
iptables -A OUTPUT -p udp -m multiport --dport 21 -j ACCEPT
============
mydebian:/etc/apt# iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
DROP 0 -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED
LOG 0 -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport sports 20,22,23,53,10883
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport sports 20,22,23,53,10883
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport sports 21
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport sports 21

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED
LOG 0 -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED
LOG 0 -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 20,22,23,53,10883
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 20,22,23,53,10883
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 21
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 21
mydebian:/etc/apt#
--- Pada Rab, 28/1/09, Ansgar Wiechers <lists@planetcobalt.net> menulis:

> Dari: Ansgar Wiechers <lists@planetcobalt.net>
> Topik: Re: my debian does not read my own iptables script
> Kepada: debian-firewall@lists.debian.org
> Tanggal: Rabu, 28 Januari, 2009, 11:51 AM
> On 2009-01-28 Patrik Hasibuan wrote:
> > I am building a firewall with Debian Sarge on my
> internet gateway. But
> > lookslike my debian does not read my iptables script
> after I run my
> > own iptables script.
> [...]
> > I haven't open the rpcbind,auth,printer. And the
> 21,23,53 are not
> > opened by my iptables. Where is the mistake? Please
> tell me. I am new
> > in debian and iptables. Usually I use OpenSuSE and
> SuSEfirewall2 and I
> > configure the firewall with YaST2 so easily. But now I
> want to get
> > close to debian too. And I am stucked on this case.
> [...]
> > #!/bin/bash
> > #Zero...zero...from beginning
> > iptables -F
>
> You are not setting default policies (bad idea), so your
> chains probably
> accept all incoming packets. As others have told you
> before: please post
> the output of "iptables -nL" and "iptables
> -t nat -nL" (and perhaps the
> output of "iptables -t mangle -nL" and
> "iptables -t raw -nL").
>
> As a starting point, my iptables scripts usually begin like
> this:
>
> ----8<----
> # 1) Disable IP forwarding.
> echo "0" > /proc/sys/net/ipv4/ip_forward
>
> # 2) Set default policies
> iptables -P INPUT DROP
> iptables -P OUTPUT ACCEPT
> iptables -P FORWARD DROP
>
> iptables -t nat -P PREROUTING ACCEPT
> iptables -t nat -P POSTROUTING ACCEPT
> iptables -t nat -P OUTPUT ACCEPT
>
> # 3) Flush chains
> iptables -F
> iptables -t nat -F
>
> # 4) Delete user-defined chains
> iptables -X
> iptables -t nat -X
>
> # 5) Re-enable IP forwarding (if required)
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> # ...
> ---->8----
>
> Regards
> Ansgar Wiechers
> --
> "The Mac OS X kernel should never panic because, when
> it does, it
> seriously inconveniences the user."
> --http://developer.apple.com/technotes/tn2004/tn2118.html
>
>
> --
> To UNSUBSCRIBE, email to
> debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org


___________________________________________________________________________
Dapatkan nama yang Anda sukai!
Sekarang Anda dapat memiliki email di @ymail.com dan @rocketmail.com.
http://mail.promotions.yahoo.com/newdomains/id/


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

StreetView killed Bambi, but also fights crime; Securing Super Bowl 43; Activists target Microsoft

Network World logo

Daily News PM Alert

NetworkWorld.com | LANs & WANs Research Center | Update Your Profile


Sponsored by Oracle
rule

Successfully Manage a Secure Database.
Database professionals are invited to join this Oracle Live Webcast on Thursday, February 5 at 2:00 p.m. ET/11:00 a.m. PT. Gain a better understanding of database security and how to more strategically work with security administrators. Don't miss out. Register for this live webcast now

rule

Spotlight Story

StreetView killed Bambi, but it fights crime, too
By Google Subnet
With all the attention Google StreetView's clash with a baby deer evoked, it can be easy to overlook the tool's crime-fighting good side. Not too long ago, StreetView was instrumental in returning a kidnapped Massachusetts girl safely to her home, and just recently, it helped a Swiss police team detect a 1.2-acre marijuana field and nab the gang responsible. As with all things Google, you have to take the bad with the good. Read full story

Related News:

News podcast: Network World 360
IT salaries won't be spared from the economic malaise plaguing North America. The odds are pretty good that this will never happen to you, but should a floating head of U.S. President Barack Obama pop up on your desktop Monday morning, know this: You've been hit with the Obama worm. (7:33)

Securing Super Bowl 43
Bob Cannon from Johnson Controls, a systems integrator, talks about the physical security systems at Raymond James Stadium in Tampa Bay, site of this year's Super Bowl. The network he and his team built allow multiple agencies access cameras and other systems through a single network. (11:09)

Shareholder activist targets Microsoft
Craig Montgomery of The Crandrea Group is spearheading a grassroots shareholder activism movement that aims to oust Ballmer and turn Microsoft into a telecom player.

Worm floats Obama's head on your desktop
The odds are pretty good that this will never happen to you, but should a floating head of U.S. President Barack Obama pop up on your desktop Monday morning, know this: You've been hit with the Obama worm.

State's plan to reprogram huge spectrum asset faces challenges
South Carolina wants to repurpose a big chunk of long-dormant spectrum, enough to offer high-bandwidth broadband services from border to border. But the plan faces challenges in the economy, the legislature, and ...

How carriers will weather the recession
Telecom carriers generally use three tactics to guide themselves through a recession: layoffs, capital investment cuts and an emphasis on cheaper plans.

Nortel ends mobile WiMAX agreement, exits business
Nortel this week announced that it has decided to discontinue its mobile WiMAX business and end its joint agreement with Alvarion.

Juniper Q4 grows, but falls short
Juniper posted a 14% hike in fourth-quarter sales that nonetheless fell short of Wall Street expectations.

NEC to lay off 20,000 as economy bites
NEC plans to lay off 20,000 workers, close factories and withdraw from some business areas as a result of the poor economic conditions, it said Friday.

Google Chrome Spoofing User Agent at Hotmail
Lenssen: An update to Google’s browser Chrome fixes an issue with Hotmail – by faking which browser it is.

What if my storage cloud turns stormy?
Services that store enterprise data in a "cloud" on the Internet raise questions that organizations are just beginning to ask, but for all their limitations, they may be no more risky than on-site storage platforms. Plus:
Tips for safe cloud storage

Researchers cool CPUs with nano-size fridges
Cramming ever more transistors into CPUs has not troubled chip makers Intel Corp. and AMD Inc. The problem, rather, has been how to handle the extreme heat generated by the movement of so many electrons in such a tiny ...


Betting on SuperNAP
In Las Vegas, data center takes power and cooling to the limitIn Las Vegas, data center takes power and cooling to the limit.

Data gone missing
10 woeful tales of data gone missing10 woeful tales involving backup tapes: some current, some classic and one just plain unusual.

Sponsored by Oracle
rule

Successfully Manage a Secure Database.
Database professionals are invited to join this Oracle Live Webcast on Thursday, February 5 at 2:00 p.m. ET/11:00 a.m. PT. Gain a better understanding of database security and how to more strategically work with security administrators. Don't miss out. Register for this live webcast now

rule

Preparing for the Next Cyber Attack.
Ensure you are up-to-speed on the latest security technologies available to keep your network safe in this Executive Guide. Get a thorough assessment of the corporate security threat landscape. Protect your network with data leakage protection, NAC and other technologies explained in this report.
Download this Executive Guide now.


Comparing Troubleshooting Tools.
Better understand which network and application troubleshooting tools make the most sense for your IT shop. SNMP, NetFlow and packet analysis offer trending, network forensics, and server response time measurements. Learn the pros and cons of each and how they simply are not enough on their own.
Watch this webcast now.

 

01/30/09

Today's most-read stories:

  1. Ex-Fannie Mae employee accused of planting computer time bomb
  2. Fan starts campaign for Windows 7's immediate release
  3. Windows 7 will not sway XP users
  4. Google M-Lab provides a window into your ISP
  5. Don't fear the penguin: A newbie's guide to Linux
  6. 10 woeful tales of data gone missing
  7. IPhone takes 1.1% of the mobile phone market
  8. Worm floats Obama's head on your desktop
  9. Taser-wielding boss? Can't get to me here
  10. Are these the real reasons for the fall of Nortel?


Effectively Managing Change.
Find the right network/system management platforms that leverage the latest IT technologies in this Executive Guide, "The New Network/System Management Challenges." Get a handle on server sprawl, managing 802.11n wireless LANs, and data center automation tool integration. Confidently deploy innovative technologies that drive efficiencies today.
Download this Executive Guide now.



IT Buyers guide

 


This email was sent to security.world@gmail.com

Complimentary Subscriptions Available
for newsletter subscribers. Receive 50 issues
of Network World Magazines, in print or
electronic format, free of charge, Apply here.

Terms of Service/Privacy

 

Subscription Services Update your profile
To subscribe or unsubscribe to any Network
World newsletter, change your e-mail
address or contact us, click here.

Unsubscribe

Network World, Inc., 492 Old Connecticut Path, Framingham, MA 01701
Copyright Network World, Inc., 2009

www.networkworld.com