Matt:
That's an interesting firewall log. Two quick questions
spring to mind:
1. The source-IP is 192.0.1.11, the dest is 192.0.1.7, but this
is coming in on the eth0 interface of your firewall. So...
how does your LEAF firewall connected to your WinXP box?
I'm presuming that
Tony:
Heya. Yes, the 10.x.y.z private IP address range is blocked
by the default firewall script that comes with Dachstein. You may
want to try echowall.lrp which I built for Dachstein which doesn't
do this. I had the same trouble with the standard Dachstein ruleset,
and before long I had
Eyal:
Heya. The problem adding some ACCEPT rules to allow
one address to work, though, is that these rules must be
inserted into the ipchains input chain *before* the rule
which DENY's the whole range. Else the packet will be dropped
before it gets to the forward chain.
Me, I'm
:
Aanhalen Scott C. Best [EMAIL PROTECTED]:
Just gambling here but couldn't a packet coming from the inside
with an echo request or (probably any data destined for 0.0.0.0)
provoke this kind off response?
A capture of network traffic should help you out if that is
the case.
Kim Oppalfens
PS
Michael:
Heya. Sorry about that. Paraphrasing a famous beagle,
a ScriptAlias bug in your httpd.conf always appears when you're
in the shower on vacation. :)
Service is up again. Sorry for the delays...
-Scott
PS: These are some strange logs you're seeing. :) I believe
Stewart:
Heya. Unfortunately, you've chosen a difficult application
to start with: FTP is notoriously difficult to get working behind
a NAT'ing firewall. Here's a PDF which explains why:
ftp://ftp.echogent.com/docs/FTP_and_Firewalls.pdf
As you can see, active FTP requires more
Jabez:
Heya. So you know up-front: I've not installed LaBrea
on my systems here. I like the idea of it, of course, but
haven't done anything about it.
That being said, here's what I see below. Now that
you've opened port-80, it looks like your sh-httpd process
(which I believe
Jabez:
Heya. As you probably know, that log looks like a
CodeRed worm (an IIS web-server virus from early last year).
It also looks like your firewall is simply blocking this
packet before any other process can see it, including LaBrea.
This seems to me a Good Thing. :)
-Scott
I just
Tony:
Heya. Sorry for chiming in late, I had a busy weekend. :)
I believe the information about ipmasqadm bypassing ipchains is
incorrect. I've always known it to be described as:
http://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html
Some nice ascii art there. Quoting from the
Morgan:
Heya. I think you're doing two things incorrectly. First,
you're using iphains -A input ... which means to Append the rule
at the end of the input chain. So, it may be appendning it after
rule #41 which is blocking it. You need either use -I to Insert
the rule earlier in the
Mike:
Heya. Some thoughts on what you're seeing:
Apr 18 15:44:50 firewall kernel: Packet log: input DENY eth0 PROTO=17
66.147.147.152:520 66.147.147.255:520 L=52 S=0x00 I=64309 F=0x
T=128(#40)
These are UDP packets being broadcast to port 520 on all devices
on your
Dustin:
Heya. Just a quick check to see if you've told your
firewall to allow those protocol=47 packets to come through.
You got the TCP port=1723 ones for PPTP right, but there's
two pieces to it.
-Scott
Hello,
I am attempting to replace a 2.9.4 based firewall with Dachstein.
eth0
vpnserverip externalip n/a
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott C. Best
Sent: Friday, April 12, 2002 2:30 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Leaf-user] VPN behind Dachstein
Dustin
DJ:
I've updated the advice.txt file at:
www.echogent.com/cgi-bin/fwlog.pl
...so that it correctly reports on these packets that you're
seeing. Quick answer: it's a terribly sloppy type of load-balancing,
not a DNS attack. If the SYN flag were set, I'd be much more
Paul:
Heya. This looks to me like a DHCP reply as well (checkout
http://www.echogent.com/cgi-bin/fwlog.pl to see). I think RFC-1542
indicates that port-68 is where DHCP (aka, BOOTP) replies must sent
*to*, and DHCP servers send them from port 67. Though I bet elsewhere
in your logs, you
Greg:
Heya. A quick comment or two to your recent post:
Is there a significant performance penalty when using a Celeron or
Duron processor vs an Athlon or Pentium. Not just in speed but in in
the ability to process.
This is a really broad question. It all depends on what you
Brian:
Heya. One caveat to Charles' reply that may be entirely
obvious already: you need to have an SSH account on one of the
machines in the remote system in order to setup such a tunnel. So
you can use this method to, say, securely tunnel web access to
weblet running on your LEAF box.
Some quick feedback to the security-conscious hyperbole
about VNC that's flown across the list recently. In my experience,
it's not exactly true that VNC has very little in the way of
security. Some features it has (and I've used):
1. Via AuthHosts, you can specify which IP addresses
as well, of course, unless they have good,
built-in encryption. Generally, I think even most sysadmins are too trusting
... but then, I always thought Fox Mulder was too trusting of the
cigarette-smoking man too).
At 09:26 PM 3/21/02 +, Scott C. Best wrote:
Some quick feedback
Morgan:
Hello! Have a look here:
http://www.echogent.com/cgi-bin/fwlog.pl
The IGMP packet you're seeing is coming from your ISP's
router, as it's trying to find other routers directly connected to
it. As the firewall log explanation script says, you can safely
ignore
winnt.private.network winnt
I can see my WinNT Box (at .2) query the DS box
for a reverse-lookup (PTR?) for 1.123.168.192, and I cannot
see that the DH box replying with pc.private.network.
Hope this helps clarify.
-Scott
On Sat, 9 Mar 2002, Michael D. Schleif wrote:
Scott C. Best
Boyd:
As Charles says, the docs on www.phoneboy.com/faq/0372.html
suggest this is a lot like an IPSec connection. You may want to have
a look at echoWall again, though: it supports both FW1 and IPSEC.
You can enable or disable either of them, see what works.
-Scott
One guy behind my
Lonnie, Boyd:
Ah, serendipity. :) One email, two answers...
To get a PPTP-based VPN client working from behind a
LEAF/LRP disk, you need to do four things (none of which is
to search the email archives, though that works too ;):
1. Be sure to be using a VPN enabled kernel.
Lonnie:
You can best find echoWall on freshmeat.net. The blurb
there is fairly accurate. :)
http://freshmeat.net/projects/echowall/
cheers,
Scott
On Mon, 4 Mar 2002, Lonnie Cumberland wrote:
Thanks Scott,
I think that I will now proceed to upgrade my old EigerStein LRP to
the
Matt:
Heya. Thanks for the candid feedback. Some replies
to you inline, with gratuitous clipping:
Let me first say that I like echowall and what you've done with.
I've said that before and recommended it to others even though I've
authored my own pfw. Yours is better, more
Scott:
What you type looks correct to my eye. What does your
PPTP client think of it? :)
-Scott
On Tue, 26 Feb 2002, Scott Ecker wrote:
I looked at echowall.lrp and from it I gathered that I should add the rules:
$IPCH -A input -s 0/0 -d 207.202.240.236/32 1723 -p tcp -l -j ACCEPT
Brian:
Heya. not sure if you knew, but there are 2 or 3 other
steps to getting an IPSec VPN client working from behind a
Dachstein firewall/router. Just holler if you'd like the gory
details.
As for the firewall rules...what you write is close,
but a bit off. Have a look in the
Lonnie:
Heya. Here's what I put into the SMB section of the
echowall ruleset:
#SMB#$IPCHAINS -A input -s 0/0 -d $IP_EXT/32 135 -p tcp -j ACCEPT
#SMB#$IPCHAINS -A input -s 0/0 -d $IP_EXT/32 137:139 -p udp -j ACCEPT
#SMB#$IPCHAINS -A input -s 0/0 -d $IP_EXT/32 139 -p tcp -j ACCEPT
Scott:
Heya. Yes, you can port-forward a PPTP VPN connection pretty
easily thru a Dachstein firewall. It comes with a VPN enabled kernel,
so all you'll need to do is to uncomment the pptp masq module in
/etc/modules (the line which reads ip_masq_pptp), and tweak your
firewall rules.
Dave:
Heya. Give the echowall.lrp package a try. It's got a
more aggressive don't log this sort of noise section to it
than the stock firewall that comes with Dachstein does.
EchoWall was built for Dachstein, so it should sneak
in nicely. The README has all the details of
Mike:
Heya. Nope, nothing's wrong with your setup; you're
not seeing a bug. You really are seeing all of these deny'd
packets. Someone on your cable subnet may be trying to
crush you with noise, or someone from anywhere on the planet
may have taken interest in your ISP's cable system. No
Stephen:
Heya. Presuming that you're using one of the Dachstein
versions, you need to do 3 things to get passthru IPSec
masquerading to work:
1. As Charles said, you need to open UDP-500 and protocol (not
port) 50.
2. You need to uncomment the ip_masq_ipsec line in /etc/modules,
Julian:
Hello again! Wow, you have some interesting log files. :)
I keep getting connection attempts on tcp port 21 from this particular
IP address. I'm pretty sure this is someone trying to connect to an
FTP server on my network. Incidentally, there are no FTP servers on my
LAN.
Greg:
Heya. I know how you feel about being reluctant to touch
your firewall now that it's running. Fortunately...it's not as
bad as you might remember -- I had to get Dachstein up and running
so that I could get echoWall debugged on it. Since Charles did
both distro's, they lookfeel
Julian:
Heya. I'm going to go with what fwlog.pl is telling
you on this one. :) The reply does indeed look to be from the
NAT router you had previously at 192.168.254.254. There's
no SYN flag set, so it's not a Code-Red packet, and it's
coming at you at a very high port number (61000+)
Jim:
Heya. Sorry for the late reply; didn't get to my
mailing list email this weekend.
Yes, echoWall supports both IPSec and PPTP VPNs,
either in passthru mode or as VPON endpoints. See the
.conf file that comes with the echowall.lrp for an example
of IPSec passthrough. To make
.
Good luck!
-Scott
On Mon, 14 Jan 2002, Scott C. Best wrote:
Eric:
Heya. My wife connects to her corporate VPN server in very
much the same way. Yes, it's true: I keep echoWall well-maintained
because she makes me. :)
Give echowall.lrp a try. I do not think you need
Ed:
Heya. The 3D's in what you wrote threw me. Ah, the
horror of HTML email. :)
Try this: head to www.echogent.com/cgi-bin/fwlog.pl
and plug in the packet you're seeing:
Jan 14 01:00:32 firewall kernel: Packet log: input DENY eth0 PROTO=1
192.168.101.1:0 24.138.23.131:0 L=84
Joe:
Heya. Not to tout too much in the same day, but you
should give echoWall a try. :) It has a more aggressive don't
log this junk section than the stock firewall that comes
with EigerStein. It also has support for IPSec of course.
If you can't upgrade due to your production
Jim:
Heya. Your captured packet looks to be a syslog packet
that some firewalls can be setup to broadcast. That is, when
a PIX (for example) firewall sees an event that worries it,
it can log the event and then broadcast to a syslog collector
like the one from Kiwi Software
Wyatt:
Heya. Interesting question. I think the best way to
compare and contrast the different firewall-setup packages
is to ask the authors what their intent was for providing it.
I know I built echoWall with a target user in mind, and
if you're the target user, and you're not
Heya sport fans. Sorry for the delay...took a
few days off grieving the loss of my first floppy. :)
Echowall is now rev'd to 1.40, and the old
problems with 1.33's use of cut has been fixed.
It also fixes the problem of killing off all copies
(and not just one) of ipfwd in the
Jan:
Some interesting packets there in your logs; I've
a better idea now of what @Home is like in the Netherlands. :)
Please give the echowall.lrp package a try. It
logs a lot less of this noise by default. It works fine on
the Dachstein images.
Also, gives this a try:
Paul:
Heya. Notso left field, really. I've used ipfwd to
forward IPSec packets (protocol 50 and 51) to my NAT'd LAN's
broadcast address...and IPSec clients on that LAN can handle
it.
Of course...IPSec has some sense of state of a
connection beyond just the packets. Webservers
John:
Heya. Regarding your firewall troubles, might I suggest
that you please give the echowall.lrp package a try, available
at ftp.echogent.com. It's expressly designed towards making an
Eiger/Dach firewall with port-forwarding as easy as possible to
setup.
In other words, it's
Richard:
Heya. I'll update the fwlog.pl processor at echogent.com
so that it offers some advice about packets like these.
Charles' advice about how to handle them is good, but
I don't think it goes far enough. Here's the reduce my log
noise from the echowall.rules file. Please
224.0.0.0/4 -j DENY
$IPCHAINS -A input -i $IF_EXT -b -s 240.0.0.0/5 -j DENY
$IPCHAINS -A input -i $IF_EXT -b -s 248.0.0.0/5 -j DENY
On Sat, 1 Dec 2001, Michael D. Schleif wrote:
Scott C. Best wrote:
Heya. Thanks for the packet log, am updating fwlog.pl
to include an awareness
Lynn:
Heya. Late suggestion: try either the echowall.lrp package,
or cutpaste from the end of the echowall.rules file inside of
that package. I built echowall for a 486 with only 16M of RAM
that firewalled me from a cable-modem environment. As you prolly
know, I had to reboot every week
Michael:
Heya. Thanks for the packet log, am updating fwlog.pl
to include an awareness of protocol 88. It knew about regular
IGRP (IP protocol 9) but not this one. :)
Regarding silent deny's...you can block the whole
224.0.0.0/4 range (RFC-1112 Class-D multicast) without worry.
Scott:
Heya. Sorry for the late reply; I hadn't yet seen
one to your post, so I thought I'd chime in:
Is there a way to prevent logging of certain events? Someone on my subnet
is requesting DHCP packets constantly and it's filling up my logs quickly.
Is it possible to still deny the
David:
Heya. You need to use the ipfwd utility to forward
arbitrary IP protocols, like the ones associated with VPN'ing.
I'm pretty sure it's still included by default on the Dachstein
images. You can peek in the IPSEC portion of the echowall.rules
file in the echowall.lrp package for
Paul:
Heya. Keep in mind that every port-forwarding rule
requires an associated rule which opens the hole in the
firewall in the first place. So you'll need a rule which
looks something like:
ipchains -A input -s 0/0 -d 123.234.123.234/32 80 -p tcp -j ACCEPT
Note that this rule
Don:
Heya. Easiest thing to do is grab the echowalll.lrp
package and setup your IPSEC_HOST as per the instructions in
the README.
To answer your questions...yes, Dachstein (and the others)
can masq and forward an IPSec connection much like any other
sorta connection *provided*
Kory:
Hello again. Quick suggestion:
Kory Krofft wrote:
All this talk about the weblet message logs has me wondering. My
firewall log states that since yesterday I have almost 3000 denied or
rejected packets. I included a sample of the log entries below. Can
someone please
Robert:
Heya. In general...an open port on your firewall is
not really a security problem *if* there's no service actually
listening to that port. So, is Dachstein actually running a
service that's listening to UDP port-9?
Secondly, AFAIK, the default firewall rules for
on this one. :)
Hope it proves useful! Feedback welcome.
cheers,
Scott
On Sun, 4 Nov 2001, Scott C. Best wrote:
Kory:
Well, how 'bout that. These lines are causing the
trouble in Dachstein:
$IPCHAINS -A input -i !lo -s 127.0.0.0/8 -j DENY
$IPCHAINS -A input -i !lo -d
Kory:
Heya. Interesting error; I've not run echoWall on a
Dachstein kernel yet, but I'm surprised it wouldn't slip right
in. Huh.
The weird character warnings appear to be generated
by these two lines in echowall.rules:
$IPCHAINS -A input -i !lo -s 127.0.0.0/8 -j DENY
$IPCHAINS
David:
Heya. What Todd said is pretty much my understanding as
well; NetMeeting is a disaster of a protocol in so far as how
it interacts with NAT'ing firewalls. In addition to all of the
problems Todd mentioned, I believe that the source-IP of a
NetMeeting client is embedded within the
Jason:
Heya. I hadn't seen a reply to your post yet, probably
because your question was a bit scary. :) Asking how to open
40,000 UDP ports on a LEAF list would be like asking how can
I be sure to poison myself? on a medical self-help list. :)
Anyhow. Presuming you meant to open
Mark:
Hope your HL problems are getting better. Two quick
thoughts:
Thanks for the replies...I believe the problem lies in the CStrike
server config, since this is where the 169.254.0.0 address shows up.
When try to run a server on another machine without a WAN adapter...it
shows as
Mark:
Okay, so the server allocates the correct IP address,
that's a start. Can I ask though: from the LEAF firewall box,
can you ping this 192.0.0.0 machine successfully? Perhaps you
just meant that IP address as an example, but perhaps not.
Also, importantly, type this after
Mark:
Heya. This sounds like it's either an interface problem,
or a problem with the CounterStrike server setup. In echowall.conf,
did you choose ppp0 or eth0 for IF_EXT? For PPPoE, I believe
it should be the first one.
The 169.254.0.0/16 address you speak about is actually
what
Vance:
Hard to say. Obviously, you can connect multiple clients to
a VPN server if it's only one at a time: just switch the settings to
show who should be connected, and re-start.
But I suspect you're asking about doing it simultaneously.
This is tricky. In fact, I suspect it's
Kevin:
Heya. Sorry for the late reply: as you can see in the
archives, there was a big discussion regarding unsolicited TCP
packets to port 53. Intentionally misconfigured packets, too,
ones set with both the SYN and ACK flags, as if your firewall
tried to initiate a connection. Your
Rob:
Heya. Glad to here the multicast rules flew. Regarding
echowall and ES2B playing nicely together, I built echowall
on and for that system specifically. So, when it installs
itself, it gently brushes aside the default firewall of ES2B
and puts itself in place instead. When/if you
Alan:
Heya. So...from looking over Intelispan's website,
it looks as if their Secure VPN Service is an IPsec one.
In order to have your LRP box support a VPN client, you'll
need to be using a VPN-enabled kernel. Fortunately, that's
not all that hard to do:
1. Got to Charles' site at:
Rob:
Heya. Some quick answers (am posting this on-list, as
you suggested)
1. Actually, echowall is the one doing more filtering, not less. Charles'
default script lets many of the broadcast-noise stuff go thru to the
end, where it gets logged by the last catch and log everything that
Chris:
Heya. As Ray said in an earlier mail, the idea of
using MACID's to specify the server is so that you can
give the server its IP address however you want: statically
or dynamically.
If you have services that move box to box, you'd
need to re-initialize echowall after the
Chris:
Hello again...
I am trying to get echowall running on an Eigerstein 2BETA day
5/27/01. So far, this is what I have done:
1. Got echowall.lrp on my disk
2. Added echowall to Syslinux.cfg
3. Executed ./echowall install from its directory and rebooted
I gotta work
Phew, busy day. One real bug found in echowall,
now fixed. Also, MSoft updated their DirectX from version
7 to version 8, and the new version (gasp) doesn't use
all of the same ports as the others. I know, I was
terribly shocked myself. Almost fell down.
So, version 1.22 of
Heyaz. Just posted version 1.1 of echowall.lrp
in all the usual places. Some bug fixes to the now-tested
PPTP and IPSec pieces, as well as added support for
Battlenet and Firewall-1 VPN'ing.
Hope it proves useful!
cheers,
Scott
http://leaf.sourceforge.net/devel/sbest/echowall
Phil:
Heya. Have a look here:
http://lrp1.steinkuehler.net/files/kernels/2.2.16-1-VPNMasq/
Download one of those kernels, have it be the linux
file on your floppy.
In the ./modules directory there, get the modules
for your NIC in the NET subdirectory, and then get
72 matches
Mail list logo
