Re: Firewall-troubleshooting

[KC]

Hi,

I am tring out firehol right now on a fresh optimized version of this
firewall that I decided to make from scratch. The damn thing still won't
work. I know I am missing something important in both these scripts because
 in both cases it drops everything and my rules are not functioning at all.

Best Regards

kc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Firewall-troubleshooting

[Daniel Pittman]

On 3 Jul 2005, KC wrote:
> Daniel Pittman wrote:
>> On 3 Jul 2005, KC wrote:
>>
>>> I need help understanding what goes wrong in this script. I cannot ping
>>> anyone and cannot resolve as well. In fact I believe the only thing I can
>>> get is an ip address from my isp's dhcp server.

[...]

>> I can't spot anything wrong with your script, which means that it isn't
>> an obvious stupid mistake (congratulations ;).  You have some work to
>> do, I guess. :)

[...]

>> Finally, that is a pretty complex firewall script, and obviously
>> somewhat hard to maintain.  Maybe you would get better value for your
>> time by using an existing firewall helper like 'firehol', or something,
>> than re-doing the work that went into the existing tools?
>>
>> Of course, if your aim is to learn iptables rather than just get it
>> working, that loses. ;)
>
> Yes the script is kind of long and tedious in its respects. 

Well, a decent firewall is when you express it in iptables -- the
assembly language of firewalls. ;)

[...]

> I am trying to block out everything accept what i need. 

That is a good policy.

> I think that my firewall optimization is kind of crap but I am in
> process of working on that. The other thing that I just noticed is
> that my order for rules is not very properly laid out. I should have
> had the most active rules up ontop right before all the drop rules. 

So-so.  On most of the systems that people use for firewalling these
days, the performance cost of the various tests is next to invisible,
because the machines are grossly overpowered.

For example, the smallest thing I look after that does firewalling is my
P3-550 at home, which replaced a Pentium-233, both of which could have
handled vastly more firewall rules than I ever had, despite a much more
complex setup than your script manages.

So, unless you actually notice a performance problem you are probably
wasting your time trying to "micro-optimize" your firewall that way, in
my opinion. 

[...]

> I tried some automated firewall scripting programs, and just feel that
> a lot of them are just designed to save time for the lazy, and then
> you waste a lot of time trying to correct the script. 

Sure, a lot of them suck.  In fact, most of them *really* suck, in my
opinion.  

I found that 'firehol' was quite a surprise to me -- not only didn't it
suck, it actually improved my hand-written firewall somewhat.  

Unlike everything else, it doesn't tell you to fill in three values in a
configuration file and expect to have a full firewall.  All it does is
help take the tedious bits out of writing an iptables firewall.

You can also use, well, anything iptables-ish if you want.  I would
suggest giving it a whirl at some point, just because it doesn't suck
the same way all the other tools do.

> These programs have their users I am just not one of them. I have also
> learned that iptables have some very interesting and helpful modules.
> If someone knows anything about that, then I would appreciate if they
> let me know where I could get them.

Well, if you want the latest patch-o-matic stuff, netfilter.org will
help you.  If you have specific questions, just ask. :)

 Daniel

-- 
...I've seen things you people wouldn't believe. Sun monitors on fire off the
side of the multimedia lab. I've seen NTU lights glitter in the dark near the
Mail Gate. All these things will be lost in time, like the root partition last
week. Time to die...
-- Peter Gutmann, _alt.sysadmin.recovery_


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Firewall-troubleshooting

[KC]

Hi,

Yes the script is kind of long and tedious in its respects. My initial
purpose was to set this up at a remote facility with around 20 systems. I
have also tried to get info from iptables -L chian, but noticed that the
rules seem to be ok. If people want I can put the output for iptables -L
chain. I am trying to block out everything accept what i need. I think that
my firewall optimization is kind of crap but I am in process of working on
that. The other thing that I just noticed is that my order for rules is not
very properly laid out. I should have had the most active rules up ontop
right before all the drop rules. I am asking for help if anyone notices
anything interesting or decides to just suggest a more optimized approach
to things let me know. I tried some automated firewall scripting programs,
and just feel that a lot of them are just designed to save time for the
lazy, and then you waste a lot of time trying to correct the script. These
programs have their users I am just not one of them. I have also learned
that iptables have some very interesting and helpful modules. If someone
knows anything about that, then I would appreciate if they let me know
where I could get them.

Best Regards

kc

