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. Firewall Log Analysis - Computer vs. Human (Adrian Grigorof)
2. Re: SSH brute force attack (Marko Jakovljevic)
3. Re: Opinion: Worst interface ever. (Jan Tietze)
4. Cisco PIX Version 6.3(3) SMTP Problem (David M. Nicksic)
5. Re: RE: [fw-wiz] Opinion: Worst interface ever. (vbwilliams@neb.rr.com)
6. RE: Opinion: Worst interface ever. (Mark Teicher)
7. RE: Opinion: Worst interface ever. (Mark Teicher)
--__--__--
Message: 1
From: "Adrian Grigorof" <adi@grigorof.com>
To: <firewall-wizards@icsalabs.com>
Date: Tue, 5 Jul 2005 12:23:15 -0400
Subject: [fw-wiz] Firewall Log Analysis - Computer vs. Human
Hi all,
We are trying to develop a log analyzer that would "replicate" a human's
approach to log analysis - by that I mean the fact that a human can
correlate information in the log with other factors (like - "hmm, the log
says that the firewall was restarted at 12:03 PM"... oh, yeah, it was that
UPS failure yesterday around noon). For this particular example, the log
analyzer could say in the report: "12:03 PM - Firewall restarted - Possible
power failure, power disconnection or manual restart" - a bit vague I agree
but it is better than nothing - and in fact, this is what the firewall
admin would go through, right? Thinking, "Why would there be a restart? I
did not restart it.. anything happened at noon? The UPS failure!". Or for
example, instead of saying IP 123.123.123.123 was denied for protocol
TCP/8543 and let the firewall admin worry about it maybe the analyzer should
do a bit of analysis, check the "history", see that this protocol is not
something commonly used, it's not one of the common worms and decide to
report that it is in fact a stray TCP packet caused by Internet latency (TCP
port higher than 1024, not a "known protocol", coming from an IP address
that is typically accessed by internal IPs via HTTP - all this information
is should be obtainable from the logs).
Now, the question is, what are the things (in your opinion) that only a
human can do?
Regards,
Adrian Grigorof
www.firegen.com
--__--__--
Message: 2
Date: Tue, 5 Jul 2005 18:49:25 +0200
From: Marko Jakovljevic <wizardx86@gmail.com>
Reply-To: Marko Jakovljevic <wizardx86@gmail.com>
To: TODERICKL@mail.ecu.edu
Subject: Re: [fw-wiz] SSH brute force attack
Cc: firewall-wizards@honor.icsalabs.com
Hey Todd, and guys :)
This is my first post so i hope this is the way to reply to the mailing lis=
t ;)
I also have the same problem with these brute SSH attacks. As Matthew
want specifies there isnt much else you can do besides blackholing the
IP, i do know of cases where the system is merely a honeypot
compromised by a sub7 variant or running something called evilbot.
This effectivly allows the zombie master to control all the 'zombies'
that login to the server. Besides this being very effective for denial
of service attacks they can also use the zombies for brute force
attacks and phishing on irc servers / msn / email phishing etc..
I would suggest to completely disallow external ssh access for the
root account and another possibility is using IPtables or whichever
firewall you would use to change the SSH port so that the default port
gets a connection refused. This throws a spanner in the works for the
average script kiddie. If you dont know iptables that well (assuming
you are using iptables in the first place)
http://qtables.radom.org/download.php is an excellent website with a
built in standalone script that generates an IPtable ruleset which is
easy to follow.
Another great tool i found that helps is
http://swatch.sourceforge.net/ for monitoring the logs. What Swatch
can do is monitor whatever logs you wish it to monitor and create
specific firewall rules for an active response. Swatch also has
emailing and of course if it pleases you sms gateway facilities. What
i did with swatch was basically setup a configuration where any false
login attempts to (test/admin/joe/bill) and such others and
automatically blackholes that address and prevents it from accessing
the system for a certain period of time. This "throttle" lasts for
around 600 seconds on the first attempt and if the attempts continue
the throttle lasts longer and longer. The theory is that if it is a
compromised honeypot sooner or later it is going to be cleaned up
(Hopefully) so the ban wont last forever (not that it really matters).
Furthermore any attempts on root and such other accounts can follow
the same pattern.
With some creative use of Swatch and Ethereal you can setup a email
that is sent to you weekly with the logged IP's of every attempt as
well as how many failed attempts, the accounts attempted and then you
can take measures from there.
NB - VERY IMPORTANT!=20
When working with swatch i found a problem with regard to creating
rulesets for other packets besides SSH. Using ettercap (packet
generator) http://sourceforge.net/projects/ettercap/
I was able to create a packet with the same destination IP as the
source IP resulting in me blocking myself out of the system. Although
the attacker gets no benefit from this he automatically blocks the IP
hence turning the system into a closed loop. This isnt possible (i
think?) with SSH packets as those one cannot spoof the source IP but
with others it is.
In summary i'd say Swatch is the best option if those brute attempts
keep annonying you but i guess just preventing outside root SSH access
and changing the default ssh port ah yeah and making a good password
(not something like 1234 or password / root / l33t ) etc... would
result in a relativly secure system.
Thanks guys
" Apart from black-holing the addresses in a "No SSH for you" policy on the
firewall (horse already bolted), about the only thing you can do in ensure
that you can't SSH in as root (something I highly advise anyway) and go to
strong authentication. I have used SKEY quite successfully for this and its
free :-). "
On 7/3/05, David Ross <David.Ross@isrc.qut.edu.au> wrote:
> Toderick, Lee W wrote:
> > Our computers running SSH daemons have logged attacks. The attacks begi=
n
> > with a scan logged "Did not receive identification string from x.x.x.x"=
,
> > followed approximately 15 minutes later with "Illegal user " or " Faile=
d
> > password for root".
> >
> > Does anyone have information or documentation about this scan/attack?
>=20
> I see it daily - and usually ignore it.
> Sometimes I filter the address blocks if they belong to ISPs in
> countries that I am unlikely to visit (and hence ssh from).
> That keeps the logs manageable.
>=20
> --
> David Ross
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>
--__--__--
Message: 3
Date: Tue, 05 Jul 2005 23:17:26 +0200
From: Jan Tietze <jan@planet-pinguin.de>
To: "Paul D. Robertson" <paul@compuwar.net>
Cc: StefanDorn@bankcib.com, firewall-wizards@icsalabs.com
Subject: Re: [fw-wiz] Opinion: Worst interface ever.
Paul D. Robertson schrieb:
>On Tue, 5 Jul 2005 StefanDorn@bankcib.com wrote:
>
>
>>>I can't even imagine trying to audit the "we'll pick the most exact
>>>
>>>
>>match"
>>
>>
The target audience of the Firebox really doesn't know what an audit is.
They usually also don't have much of a budget.
>>>ruleset evaluation of one of these beasts. If I thought there was any
>>>chance the old software would work with the new box, I'd be loading that
>>>tomorrow. My "same vendor" rationale is right out the window- the two
>>>products aren't even close- other than the fact they're both red.
>>>
Since this came up a lot - AFAIK the Watchguard Firebox X series is not
ASIC-based, but based on readily-available x86-style hardware in a nice
red box that mounts in your favorite data center rack and looks really
pretty. It still has mostly the same software on it that used to work in
their previos appliances (Firebox 10/100/II/III series), and that means
it shares the unholy heritage of their rather "unconventional" approach
to rulesets. The ASIC-based Vclass offerings were originally RapidStream
boxes, and they use a totally separate piece of management software that
uses a more traditional approach for ruleset ordering. The Firebox
series really is a SMB device targeted at someone who is so unfamiliar
with firewalls that he won't notice the difference compared to other
firewalls anyway.
>>The 7.x series of software does this- precedence is based on how specific
>>each rule is. The most specific rules are evaluated first, and so on. Of
>>
>>
>But what counts as specific? Is a port more or less specific than an
>address? Is a protocol less specific than a user? If they do an ASIC
>rev, is my happy little ruleset going to do something different if I have
>to replace a box?
>
>
This used to be in their documentation. Also, while we're at it - what's
"incoming" and "outgoing"? They *did* change that once between releases.
Their Firebox II/III boxes used to have 3 NICs only, one for External,
one Trusted, one Optional (DMZ) network (this alone should tell you
something about the target market). Basically, incoming and outgoing are
arranged like this:
Trusted -> Optional -> External
---------- outgoing ----------->
<-------- incoming -----------
However, things get very interesting when you are having VPN users or
sites, because that doesn't fit in very well in this logic, and it was
also changed recently.
One thing you should do when creating a ruleset in WFS (don't know about
8.0, but for pre-8.0, this is true) to avoid confusion about ruleset
ordering is create rulesets like this:
<TRU|OPT|EXT|VPN>-<TRU|OPT|EXT|VPN>-ServiceName
with only one of "Incoming" and "Outgoing" set to "enabled and allowed",
and the other set to "Disabled". This means for each given service and
direction, you can only have a single "service icon" match. This might
end up with rules that are too permissive (ie. you wish to enable
communication between to hosts Trusted_A and Optional_B as well as
Trusted_B and Optional_C, but not Trusted_A and Optional_C), which is
when you should just create another rule of the same kind (preferrably
with a somewhat descriptive suffix). When following this nomenclature,
you won't create rules that are too permissive, and can work around the
magic ruleset ordering problem (just one rule for each service, ruleset
of evaluation doesn't matter anymore). It sure isn't pretty though, but
when you have lots of rules, the nomenclature also helps you find the
rule you seek.
>>course, the software itself does nothing to show you the order they are
>>in. I think I recall reading that in the newer "Fireware Pro" software,
>>you can manually set precedence. Maybe it hasn't been implemented yet.
>>
>>
>I think their marketing department needs smacked. I didn't even start to
>go on about having three interfaces in the box I can't use unless I pay
>more money.
>
>
In all fairness, that's really not that unusual, given that some license
their products on throughput etc.
>>>While I'm ranting- what's with support hours from 9-6pm *at my
>>>location*?
>>>
>>>
You could get Gold support and 24x7 support hours ;-) Also, if you
purchased from a Watchguard partner, you should be able to get some help
from them. And getting access to the support website also shouldn't be
very difficult with a LiveSecurity key (don't expect too much from it
though; the known issues list is notoriously incomplete...).
>>>Hello Watchguard- firewalls are *production* boxes, downtime doesn't get
>>>scheduled for when the users are still working!
>>>
>>>
>>The good news is, they have a support forum with some pretty helpful
>>Watchguard people moderating it, and even a few customers who try to help
>>people out. Bad news is, I've yet to get a question completely answered
>>
>>
They have a forum, yes, but the s/n ratio is terrible and the overall
quality of the responses even by Watchguard support personnel is far
from impressive.
>>via their incident response system. Barring disaster, I generally try to
>>figure a problem out myself, since every time I contact support they
>>immediately request that I let them connect and play with the
>>configuration..which isn't going to happen. It makes me wonder if
>>
>>
The next suggestion by their support is going to be "just rebuild the
configuration from scratch and see if the problem goes away". Either try
to find a knowledgeable person with the partner you purchased the box
through, or demand to have the ticket escalated to second level.
>>outsourcing can really be worth it, considering the fact that it generally
>>results in customers getting irritated with it and then requesting a US
>>representative anyway. Why not just get it right the first time?
>>
>>
>I'm glad I'm not the only one left with that impression. I'm going to go
>back over my personal evaluation criteria and tweak the support parts to
>match what I see as good. I also think that I'm going to go back to
>building more open source based firewalls- the idea behind a commercial
>product is support and consistency. I'm not seeing good things in either
>department.
>
>
At one point I had to work with Watchguard firewalls most of the time.
They really are oriented towards beginners for whom network security is
a relatively new field and part-time duty of their job. I'm seeing some
great products with rather good management software. I don't share your
pessimistic view of the commercial firewall vendor space, and I
certainly wouldn't want to go back to building firewalls myself from
open source components again though - there's so many things to worry
about (logging securely, log file management, distributed firewall
management, clustering, VPN inteoperability, link redundancy, patch
management..., remote upgrades, downgrades...) that I'd much rather pick
a commercial solution with a reasonable architecture and management.
I'm also pretty sure that you are mixing up their Vclass and Firebox
product lines. They have nothing in common AFAIR.
-- Jan
--__--__--
Message: 4
Date: Tue, 05 Jul 2005 14:54:19 -0700
From: "David M. Nicksic" <dnicksic@mossbaygroup.com>
To: <firewall-wizards@honor.icsalabs.com>
Subject: [fw-wiz] Cisco PIX Version 6.3(3) SMTP Problem
I am using a PIX 520 v 6.3.3 and having a spam problem. A spam service
Postini is employed. I want to deny all SMTP traffic unless it comes from
one of the Postini servers. Can the PIX be configured to accomplish this?
Thanks in advance for any help.
--__--__--
Message: 5
Date: Tue, 05 Jul 2005 17:36:03 -0600
From: vbwilliams@neb.rr.com
Subject: Re: RE: [fw-wiz] Opinion: Worst interface ever.
To: "Paul D. Robertson" <paul@compuwar.net>
Cc: Eugene Kuznetsov <eugene@datapower.com>,
firewall-wizards@icsalabs.com
Reply-To: vbwilliams@neb.rr.com
My opinion...
I won't use the products strictly because of their interfaces. None of
them are consistent with the other. There needs to be consistency.
In my opinion, the interface is one of the only differentiating things
in this line of products. I would much rather use a version of PIX
than mess around with Watchguard at this point in the game. With PIX,
I know what I'm getting. The command line and web interfaces are the
same regardless of the model of firewall. Watchguard, why is every
different model/version different...and vastly different?
In my opinion, if you're going to base a commercial firewall product on
open/free software (which several of the Watchguards are...at least the
ones I've dealt with), then you better differentiate your product with
something that's definitely superior. The documentation is definitely
subpar, the OS is the same as any homegrown solution, so what else is
there other than interface?
You could build yourself the equivalent of any of the Watchguard
products for about the same price as it costs to buy one off the
shelf. Seeing as their support sucks, their interface sucks, their
documentation sucks, why do people keep buying the things?
----- Original Message -----
From: "Paul D. Robertson" <paul@compuwar.net>
Date: Tuesday, July 5, 2005 9:08 am
Subject: RE: [fw-wiz] Opinion: Worst interface ever.
> On Tue, 5 Jul 2005, Eugene Kuznetsov wrote:
>
> > I am not familiar with the WatchGuard interface, but I will say
> one general
> > thing in their defence -- this stuff is harder to do than it seems.
>
> Sure, but while the old interface was ugly, it was intuitive- and
> consistency is important.
>
> > For every user like you, who's annoyed about the redesign,
> there's another
> > one who demanded that the UI be reworked in the first place: to
> make it more
> > intuitive for his preferred configuration, or to add options for new
>
> Sure, when a vendor goes from "intuitive and simple" to "where the
> heck is
> this thing failing, all the things the manual says are done?" I
> think it's
> bad.
>
> > features. I'll even go out on a limb and bet $5 that somewhere
> in the first
> > 5 minutes of your ordeal, you took a wrong turn, and it all went
> downhill> from there. Had you taken a different path, it would've
> all been good.
>
> One of my coworkers had the same issue, so I'm guessing that it's
> not all
> that intuitive where that turn was. It's frustrating to go from "hey,
> this product is good" to "hey, this revision is bad!"
>
> I'm really starting to dislike the "interface can't run locally on the
> device" stuff when coupled with "won't log on the device."
>
> > So take this as a vendor perspective: it's not easy, especially
> since> customer requirements are increasingly diverging. More
> features --> more
> > complexity.
>
> Hey, I didn't ask for more features, someone's marketing
> department did!
> I'm mostly upset at myself for assuming that the new version would
> be an
> incramental improvement of the old, not something that two of us had
> serious issues with despite following the instructions in the manual.
>
> I'm also going to add a new vendor test to my criteria- if I can't get
> read-only access to the support site without a login, that
> vendor's off my
> list.
>
> Paul
> -------------------------------------------------------------------
> ----------
> Paul D. Robertson "My statements in this message are personal
> opinionspaul@compuwar.net which may have no basis whatsoever
> in fact."
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>
--__--__--
Message: 6
Date: Tue, 05 Jul 2005 20:46:12 -0400
To: "Eugene Kuznetsov" <eugene@datapower.com>
From: Mark Teicher <mht3@earthlink.net>
Subject: RE: [fw-wiz] Opinion: Worst interface ever.
Cc: "'Paul D. Robertson'" <paul@compuwar.net>,
<firewall-wizards@icsalabs.com>
The WG UI has been redesigned over the years, but still has the same
clunk and feel it used to have in the early days, the context
sensitive help actually works compared to years ago where one filed a
bug and waited for the next rev. Their appliance design has changed
many times for cost reasons. At one time or another they were known
as "The Big RED BOX" firewall. I think that was when David Bonn was
their Chief Technology Officer, since then I don't know who has been
fiddling with the code or the User Interface. All I can say is that
there are still issues with the interface and some of the newer
features, whatever you do plan ahead when enabling the in-line AV and
SPAM feature.
You may want call technical support ahead of time and schedule lots
of offline time to configure it properly or all your email might end
up in /dev/null. :(
At 10:44 AM 7/5/2005, Eugene Kuznetsov wrote:
>I am not familiar with the WatchGuard interface, but I will say one general
>thing in their defence -- this stuff is harder to do than it seems.
>
>For every user like you, who's annoyed about the redesign, there's another
>one who demanded that the UI be reworked in the first place: to make it more
>intuitive for his preferred configuration, or to add options for new
>features. I'll even go out on a limb and bet $5 that somewhere in the first
>5 minutes of your ordeal, you took a wrong turn, and it all went downhill
>from there. Had you taken a different path, it would've all been good.
>
>Now, again, I don't know much about WG, they could be just awful. I just
>know that "flexibility" and "ease-of-use" often work at cross-purposes and
>it takes a whole lot of ingenuity, discipline and luck to pull it off. I
>think we get it right with our products, most of the time, but it is not
>easy.
>
>So take this as a vendor perspective: it's not easy, especially since
>customer requirements are increasingly diverging. More features --> more
>complexity.
>
>\\ Eugene Kuznetsov, Chairman & CTO : eugene@datapower.com
>\\ DataPower Technology, Inc. : Web Services security
>\\ http://www.datapower.com : XML-aware networks
>
>
>_______________________________________________
>firewall-wizards mailing list
>firewall-wizards@honor.icsalabs.com
>http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
--__--__--
Message: 7
Date: Tue, 05 Jul 2005 20:53:59 -0400
To: "Paul D. Robertson" <paul@compuwar.net>
From: Mark Teicher <mht3@earthlink.net>
Subject: RE: [fw-wiz] Opinion: Worst interface ever.
Cc: Eugene Kuznetsov <eugene@datapower.com>,
firewall-wizards@icsalabs.com
I recall this argument all to well during the early days of
implementing firewalls. Customers used to go gaga over some X11
based UI from some vendor versus a curses based ui, that was simple
to use and less than 7 or 8 config options and a customer's firewalls
was up and protecting their network from the baddies.
But that was over a decade ago, and not to many people remember the
days of hiring female technical engineers that could fill a sweater
and knew a little bit about net-perm tables and proxy gateways.. ..
Still waiting for the Graybeards of Internet Security to have their
first gathering
At 11:08 AM 7/5/2005, Paul D. Robertson wrote:
>On Tue, 5 Jul 2005, Eugene Kuznetsov wrote:
>
> > I am not familiar with the WatchGuard interface, but I will say one general
> > thing in their defence -- this stuff is harder to do than it seems.
>
>Sure, but while the old interface was ugly, it was intuitive- and
>consistency is important.
>
> > For every user like you, who's annoyed about the redesign, there's another
> > one who demanded that the UI be reworked in the first place: to
> make it more
> > intuitive for his preferred configuration, or to add options for new
>
>Sure, when a vendor goes from "intuitive and simple" to "where the heck is
>this thing failing, all the things the manual says are done?" I think it's
>bad.
>
> > features. I'll even go out on a limb and bet $5 that somewhere in the first
> > 5 minutes of your ordeal, you took a wrong turn, and it all went downhill
> > from there. Had you taken a different path, it would've all been good.
>
>One of my coworkers had the same issue, so I'm guessing that it's not all
>that intuitive where that turn was. It's frustrating to go from "hey,
>this product is good" to "hey, this revision is bad!"
>
>I'm really starting to dislike the "interface can't run locally on the
>device" stuff when coupled with "won't log on the device."
>
> > So take this as a vendor perspective: it's not easy, especially since
> > customer requirements are increasingly diverging. More features --> more
> > complexity.
>
>Hey, I didn't ask for more features, someone's marketing department did!
>I'm mostly upset at myself for assuming that the new version would be an
>incramental improvement of the old, not something that two of us had
>serious issues with despite following the instructions in the manual.
>
>I'm also going to add a new vendor test to my criteria- if I can't get
>read-only access to the support site without a login, that vendor's off my
>list.
>
>Paul
>-----------------------------------------------------------------------------
>Paul D. Robertson "My statements in this message are personal opinions
>paul@compuwar.net which may have no basis whatsoever in fact."
>_______________________________________________
>firewall-wizards mailing list
>firewall-wizards@honor.icsalabs.com
>http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
--__--__--
_______________________________________________
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