Send firewall-wizards mailing list submissions to
firewall-wizards@honor.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@honor.icsalabs.com
You can reach the person managing the list at
firewall-wizards-admin@honor.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Strange Pix behavior. (Jim MacLeod)
2. Re: Host based vs network firewall in datacenter (Alin-Adrian Anton)
3. Re: Password Recovery IP330 (Keith A. Glass)
4. RE: Strange Pix behavior. (Paul Melson)
5. RE: Password Recovery IP330 (Paul Melson)
6. Re: Ok, so now we have a firewall, we're safe, right? (Devdas Bhagat)
7. Re: Password Recovery IP330 (Jim MacLeod)
8. Re: Strange Pix behavior. (Jim MacLeod)
9. RE: Strange Pix behavior. (Paul Melson)
10. RE: so much for "deny all" (Kerry Thompson)
--__--__--
Message: 1
Date: Thu, 16 Jun 2005 01:00:20 -0700
From: Jim MacLeod <jmacleod@gmail.com>
To: Paul Melson <psmelson@comcast.net>
Cc: 'Firewall Wizards List' <firewall-wizards@honor.icsalabs.com>
Subject: Re: [fw-wiz] Strange Pix behavior.
Paul Melson wrote:
>If the firewall successfully deletes the state table entry before the remote
>server can send an RST+ACK (which is what you want, you don't want your
>firewall waiting for an untrusted system's predicted response before it
>revokes its access), that packet will be compared to the access-lists that
>allow traffic from the outside and if no match is found, it will be dropped
>and logged.
>
>
I'm not aware of any TCP implementation that will ACK a RST, since RST
indicates that the host has destroyed the connection. It's invalid to
ACK a RST, and would provoke yet another RST. That's one of the reasons
to use a FIN+RST, rather than a full FIN-ACK-FIN-ACK. Your explanation
also doesn't account for UDP, although typically a stateful firewall
will keep a running timer for UDP pseudo-sessions and remove the table
entries once the timer expires.
My first guess in cases like this - HA pair, replies dropped - has
historically been unintentional asymmetric routing, when the outbound
connection goes through one firewall, but the response returns through a
different one, and the RTT is less than the sync interval for the
firewalls. In that case, the inbound firewall would act as expected,
dropping a session for which is has no table entry. Granted, I haven't
seen this problem in quite a while, and even then it was primarily on
inbound connections.
I'd be interested in seeing if there's a correlation in the logs with
existing connections from the client to the server. Are these really
dropped responses, or is it attack traffic designed to mimic that
traffic pattern? Real dropped responses should have Accept messages to
the same servers from the same client IP around the same time. The fact
that the drop messages are in proportion to the outbound connections is
a good sign that it's not an attack.
>Your firewall is working just fine, or at least, it's working as it was
>designed to work. If you don't want to see it, I recommend using Kiwi or
>syslog-ng to remove these entries from the syslog stream before they reach
>your log analyzer.
>
>
I'd argue instead that this behavior is unusual, and furthermore that
blocking Deny log entries is a good way to ignore evidence of actual
attacks. Granted, there's a signal-to-noise ratio problem right now,
but that can easily be corrected by filtering on known protocols in the dst.
-Jim
--__--__--
Message: 2
Date: Thu, 16 Jun 2005 16:02:59 +0300
From: Alin-Adrian Anton <aanton@spintech.ro>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Host based vs network firewall in datacenter
Devdas Bhagat wrote:
> On 07/06/05 12:33 -0500, Zurek, Patrick wrote:
>
>>Hi all,
>>I graduated from university not long ago and assumed my first job as
>>network administrator in a small datacenter. I've been lurking here for
>>a while and reading the archives. I've learned a lot from what many of
>>you have had to say, but I'm having difficulty making the jump from the
>>theory behind the way things should be run (ie. the network design maps
>>that show the little switch, router & firewall symbols) and the practical
>>applications of that. I was also reluctant to make this post in fear
>>of getting flamed for having what will come across as a cluess attitude
>>about network security. Instead of flaming, please correct me, I want
>>to learn.
>
No matter what kind of network you have, you need at least one firewall
at the border with the Internet.
Having a datacenter without a fast firewall at the border, is simply insane.
The machine at the border can be some expensive hardware, like a cisco,
or can be a powerful BSD-based packet filter, sitting on powerful
hardware (the best you can get, Intel based).
If you chose cisco-like solution, chose an expensive one. You defenately
need it (because expensive ones can handle smarter ACLs and keep state
much better, and also can resist to DDoS over 100 Mbps. Cheap ones may die).
If you chose BSD solution use ipfw (fastest), or pf (best in terms of
what it can do). Pf on FreeBSD with Intel "FXP" cards is able to use the
hardware chip for checking CRC of the packets. This feature is only
available on FreeBSD, and as far as I know nobody ported it to other OS.
Having hardware to check for checksums greatly improves performance,
even over ipfw.
I would not chose a linux based solution for firewalling high loads of
evil traffic.
Even better, if you can afford it, you can have both: the cisco and the
BSD, cisco sitting maybe in front of the BSD. This way you also keep a
simple and good control of what goes in and what goes out, and you can
cut down packets which the hardware firewall missed (it happens).
In case of a serious DDoS problem, you can even enable statefull ACL
version (keep it somewhere) on the BSD box, to really cut down whatever
the hardware firewall skips into the internal network.
On the inside land, it may be a very good idea to use any kind of
firewall you want on each machine, in order to limit access to SNMP (if
you are going to monitor them via SNMP), and so on. You should use a
different switch for the monitoring connection, such that an internal
server cannot impersonate you in any way (arp, ISN prediction, etc).
Limit all services to what they really need to accept, and nothing else.
If they are not going to use the LAN, always bind them on the local
interface.
Each host inside the lan should not trust anyone from the LAN, so
writing down what is strictly needed for each of them is a good thing.
Implementing it is the next step, I just pointed some ideas.
Always consider an attacker is somewhere inside, and try to evoid
exposing any other machine to him.
Just my opinions.
Yours,
--
Alin-Adrian Anton
GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA)
gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA
"It is dangerous to be right when the government is wrong." - Voltaire
--__--__--
Message: 3
From: "Keith A. Glass" <salgak@speakeasy.net>
To: "Mark Sargent" <powderkeg@snow.email.ne.jp>,
firewall-wizards@honor.icsalabs.com
Date: Thu, 16 Jun 2005 13:22:09 +0000
Subject: Re: [fw-wiz] Password Recovery IP330
Here you go: it's easy, straighforward, and if your not careful, you may =
learn a bit of UNIX in the process:
****
The supported method is to boot the system into single-user mode and run =
/etc/overpw
If you are running IPSO 3.1.3 or earlier on a boot manager platform, (whi=
ch could only be an IP650 or IP330), overpw fails. Please ask for Interna=
l Resolution 1961 - How to remove config and password if overpw fails. (N=
ewer boot manager platforms require later versions of IPSO, for which ove=
rpw has been updated.)
If you are running IPSO 3.4.x, then you will be able to login as admin to=
the console without a password, but you will not be able to log into Net=
work Voyager. Therefore,
The use of overpw requires the use of the dbpasswd in order to set the Ne=
twork Voyager password to be the same as the login password.
Solution: You must have local serial console access to the unit to perfo=
rm this procedure.
Boot system into single user mode. To do this reboot or power cycle the m=
achine, When you see the line " boot: " you must enter "-s" before it goe=
s into multiuser mode. (you have about 10 seconds)
* on a ip330 or ip650 you need to type boot -s at the BOOTMGR prompt*
After it boots, it will ask you "Enter pathname of shell or RETURN for sh=
:", press Enter key.
Type "/etc/overpw" in the # prompt. It will ask if you want continue, typ=
e "y".
In IPSO 3.1.3 systems and earlier, it will ask you to put a floppy disk i=
nto the floppy drive to make sure you have physical access to the box. Pu=
t a floppy disk into the floppy drive and press Enter key. IPSO 3.1.4 and=
later does not ask this question.
In IPSO 3.4 and above, /etc/overpw will ask you to set a password. The ad=
min password defaults to no password in earlier versions of IPSO.
Continue to boot to multiuser mode.
Login as admin. If a password is required, you will be asked for one.
Use the dbpasswd command to set a new password:
nokia[admin]# dbpasswd admin newpassword ""
(Note that the "" is necessary to specify (NULL) as the old password.)
Then, save this new password to the configuration file so that you can lo=
g into Network Voyager:
nokia[admin]# dbset :save
*******************************************
--__--__--
Message: 4
From: "Paul Melson" <psmelson@comcast.net>
To: "'Jim MacLeod'" <jmacleod@gmail.com>
Cc: "'Firewall Wizards List'" <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Strange Pix behavior.
Date: Thu, 16 Jun 2005 09:25:27 -0400
I'm sorry. You're absolutely correct. It is not an RST+ACK, but rather a
FIN+ACK from the server in response to a FIN+ACK sent by the browser.
I would wager that if George looks through his logs, he is only seeing these
entries for TCP connections. The example he gave was specific to HTTP, so I
think this still applies.
As far as the normalcy of this behavior, I think that nearly any stateful
firewall that has multiple clients behind it experiences session state
mismatch, which these log messages are a symptom of. It's part of the
nature of stateful firewalls. I wouldn't suggest that anybody eliminate all
'drop' messages from their log stream, but if you know that any drop message
from [someaddr]:80 to [nataddr]:[>1023] is erroneous, why not keep it out of
your monitoring/analysis?
PaulM
-----Original Message-----
Subject: Re: [fw-wiz] Strange Pix behavior.
I'm not aware of any TCP implementation that will ACK a RST, since RST
indicates that the host has destroyed the connection. It's invalid to ACK a
RST, and would provoke yet another RST. That's one of the reasons to use a
FIN+RST, rather than a full FIN-ACK-FIN-ACK. Your explanation also doesn't
account for UDP, although typically a stateful firewall will keep a running
timer for UDP pseudo-sessions and remove the table entries once the timer
expires.
I'd argue instead that this behavior is unusual, and furthermore that
blocking Deny log entries is a good way to ignore evidence of actual
attacks. Granted, there's a signal-to-noise ratio problem right now, but
that can easily be corrected by filtering on known protocols in the dst.
-Jim
--__--__--
Message: 5
From: "Paul Melson" <pmelson@gmail.com>
To: "'Mark Sargent'" <powderkeg@snow.email.ne.jp>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Password Recovery IP330
Date: Thu, 16 Jun 2005 09:42:12 -0400
I read this and I'm like, "Man, I would swear I just answered this same
question on this list a month or two back." I was right. Turns out you
asked it. Here's the URL. Add it to your favorites.
http://honor.trusecure.com/pipermail/firewall-wizards/2005-April/018274.html
PaulM
-----Original Message-----
Subject: [fw-wiz] Password Recovery IP330
Hi All,
I'm able to access an IP330, but, can't access due to not knowing the
password. Can't find anything specific on the net for this. Anyone know how
to reset the password.? Cheers.
Mark Sargent.
--__--__--
Message: 6
Date: Thu, 16 Jun 2005 20:37:16 +0530
From: Devdas Bhagat <devdas@dvb.homelinux.org>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Ok, so now we have a firewall, we're safe, right?
Reply-To: Devdas Bhagat <devdas@dvb.homelinux.org>
On 10/06/05 12:57 -0500, Brian Loe wrote:
<snip>
> say, most people don't care so that's not likely to happen soon - so what?
> Why do you care? Protect yourself and be happy, right?
>
Because on a commons, your lack of security hurts me too.
Devdas Bhagat
--__--__--
Message: 7
Date: Thu, 16 Jun 2005 09:30:46 -0700
From: Jim MacLeod <jmacleod@gmail.com>
To: Mark Sargent <powderkeg@snow.email.ne.jp>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Password Recovery IP330
This is a fun one.
Connect the console cable (null modem, 5-pin, not 3-pin) and turn on the
IP330. Watch it as it boots: there's a 5 second window during which it
tells you to press a key to enter the bootmanager. Note that if you
don't see anything during pre-OS boot, you need to use a different
terminal emulator. Frustratingly, Hyperterm tends to work, whereas
"better" emulators don't.
Once you're in the boot manager, boot the OS in single user mode: "boot -s"
When you get a shell prompt, execute "/etc/overpw" to delete the
previous admin password. Now exit the shell (^-D, logout, exit, etc)
and the system will boot to multi-user mode, its normal operating state.
At this point, the recommended procedure is to access the system configs
via Voyager to set the new admin password. If you don't know the IP
address of the box, logging into it can be problematic, so logging in
via the command line and running "ifconfig -a" to get that information
is a good idea.
Note that simply setting the admin password from the command line via
the unix passwd command is insufficient, as the system config files are
dynamically generated at run time from Nokia's config database. You
will have to set the new admin password via Voyager to make it stick.
Enjoy.
-Jim
Mark Sargent wrote:
> Hi All,
>
> I'm able to access an IP330, but, can't access due to not knowing the
> password. Can't find anything specific on the net for this. Anyone
> know how to reset the password.? Cheers.
>
> Mark Sargent.
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>
--__--__--
Message: 8
Date: Thu, 16 Jun 2005 09:43:39 -0700
From: Jim MacLeod <jmacleod@gmail.com>
To: Paul Melson <psmelson@comcast.net>
Cc: 'Firewall Wizards List' <firewall-wizards@honor.icsalabs.com>
Subject: Re: [fw-wiz] Strange Pix behavior.
Paul Melson wrote:
>I'm sorry. You're absolutely correct. It is not an RST+ACK, but rather a
>FIN+ACK from the server in response to a FIN+ACK sent by the browser.
>
>
Hrm, that could explain why the other folks that have seen this problem
have fixed it with a code upgrade, if the PIX is purging the table entry
too soon.
>I would wager that if George looks through his logs, he is only seeing these
>entries for TCP connections. The example he gave was specific to HTTP, so I
>think this still applies.
>
>
The problem could be caused on UDP traffic with a session timer set too
short. Come to think of it, that could also cause the TCP session
errors. This assumes that these protocols have periods of time when
there's no data being transferred. If the remote server is heavily
loaded and not sending responses quickly, could that do it?
>As far as the normalcy of this behavior, I think that nearly any stateful
>firewall that has multiple clients behind it experiences session state
>mismatch, which these log messages are a symptom of. It's part of the
>nature of stateful firewalls.
>
Although your explanation makes sense, it doesn't explain why this
behavior is only observed on occasional firewalls, such as George's. It
definitely sounds like state mismatch, but I still think it's possible
the HA setup is part of the problem by causing delays in state table
updating at the beginning of the session.
>I wouldn't suggest that anybody eliminate all
>'drop' messages from their log stream, but if you know that any drop message
>from [someaddr]:80 to [nataddr]:[>1023] is erroneous, why not keep it out of
>your monitoring/analysis?
>
>
It's a good filter suggestion, but I personally prefer to include all
data in the monitoring and discard known oddities as part of the
analysis. Call it an additional debug level of paranoia. :-)
-Jim
--__--__--
Message: 9
From: "Paul Melson" <pmelson@gmail.com>
To: "'Jim MacLeod'" <jmacleod@gmail.com>
Cc: "'Firewall Wizards List'" <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Strange Pix behavior.
Date: Thu, 16 Jun 2005 14:43:43 -0400
> Hrm, that could explain why the other folks that have seen this problem
have fixed it with a code upgrade, if
> the PIX is purging the table entry too soon.
I've seen this behavior in several different products at several different
code levels. I'm sure I've seen it on a single PIX 515E as recently as
6.3(1). I've also seen it on Check Point R55, NetScreen ScreenOS 3.x (can't
remember the exact dot-version), and iptables.
> The problem could be caused on UDP traffic with a session timer set too
short. Come to think of it, that could
> also cause the TCP session errors. This assumes that these protocols have
periods of time when there's no data
> being transferred. If the remote server is heavily loaded and not sending
responses quickly, could that do it?
It could, but if it were a timeout issue, you'd expect to see it coming from
TCP protocols that have longer connection lives such as FTP or SSH. HTTP
is, for the most part, lots of connections in rapid succession transferring
relatively small quantities of data. Plus, I personally have never observed
this type of behavior involving UDP, only TCP.
> Although your explanation makes sense, it doesn't explain why this
behavior is only observed on occasional
> firewalls, such as George's. It definitely sounds like state mismatch,
but I still think it's possible the HA
> setup is part of the problem by causing delays in state table updating at
the beginning of the session.
That could be a factor, though I don't think George specified whether or not
the PIX's are actually synchronizing state tables, only that they were in a
failover configuration. Also, as I mentioned before, I have observed this
in a variety of firewalls, many of which were standalone systems.
I fear that there is a much more likely and less technical explanation for
why this behavior is not observed more often - most people don't read their
log files, at least not in their raw entirety.
PaulM
--__--__--
Message: 10
Date: Fri, 17 Jun 2005 10:22:09 +1200 (NZST)
Subject: RE: [fw-wiz] so much for "deny all"
From: "Kerry Thompson" <kez@crypt.gen.nz>
To: firewall-wizards@honor.icsalabs.com
Paul Melson said:
>[snip]
> I think it's much ado about nothing (both the panic and the hype). The
> real
> issue is the same issue that's been plaguing networks since the first
> "stateful" firewalls shipped to customers: it is easier to adopt a sloppy
> trust model than it is to discover, document, and enforce a strict traffic
> policy. Despite the obvious problems firewall vendors are ultimately
> just
> vendors. They must move units, and therefore their products have features
> that appeal to our lazy networks and lax policies.
Possibly what they are referring to is the multitude of applications which
tunnel traffic over innocuous ports. Almost anything can be tunnelled over
http/https now - just take a look at "firewall friendly" SSL-VPNs which
happily pass through proxies to connect an outside endpoint to the
internal desktop PC. Even fairly lame stuff like gotomypc.com is getting
harder to manage as it becomes more common.
So the firewalls now have to do "deep inspection" to try to pick out and
manage this crap being tunnelled, and the poor security administrator is
being forced to take a stance where he has to permit everything and make
some attempt to pick out the rubbish which is deeply hidden and probably
even encrypted.
Not surprisingly, plenty of vendors who sell the tunnelling technology (
like SSL VPNs ) now need to sell new firewalls which need "deep
inspection" to manage the tunnels.
Kerry
--
Kerry Thompson, CCNA CISSP
Information Systems Security Consultant
http://www.crypt.gen.nz
--__--__--
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest
No comments:
Post a Comment