Daniel Pittman wrote:
> On 3 Jul 2005, KC wrote:
> 
>>I need help understanding what goes wrong in this script. I cannot ping
>>anyone and cannot resolve as well. In fact I believe the only thing I can
>>get is an ip address from my isp's dhcp server.
> 
> 
> With sufficiently modern kernels, the DHCP client uses raw sockets, so
> it can (AIUI) bypass firewall rules that would otherwise stop it getting
> through.
> 
> I can't spot anything wrong with your script, which means that it isn't
> an obvious stupid mistake (congratulations ;).  You have some work to
> do, I guess. :)
> 
> Two things that are generally helpful in debugging iptables/firewall
> problems:
> 
> The logs of dropped packets, which I note you have added, may show you
> where things are getting discarded.  A *default* log at the end, showing
> everything else, is also really helpful. 
> 
> Watching the output of 'iptables -L' will show you where packets are
> flowing:  each time they pass a rule, or chain, they bump up the packet
> count.
> 
> This can show that, say, one of your rules is eating all the packets --
> they get that far, then stop. 
> 
> 
> Finally, that is a pretty complex firewall script, and obviously
> somewhat hard to maintain.  Maybe you would get better value for your
> time by using an existing firewall helper like 'firehol', or something,
> than re-doing the work that went into the existing tools?
> 
> Of course, if your aim is to learn iptables rather than just get it
> working, that loses. ;)
> 
>  Daniel
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Firewall-troubleshooting

[Daniel Pittman]

On 3 Jul 2005, Steve Kemp wrote:
> On Sat, Jul 02, 2005 at 04:46:29PM -0400, KC wrote:

[...]

> One thing did stand out though, you don't allow outgoing connections
> generally.  These lines:
>
>> iptables --policy OUTPUT DROP
>> iptables -t nat --policy OUTPUT DROP
>> iptables -t mangle --policy OUTPUT DROP
>
> They seem to say "no output except that which is explictly allowed".
>
> For a big network I too would restrict outgoing connections, but for
> a home machine with only trusted hosts? It's an additional complication
> which doesn't gain you much.
>
> (Sure if you had a trojan which phoned home, or tried to compromise
> other hosts .. it would help.  But .. in general it less useful than
> it appears).

...you mean, like every one of the increasingly popular remote control
trojans that infest Windows machines?

Alternately, the variety of IRC remote-controlled things that get
installed after some automated exploit of a hole in your Linux/Unix
machines?

Believe me, you *do* benefit from having this sort of protection for
small home network -- in some cases, *more* than you do for large
organisations, since they often have rules to stop people doing (too
much) stupid stuff...

  Daniel

-- 
Nothing is more beautiful than the loveliness of the woods before sunrise.
-- George Washington Carver


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Firewall-troubleshooting

[Daniel Pittman]

On 3 Jul 2005, KC wrote:
> I need help understanding what goes wrong in this script. I cannot ping
> anyone and cannot resolve as well. In fact I believe the only thing I can
> get is an ip address from my isp's dhcp server.

With sufficiently modern kernels, the DHCP client uses raw sockets, so
it can (AIUI) bypass firewall rules that would otherwise stop it getting
through.

I can't spot anything wrong with your script, which means that it isn't
an obvious stupid mistake (congratulations ;).  You have some work to
do, I guess. :)

Two things that are generally helpful in debugging iptables/firewall
problems:

The logs of dropped packets, which I note you have added, may show you
where things are getting discarded.  A *default* log at the end, showing
everything else, is also really helpful. 

Watching the output of 'iptables -L' will show you where packets are
flowing:  each time they pass a rule, or chain, they bump up the packet
count.

This can show that, say, one of your rules is eating all the packets --
they get that far, then stop. 


Finally, that is a pretty complex firewall script, and obviously
somewhat hard to maintain.  Maybe you would get better value for your
time by using an existing firewall helper like 'firehol', or something,
than re-doing the work that went into the existing tools?

Of course, if your aim is to learn iptables rather than just get it
working, that loses. ;)

 Daniel

-- 
A cathedral, a wave of a storm, a dancer's leap,
never turn out to be as high as we had hoped.
-- Marcel Proust


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Firewall-troubleshooting

[Steve Kemp]

On Sat, Jul 02, 2005 at 04:46:29PM -0400, KC wrote:

> I need help understanding what goes wrong in this script. I cannot ping
> anyone and cannot resolve as well. In fact I believe the only thing I can
> get is an ip address from my isp's dhcp server.

  There's no way I'm going to read through all of that and try to 
 understand it.

  Perhaps you'd be better off starting with a smaller firewall script
 and then adding to it as you need?

  One thing did stand out though, you don't allow outgoing connections
 generally.  These lines:

> iptables --policy OUTPUT DROP
> iptables -t nat --policy OUTPUT DROP
> iptables -t mangle --policy OUTPUT DROP

  They seem to say "no output except that which is explictly allowed".

  For a big network I too would restrict outgoing connections, but for
 a home machine with only trusted hosts?  It's an additional complication
 which doesn't gain you much.

  (Sure if you had a trojan which phoned home, or tried to compromise
 other hosts .. it would help.  But .. in general it less useful than
 it appears).

Steve
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Firewall-troubleshooting

[KC]

Hi

I need help understanding what goes wrong in this script. I cannot ping
anyone and cannot resolve as well. In fact I believe the only thing I can
get is an ip address from my isp's dhcp server.

Best Regards

kc

## FIREWALL ##

## Symbolic Constants

