All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: intermittent and unreliable behaviour with iptables scripts
@ 2002-11-13 15:01 Doug Watson
  2002-11-13 16:25 ` Trojaned tcpdump and libpcap James Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Doug Watson @ 2002-11-13 15:01 UTC (permalink / raw)
  To: 'netfilter@newkirk.us',
	'netfilter@lists.netfilter.org'

[-- Attachment #1: Type: text/plain, Size: 5788 bytes --]

Thanks for your input.

I unfortunately have had litte chance the last day or two to 
actually put to use the advise given by you and the others who
have sent me feedback due to MEETINGS! 

2 Things you seem to ofer several suggestions regarding reconfiguring
my iptables script that I will attempt to implement and evaluate. I 
may have some questions in a day or so when I attempt to do this.

Also you asked me if I had checked /proc/net/ip_conntrack. What should I be
looking for in ip_conntrack? One thing I did notice in ip_conntrack is
packets
with a destination of xxx.xxx.xxx.255. I believe this to be broadcast
traffic from
some of our workstations. We are working to track this down and stop it. 
What do you see as a possible impact of this broadcast traffic. I have yet
to see that
ip_conntrack has filled up.

Thank you,
Doug Watson
-----Original Message-----
From: Joel Newkirk [mailto:netfilter@newkirk.us]
Sent: Tuesday, November 12, 2002 1:31 AM
To: Doug Watson; 'netfilter@lists.netfilter.org'
Subject: Re: intermittent and unreliable behaviour with iptables scripts


On Monday 11 November 2002 12:25 pm, Doug Watson wrote:
> Fellow list users,
>
> I have been attempting to set up a new firewall for my company with the
> two goals of 1. implementing statefull packet filtering and 2.
> creating a DMZ for servers that need to be accessed by the
> outside world, such as HTTP, SMTP, DNS and FTP.
>
> There seems to be a lot to describe here so please stick with me.

OK, but I'm going to snip liberally... :^)

> When browsing the web, web pages that normally would load very quickly
seem
> to hang for an inconsistent amount of time, anywhere between 1 second to
30

> I will note that when the firewall is in the state that no web pages will
> load, pings to its LAN interface which usually return in about 1ms will
> time timeout, but I have not been able to link this to any specific
network

So the problem is probably occurring in PREROUTING or routing, since it hits

both forward and input packets. Try inserting in nat prerouting and filter 
forward and input:

$IPTABLES -t filter -I FORWARD 1 -i $LAN_IFACE -p ICMP -j LOG --log-level 
debug --log-prefix "IPT:SlowPingFront: "
$IPTABLES -t filter -I FORWARD 1 -o $LAN_IFACE -p ICMP -j LOG --log-level 
debug --log-prefix "IPT:SlowPingBack: "

Reproduce your problem and slow ping (-i 10 perhaps, -w 10000 from windows) 
from the lan to the firewall and beyond, and see what picture the log
paints.  
If the ping is just dying somewhere you can (hopefully) see it's trail.  If 
it's really slow (several seconds) you've hopefully narrowed it down to
WHERE 
it's slowing.

Check /proc/net/ip_conntrack, general memory issues, and top.

> Also overall speed of our connection seems to be noticeably slower when
> running through this firewall. One example be it a good one or not is
> when running the high speed bandwidth test at
http://www.bandwidthplace.com
> through the current firewall the average speed returned is between 1.0 and

> same test through the new iptables based firewall the average speed
> returned usually in the range of 600 to 800 Kbps.

This is quite possibly the same thing as above, just in a less intrusive
part 
of the cycle...  However, I had a few suggestions on your forward and 
bad_tcp_packets chains.

- disclaimer -
below is largely feng shui firewalling.  After a dozen readings of your 
firewall (cigarette breaks outside :^) it just didn't 'feel' right, and the 
changes below 'improve the flow' and 'feel right' often without any firm 
justification.  (along with some clarity and simplicity)  However, you DID 
ask for thoughts in general...
- /disclaimer -

Move the spoof tests from bad_tcp_packets to their own chain, or just move
the 
state tests directly to the start of forward and input.  (Do you need them 
for output?  You certainly don't need to test for -i $INET_IFACE in 
output...)  Call the spoof tests next, to catch both $LAN and $DMZ bound 
spoofs.

You currently accept EST/REL from $INET back to $DMZ, then have tests for
new 
connections on that route, then blanket EST/REL.  Make your unrestricted 
EST/REL rule next instead, followed by your $LAN accept rule, unless you
want 
to block otherwise valid EST/REL involving the DMZ, in which case the 
following two rules have to come before the EST/REL.  -i $LAN -o $DMZ ACCEPT

is redundant, picked up in the -i $LAN ACCEPT that follows in your current 
sequence, and EST/REL -i $INET -o $DMZ or -o $LAN are subsumed in the
blanket 
accept.

Follow this up with a jump for -o $DMZ_IFACE -j DMZin, then  -o $DMZ_IFACE
-j 
DMZout.  and move all appropriate rules to those chains.  Now you can treat 
DMZin almost like INPUT for the DMZ, and DMZout like OUTPUT, and keep all
DMZ 
rules separate from lan<->inet.  You can easily insert/remove a blanket 
accept/reject/drop/return target at the head, or add 'policy' at the end.  
All that these rules need to test now is protocol related, the other 3 
matches for each -i $INET rule are eliminated.  (unless you later use -d or 
-p to filter various DMZ forwards differently)  Also, if you have this
before 
your EST/REL then the DMZ chains should each get their own EST/REL at their 
end, before any 'policy' rule.

Finish out with your log rule.  Don't forget to change INPUT (and OUTPUT) to

reflect the removal of bad_tcp_packets, if you integrated the state rules.

Thus ends today's session of Feng Shui Firewalling.  :^)  The resulting
script 
is simpler and more easily modified than currently, and the process is 
simpler than the instructions.  As far as I see, it achieves the same 
filtering and forwarding as your current script with potentially far less 
rule tests per packet, but if I've missed something somebody please correct 
me.

j

[-- Attachment #2: Type: text/html, Size: 8804 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread
* RE: Trojaned tcpdump and libpcap
@ 2002-11-14  9:06 Wouter Coppens
  0 siblings, 0 replies; 4+ messages in thread
From: Wouter Coppens @ 2002-11-14  9:06 UTC (permalink / raw)
  To: netfilter

What are the actions to take when you're infected?

Is just getting a good version enough? Or do I have to remove some
files? 

According to the website it compiles a C-program. How can I remove this
program?

Regards,

Wouter 

-----Original Message-----
From: James Miller [mailto:jimm@simutronics.com] 
Sent: woensdag 13 november 2002 17:26
To: netfilter@lists.netfilter.org
Subject: Trojaned tcpdump and libpcap

Hello all

I have been a long time reader of this list.  An associate passed this
along
to me this morning and I wanted to share it with everyone.

http://hlug.fscker.com/
Latest libpcap & tcpdump sources from tcpdump.org contain a trojan.

Affected version are:
libpcap-0.7.1.tar.gz
tcpdump-3.6.2.tar.gz
tcpdump-3.7.1.tar.gz


Regards,
Jim







^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-11-14  9:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-13 15:01 intermittent and unreliable behaviour with iptables scripts Doug Watson
2002-11-13 16:25 ` Trojaned tcpdump and libpcap James Miller
2002-11-13 17:10   ` Michael H. Warfield
  -- strict thread matches above, loose matches on Subject: below --
2002-11-14  9:06 Wouter Coppens

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.