CONNECTION_TRACKING="1"
LOCAL="eth0"
INTERNET="eth1"
LOOPBACK_INTERFACE="lo"
MY_ISP="24.0.0.0/8"
LOOPBACK="127.0.0.0/8"
IPADDR=`ifconfig eth1|awk '/inet/{print $2}'|awk -F ':' '{print $2}'`
INTERNAL_IP=`ifconfig eth0|awk '/inet/{print $2}'|awk -F ':' '{print $2}'`
LOCAL_NET="192.168.3.0/24"
BROADCAST_SRC="0.0.0.0"
BROADCAST_DEST="255.255.255.255"
PRIVPORTS="0:1023"
UNPRIVPORTS="1024:65535"
SUBNET_BASE="192.168.3.0"
SUBNET_BROADCAST="192.168.3.255"

## Hosts
DESKTOP="host2"
DESKTOP2="host"
WWW="host3"
#MAIL="192.168.2.5"
#IRC="192.168.2.40"
#IMAP_CLIENTS="continued... "
TIME_SERVER="time.server.address"
HOSTS_PING="isp subnet"
NAMESERVER="nameserver1"
DHCP_SERVER="dhcp-server1"

## PORTS
IRC_PORT="6667"
WEB_PORT="80"
SSL_PORT="443"
SSH_PORTS="445"
DK_PORT="4660"
XWINDOW_PORTS="6000:6063"
TRACEROUTE_SRC_PORTS="32769:65535"
TRACEROUTE_DEST_PORTS="33434:33523"
## Private Class Networks

CLASS_A="10.0.0.0/8"
CLASS_B="172.16.0.0/12"
CLASS_C="192.168.0.0/16"
CLASS_D_MULTICAST="224.0.0.0/4"
CLASS_E_RESERVED_NET="240.0.0.0/5"

## Flush the chains of all rules

iptables --flush
iptables -t nat --flush
iptables -t mangle --flush
echo "Flushed rules for all chains"

## Show Internal and External Addresses and enable forwarding

echo "External IP " $IPADDR
echo "Internal IP " $INTERNAL_IP
#echo "1" > /proc/sys/net/ipv4/ip_forward

## Enable broadcast echo Protection

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

## Disable Source Routed Packets

for p in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 > $p
done

## Enable TCP SYN Cookie Protection

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

## Disable ICMP Redirect Acceptance
# A redirect message SHOULD be silently discarded if the new gateway
address it specifies is not on the same subnet that it came from.

for p in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo 0 > $p
done

## Don't send redirect Messages

for p in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo 0 > $p
done

## Drop Spoofed Packets coming in on an interface, to which a reply would
result in going out a different interface.

for p in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $p
done

## Log packets with impossible addresses.

for p in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 1 > $p
done

## Unlimited traffic on the loopback interface

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# POLICY #

## Default Policy

iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

iptables -t nat --policy PREROUTING DROP
iptables -t nat --policy OUTPUT DROP
iptables -t nat --policy POSTROUTING DROP
iptables -t mangle --policy PREROUTING DROP
iptables -t mangle --policy OUTPUT DROP
iptables --delete-chain
iptables -t nat --delete-chain
iptables -t mangle --delete-chain

# DNS

iptables -A OUTPUT -o $INTERNET -p udp -s $IPADDR --sport $UNPRIVPORTS -d
$NAMESERVER --dport 53 -j ACCEPT

iptables -A INPUT -i $INTERNET -p udp -s $NAMESERVER --sport 53 -d $IPADDR
--dport $UNPRIVPORTS -j ACCEPT

iptables -A OUTPUT -o $INTERNET -tcp -s $IPADDR --sport $UNPRIVPORTS -d
$NAMESERVER --dport 53 -j ACCEPT

iptables -A INPUT -i $INTERNET -p tcp ! --syn -s $NAMESERVER --sport 53 -d
$IPADDR --dport $UNPRIVPORTS -j ACCEPT

iptables -A OUTPUT -o $INTERNET -p udp -s $IPADDR --sport 53 -d $NAMESERVER
--dport 53 -j ACCEPT

iptables -A INPUT -i $INTERNET -p udp -s $NAMESERVER --sport 53 -d $IPADDR
--dport 53 -j ACCEPT



### STEALTH SCAN POLICY ###

# All of the bits are cleared

iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# SYN and FIN are both set

iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

# SYN and RST are both set

iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# FIN and RST are both set

iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP

# FIN is the only bit set, without the expected accompanying ACK

iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP

# PSH is the only bit set, without the expected accompanying ACK

iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP

# URG is the only bit set, without the expected accompanying ACK

iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

## Refuse packets from the following ban list
## example
iptables -I INPUT -i $INTERNET -s 72.21.42.186 -j DROP
#iptables -I INPUT -i $INTERNET -s address/mask -j DROP

## Packet State Validation

if [ "$CONNECTION_TRACKING" = "1" ]; then
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID
input: "
iptables -A IN