Sign in with
Sign up | Sign in
Your question

Defeating Firewalls: Sneaking Into Office Computers From H..

Tags:
  • Firewalls
  • Office
  • Networking
Last response: in Networking
Share
August 12, 2005 11:21:40 AM

Archived from groups: comp.security.firewalls (More info?)

Greetings Everyone,

In this paper, I discuss a technique to get into your office computer
using ssh tunneling with some cool tricks. You don't need anything much
to implement this, not even an open port on the firewall. All you need
from your employer is the http(s) proxy which most of the companies
provide. This paper shows how an employee can ridicule the firewalls of
the company by facilitating the access to the company intranet using
easily available resources.

Here is the problem scenario - "You work with a company 'XYZ'. At
office, you cannot access internet directly and you 'browse' internet
using HTTP(S) proxy. Back at home, you have an internet connection. You
want to access the office computer from home, but you don't have the
VPN access." How do you do that? Read the paper for the solution.

Disclaimer: Please use your brain before using this technique. You can
be kicked out by your employer for using it. Don't blame me.

Here is the link to blog-entry:
http://manugarg.blogspot.com/2005/07/defeating-firewall...

cheers,
^manu
---------
Manu Garg
http://www.manugarg.com
"Truth will set you free!"

More about : defeating firewalls sneaking office computers

August 12, 2005 11:46:51 AM

Archived from groups: comp.security.firewalls (More info?)

May I know that "properly setup firewall solution", please!! :) 
August 12, 2005 12:06:37 PM

Archived from groups: comp.security.firewalls (More info?)

But, I am just skipping firewall and there is no web server at all in
the picture. What I need is just http(s) proxy and an ssh server on
the internet (which I am supposed to have at home). I'll setup
connection to the ssh server using https proxy and ride back on that
SSL connection.

No offense meant, but I think you didn't read the paper completely. :) 
August 12, 2005 12:47:12 PM

Archived from groups: comp.security.firewalls (More info?)

Floyd L. Davidson wrote:
> Leythos <void@nowhere.lan> wrote:
> >In article <1123859197.303106.293860@g47g2000cwa.googlegroups.com>,
> >manugarg@gmail.com says...
> >> But, I am just skipping firewall and there is no web server at all in
> >> the picture. What I need is just http(s) proxy and an ssh server on
> >> the internet (which I am supposed to have at home). I'll setup
> >> connection to the ssh server using https proxy and ride back on that
> >> SSL connection.
> >>
> >> No offense meant, but I think you didn't read the paper completely. :) 
> >
> >So, you're saying that from your office you can connect to your home
> >using https and then from your home you can ride back through the https
> >connection into the computer at your office?
> >
> >I guess I would have to know why your company allows you
>
> 1)
> >outbound access
> >to all internet sites,
>
> Unnecessary. All he needs is access to *his* IP address, and it
> would be very unlikely that any random company would have reason
> to block it.
>
>
> 2)
> >why residential address blocks are not blocked,
>
> What is a "residential address block" ????
>
>
> 3)
> >why they don't terminate https sessions after x amount of time,
>
> Maybe they do! But they certainly would not have timeouts that
> are unreasonably short... say less than 8-10 hours so that
> employees can do business without being knocked off. That of
> course means that he can set up this connection just before
> leaving work, and he will have sufficient time to work at home
> prior to any reasonable timeout.
>

You can always put a cronjob to check for the connection at a certain
interval. If connection has gone down you can establish it again. As
far as the timeout of idle http connection goes (it's less than 2 min,
I think), I keep transferring data on the connection by running a
script at the ssh server side and transferring the output of that
script on that http tunnel.

> 4)
> >and how
> >they can miss an active https session that's connected for any length of
> >time beyond the norm.
>
> See above.
>
> >It would be interesting to see if our firewalls permitted what you
> >describe - we will test this weekend, but I don't think it will work on
> >our networks.
>
> Your firewalls may or may not be configured for the same
> requirements that exist at his company.

I would be interested in the results of your tests too. As long as you
company provides access to any https sites, it should work. I say it
again, "There is no special configuration required at the firewall.
Very standard setup." Only way (AFAIK) you can avoid it is by making
your proxy much more intelligent.

>
> --
> Floyd L. Davidson <http://www.apaflo.com/floyd_davidson&gt;
> Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

---------
Manu Garg
http://manugarg.com
"Truth will set you free!"
August 12, 2005 12:51:51 PM

Archived from groups: comp.security.firewalls (More info?)

Hey Frank,

I am sure it's not a profound discovery. But, I never found anybody
talking about this technique to get an easy access. That's why I wrote
this paper.

---------------
Manu Garg
http://manugarg.com
"Truth will set you free!"
August 12, 2005 12:53:57 PM

Archived from groups: comp.security.firewalls (More info?)

Proxy is not outside firewall. Only that the firewall allows port 80
and 443 from this proxy. Which is a kind of requirement for a http(s)
to work.

----------------
Manu Garg
http://manugarg.com
"Truth will set you free!"
August 12, 2005 1:35:59 PM

Archived from groups: comp.security.firewalls (More info?)

> In this paper, I discuss a technique to get into your office computer
> using ssh tunneling with some cool tricks.

YOUR office computer?

This is insider sabotage, pure and simple. It is no secret that insiders
have the potential to do more harm to a network than any outside hackers, no
matter how skilled the outside hacker is. It has been this way since
networks began. That is why companies don't rely on purely technical
prevention (won't work most of the time anyway) but instead rely on sound
employee education, hiring practices, lie detector tests in some cases, and
look for opportunities to "set an example" for the other employees by
terminating and/or prosecuting those employees that attempt or succeed in
stealing company resources.

Bottom line... OF COURSE you can "hack" into your OWN NETWORK! Big deal.
Not exactly a profound discovery.

-Frank
Anonymous
August 12, 2005 3:41:21 PM

Archived from groups: comp.security.firewalls (More info?)

manu wrote:
> May I know that "properly setup firewall solution", please!! :) 
>

for starters, do NOT have a proxy that is outside the firewall!

--
---
I am a Sock Puppet - a spews parrot and a member of the spews lunatics
of n.a.n-a.e. (AKA spews fanatics)
Which means I support moris, since moris *IS* spews.
Anonymous
August 12, 2005 6:32:20 PM

Archived from groups: comp.security.firewalls (More info?)

In article <1123856500.836097.311400@o13g2000cwo.googlegroups.com>,
manugarg@gmail.com says...
> Greetings Everyone,
>
> In this paper, I discuss a technique to get into your office computer
> using ssh tunneling with some cool tricks. You don't need anything much
> to implement this, not even an open port on the firewall. All you need
> from your employer is the http(s) proxy which most of the companies
> provide. This paper shows how an employee can ridicule the firewalls of
> the company by facilitating the access to the company intranet using
> easily available resources.
>
> Here is the problem scenario - "You work with a company 'XYZ'. At
> office, you cannot access internet directly and you 'browse' internet
> using HTTP(S) proxy. Back at home, you have an internet connection. You
> want to access the office computer from home, but you don't have the
> VPN access." How do you do that? Read the paper for the solution.
>
> Disclaimer: Please use your brain before using this technique. You can
> be kicked out by your employer for using it. Don't blame me.

It wont work in a properly setup firewall solution - and yes, it could
get anyone fired for doing it.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 12, 2005 6:32:21 PM

Archived from groups: comp.security.firewalls (More info?)

Leythos <void@nowhere.lan> wrote:
>In article <1123859197.303106.293860@g47g2000cwa.googlegroups.com>,
>manugarg@gmail.com says...
>> But, I am just skipping firewall and there is no web server at all in
>> the picture. What I need is just http(s) proxy and an ssh server on
>> the internet (which I am supposed to have at home). I'll setup
>> connection to the ssh server using https proxy and ride back on that
>> SSL connection.
>>
>> No offense meant, but I think you didn't read the paper completely. :) 
>
>So, you're saying that from your office you can connect to your home
>using https and then from your home you can ride back through the https
>connection into the computer at your office?
>
>I guess I would have to know why your company allows you

1)
>outbound access
>to all internet sites,

Unnecessary. All he needs is access to *his* IP address, and it
would be very unlikely that any random company would have reason
to block it.


2)
>why residential address blocks are not blocked,

What is a "residential address block" ????


3)
>why they don't terminate https sessions after x amount of time,

Maybe they do! But they certainly would not have timeouts that
are unreasonably short... say less than 8-10 hours so that
employees can do business without being knocked off. That of
course means that he can set up this connection just before
leaving work, and he will have sufficient time to work at home
prior to any reasonable timeout.

4)
>and how
>they can miss an active https session that's connected for any length of
>time beyond the norm.

See above.

>It would be interesting to see if our firewalls permitted what you
>describe - we will test this weekend, but I don't think it will work on
>our networks.

Your firewalls may or may not be configured for the same
requirements that exist at his company.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson&gt;
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
Anonymous
August 12, 2005 6:53:21 PM

Archived from groups: comp.security.firewalls (More info?)

In article <1123858011.738892.309250@g47g2000cwa.googlegroups.com>,
manugarg@gmail.com says...
> May I know that "properly setup firewall solution", please!! :) 

Any firewall that's properly setup won't allow it to work. You can ride
in on something and get anywhere if the firewall rules don't permit it -
there is no way you can ride a SSL connection into the company and get
access to your LAN as the web server would be in the DMZ with no
connection to the LAN - and that's just one way.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 12, 2005 6:53:22 PM

Archived from groups: comp.security.firewalls (More info?)

Leythos wrote:
> In article <1123858011.738892.309250@g47g2000cwa.googlegroups.com>,
> manugarg@gmail.com says...
>
>>May I know that "properly setup firewall solution", please!! :) 
>
>
> Any firewall that's properly setup won't allow it to work. You can ride
> in on something and get anywhere if the firewall rules don't permit it -
> there is no way you can ride a SSL connection into the company and get
> access to your LAN as the web server would be in the DMZ with no
> connection to the LAN - and that's just one way.
>

The papers is not talking about a web server - it is talking about a
proxy server for the lan users, which would HAVE to have access to both
the lan and the internet.

Part of the reason that I do not recommend proxy servers a security measure.


--
---
I am a Sock Puppet - a spews parrot and a member of the spews lunatics
of n.a.n-a.e. (AKA spews fanatics)
Which means I support moris, since moris *IS* spews.
Anonymous
August 12, 2005 7:12:00 PM

Archived from groups: comp.security.firewalls (More info?)

In article <1123859197.303106.293860@g47g2000cwa.googlegroups.com>,
manugarg@gmail.com says...
> But, I am just skipping firewall and there is no web server at all in
> the picture. What I need is just http(s) proxy and an ssh server on
> the internet (which I am supposed to have at home). I'll setup
> connection to the ssh server using https proxy and ride back on that
> SSL connection.
>
> No offense meant, but I think you didn't read the paper completely. :) 

So, you're saying that from your office you can connect to your home
using https and then from your home you can ride back through the https
connection into the computer at your office?

I guess I would have to know why your company allows you outbound access
to all internet sites, why residential address blocks are not blocked,
why they don't terminate https sessions after x amount of time, and how
they can miss an active https session that's connected for any length of
time beyond the norm.

It would be interesting to see if our firewalls permitted what you
describe - we will test this weekend, but I don't think it will work on
our networks.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 12, 2005 7:36:59 PM

Archived from groups: comp.security.firewalls (More info?)

In article <87zmrnqif6.fld@barrow.com>, floyd@apaflo.com says...
> >It would be interesting to see if our firewalls permitted what you
> >describe - we will test this weekend, but I don't think it will work on
> >our networks.
>
> Your firewalls may or may not be configured for the same
> requirements that exist at his company.

Never suggested they were - he was purporting that this would work
through firewalls, and didn't restrict it to the company he worked for.

Oh, and HTTPS sessions lasting 8 hours? We don't see them lasting more
than an hour, and that's when they leave their OWA connected by
accident. We still disconnect them and let them reconnect.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 13, 2005 9:09:32 PM

Archived from groups: comp.security.firewalls (More info?)

ibuprofin@painkiller.example.tld (Moe Trin) wrote:
>>>why residential address blocks are not blocked,
>>
>>What is a "residential address block" ????
>
>I know that you have less of a choice of providers up there, but down in
>this part of the country, most businesses don't use comcast, verizon,
>pacbell, swbell, road runner, etc. DYNAMIC HOST ADDRESSES for business.
>I'm in the Phoenix area, and the "big names" for residential service here
>are cox.net (who has the cable franchise) and qworst (who has the phone
>franchise), with a few dozen other smaller players. We really are aware of
>the local IP blocks they are using. I mean, even doing an ARIN query for
>the word "QWEST" gives you a starting point (assuming no one in your IT
>department might happen to be one of their local customers).

You might well be "really" aware of *local* blocks of IP
addresses that are typically (but not always) residential
customers.

But there simply is no such thing as a "residential address
block" that can universally be blocked. Even attempting to do
so based on local patters is a very poor idea.

>We do have a few exceptions - like a couple of local 'take-out' food
>joints, so that our employees can order that pizza or what-ever, but
>those are small holes punched in an otherwise blocked IP range.

And you cannot know positively where to "punch" these small
holes.

>>>why they don't terminate https sessions after x amount of time,
>>
>>Maybe they do! But they certainly would not have timeouts that
>>are unreasonably short... say less than 8-10 hours so that
>>employees can do business without being knocked off.
>
>One has to wonder what kind of business you are in if your employees are
>running SSH (or almost any other protocol) sessions that long. Yes, I am
>excluding the poor sod who's trying to monitor the backups from home, but
>as he's part of the IT group, he also has known particulars. The general
>employee doesn't fit that model.

That depends greatly on what business one is in, and therefore
just what employees might be doing on the Internet. It is
*never* a good idea to assume that what is typical for you or in
your experience is the limit of what might be reasonable.

>>>and how they can miss an active https session that's connected for any
>>>length of time beyond the norm.
>>
>>See above.
>
>As my previous response above. Honestly, that length of a connection
>sorta sticks out like a sore thumb.

It might. It might not too.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson&gt;
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
Anonymous
August 13, 2005 10:26:21 PM

Archived from groups: comp.security.firewalls (More info?)

In the Usenet newsgroup comp.security.firewalls, in article
<87zmrnqif6.fld@barrow.com>, Floyd L. Davidson wrote:

>Leythos <void@nowhere.lan> wrote:

>>why residential address blocks are not blocked,
>
>What is a "residential address block" ????

I know that you have less of a choice of providers up there, but down in
this part of the country, most businesses don't use comcast, verizon,
pacbell, swbell, road runner, etc. DYNAMIC HOST ADDRESSES for business.
I'm in the Phoenix area, and the "big names" for residential service here
are cox.net (who has the cable franchise) and qworst (who has the phone
franchise), with a few dozen other smaller players. We really are aware of
the local IP blocks they are using. I mean, even doing an ARIN query for
the word "QWEST" gives you a starting point (assuming no one in your IT
department might happen to be one of their local customers).

We do have a few exceptions - like a couple of local 'take-out' food
joints, so that our employees can order that pizza or what-ever, but
those are small holes punched in an otherwise blocked IP range.

>>why they don't terminate https sessions after x amount of time,
>
>Maybe they do! But they certainly would not have timeouts that
>are unreasonably short... say less than 8-10 hours so that
>employees can do business without being knocked off.

One has to wonder what kind of business you are in if your employees are
running SSH (or almost any other protocol) sessions that long. Yes, I am
excluding the poor sod who's trying to monitor the backups from home, but
as he's part of the IT group, he also has known particulars. The general
employee doesn't fit that model.

>>and how they can miss an active https session that's connected for any
>>length of time beyond the norm.
>
>See above.

As my previous response above. Honestly, that length of a connection
sorta sticks out like a sore thumb.

Old guy
Anonymous
August 14, 2005 2:19:26 AM

Archived from groups: comp.security.firewalls (More info?)

manu wrote:

> Hey Frank,
>
> I am sure it's not a profound discovery. But, I never found anybody
> talking about this technique

Well, other people seem not so stupid to write instructions that might make
others lose their jobs.

> to get an easy access. That's why I wrote
> this paper.

I hope for you that you are prepared to get sued by all those people who
have lost their jobs because they followed your instruction how to violate
the security policy of their (former) employer.

Wolfgang
Anonymous
August 14, 2005 2:54:53 AM

Archived from groups: comp.security.firewalls (More info?)

"manu" <manugarg@gmail.com> wrote in message
news:1123859197.303106.293860@g47g2000cwa.googlegroups.com...
> But, I am just skipping firewall and there is no web server at all in
> the picture. What I need is just http(s) proxy and an ssh server on
> the internet (which I am supposed to have at home). I'll setup
> connection to the ssh server using https proxy and ride back on that
> SSL connection.
>
> No offense meant, but I think you didn't read the paper completely. :) 
>

I could stop that manu. This could be stopped by
using NAT, and forcing all the machines to share
one IP address, rather than giving each PC on
the network its own individual IP address.
If the network in question is using AllegroSurf,
it will never get past that, as they only direct
connections allowed by AllegroSurf are to the
machine running AllegroSurf. You have to set
up a proxy on that machine if you want the PCs
to even get out on the Internet. In short, I could
stop your system by getting rid of all the hardware
routers, NAT, and firewalls devices, and setting on
a single machine using AllegroSurf.
Anonymous
August 14, 2005 3:04:24 AM

Archived from groups: comp.security.firewalls (More info?)

"Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message
news:slrndft0cp.1um.ibuprofin@compton.phx.az.us...
> In the Usenet newsgroup comp.security.firewalls, in article
> <87zmrnqif6.fld@barrow.com>, Floyd L. Davidson wrote:
>
> >Leythos <void@nowhere.lan> wrote:
>
> >>why residential address blocks are not blocked,
> >
> >What is a "residential address block" ????
>
> I know that you have less of a choice of providers up there, but down in
> this part of the country, most businesses don't use comcast, verizon,

Well, Comcast is about to launch a high-end
business version of their cable services. I got a
flyer in my last cable bill advertising it. It did not
say how much it would cost, but only that Comcast
is about to introduce it in this area. Comcast wants
to be a cheaper alternative for business internet, than
T-1 service. I know that when it does launch, the
high-end business version of Comcast will have
8 megabits download, and 1.5 megabits upload.
A T-1 would never reach 8 megabits, and
would likely cost a lot more than the Comcast
business-level internet that is about to be
introduced. And that will include a static IP
and will allow servers.
Anonymous
August 14, 2005 3:10:24 AM

Archived from groups: comp.security.firewalls (More info?)

"Wolfgang Kueter" <wolfgang@shconnect.de> wrote in message
news:D dlkiq$9ci$2@news.shlink.de...
> manu wrote:
>
> > Hey Frank,
> >
> > I am sure it's not a profound discovery. But, I never found anybody
> > talking about this technique
>
> Well, other people seem not so stupid to write instructions that might
make
> others lose their jobs.
>
> > to get an easy access. That's why I wrote
> > this paper.
>
> I hope for you that you are prepared to get sued by all those people who
> have lost their jobs because they followed your instruction how to violate
> the security policy of their (former) employer.


Well, you employer can terminate you, but to
be safe, he/she will not give any reference, good
or bad, becuase the courts have allowed employers
to be sued, either way. In short, most employers will
only confirm that you worked there during a certain
time period, but will not say anything beyond that.
You have to be careful what you say about
former employees, good or bad. I was taught
in college that the best policy is to not give
any reference, either way. That is what I was taught
in business law class. The safest way is to merely
say that they worked for you, but do not say
anything beyond that, good or bad.
Anonymous
August 14, 2005 5:47:21 AM

Archived from groups: comp.security.firewalls (More info?)

Leythos <void@nowhere.lan> wrote:
>In article <87hddtnx2r.fld@barrow.com>, floyd@apaflo.com says...
>>
>> But there simply is no such thing as a "residential address
>> block" that can universally be blocked. Even attempting to do
>> so based on local patters is a very poor idea.
>
>Wrong, there are simple lists available and are often used in RBL's - we
>use the residential block list to block inbound SMTP to our servers as
>we don't have any reason for a residential customer to send us email
>from their workstation, the ISP's SMTP servers are almost always not
>included in the residential network lookup lists.

It's a very poor idea.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson&gt;
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
Anonymous
August 14, 2005 6:30:46 AM

Archived from groups: comp.security.firewalls (More info?)

In article <87hddtnx2r.fld@barrow.com>, floyd@apaflo.com says...
>
> But there simply is no such thing as a "residential address
> block" that can universally be blocked. Even attempting to do
> so based on local patters is a very poor idea.

Wrong, there are simple lists available and are often used in RBL's - we
use the residential block list to block inbound SMTP to our servers as
we don't have any reason for a residential customer to send us email
from their workstation, the ISP's SMTP servers are almost always not
included in the residential network lookup lists.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 14, 2005 12:18:02 PM

Archived from groups: comp.security.firewalls (More info?)

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
>People around here don't buy T1's for -speed-. Reasons why they
>do buy T1 include:

This is an interesting list, and technically is correct in most
aspects (the comment about "synchronous ... for multimedia"
isn't right).

However, there are some *very* serious "gotcha's" in this too.
Most services provided over what might be called a "T1", may or
may not be technically what is being reference as a T1!

For example, a T1 that is provision through a provider's Frame
Relay cloud, might not provide the stated benefits. That isn't
technically just a T1, but is almost always called a T1 today.

>- T1 provides symmetric bandwidth (SDSL is not very common here)

Significant, and correct for anything likely to be called a T1.

>- T1 is point to point and thus does not have the security issues
>that one has when one is connected to the Internet

That is probably not quite true, though the issues are less
serious than with DSL or Cable provisioned services. A Frame
Relay Cloud still has the same potential insider security
issues...

>- T1 are available -most- places that phone land-lines reach --
>the required infrastructure having existed for long enough for
>very good saturation.

True.

>- T1 do not degrade with congestion from other users on your block
>(a significant problem with cable!)

Unless of course it is part of a Frame Relay Cloud. (I once saw
a carrier install a Frame Relay Point-of-Presence, and then sell
6 different customers guaranteed bandwidth circuits equal to the
backbone! ;-)

>- T1 have fixed latency and bandwidth, not variable as cable has

Probably true, but it can vary significantly if any part of the
T1 is on Frame Relay or Cell Relay (ATM) backbone services.

>- T1 is synchronous and thus suitable for multimedia applications
>that degrade when frames are received out of order

Being synchronous or not doesn't affect the order that frames
are received in. Regardless, virtually all T1's ride T3's, and
thus become isochronous and suffer from higher clock jitter than
a genuine point to point T1 over a wire facility would have.

>- T1 has no bandwidth caps, content filters, forced http proxying,

Two out of three. It certainly has a bandwidth cap. Moreover
it it is provision on Frame Relay or Cell Relay there will be
just as many wierd bandwidth specs as one can imagine (burst,
guaranteed, etc.), and might well be affected by how much other
customers are using.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson&gt;
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
Anonymous
August 14, 2005 12:28:58 PM

Archived from groups: comp.security.firewalls (More info?)

In article <cLqdnTJjYNt1Q2PfRVn-qA@comcast.com>,
Charles Newman <charlesnewman1@comcast.do.not.spam.me.net> wrote:

:Comcast wants
:to be a cheaper alternative for business internet, than
:T-1 service. I know that when it does launch, the
:high-end business version of Comcast will have
:8 megabits download, and 1.5 megabits upload.
: A T-1 would never reach 8 megabits, and
:would likely cost a lot more than the Comcast
:business-level internet that is about to be
:introduced. And that will include a static IP
:and will allow servers.

That kind of business cable is available here [Winnipeg Canada]
for about 1/8th of the price of a T1 -- less than $US100 compared to
about $US1000 for T1. 10 megabit burstable fibre has been available for
years here for about $US250. And yet there are still quite a few
T1 providers.

People around here don't buy T1's for -speed-. Reasons why they
do buy T1 include:

- T1 provides symmetric bandwidth (SDSL is not very common here)

- T1 is point to point and thus does not have the security issues
that one has when one is connected to the Internet

- T1 are available -most- places that phone land-lines reach --
the required infrastructure having existed for long enough for
very good saturation.

- T1 do not degrade with congestion from other users on your block
(a significant problem with cable!)

- T1 have fixed latency and bandwidth, not variable as cable has

- T1 is synchronous and thus suitable for multimedia applications
that degrade when frames are received out of order

- T1 has no bandwidth caps, content filters, forced http proxying,
--
The rule of thumb for speed is:

1. If it doesn't work then speed doesn't matter. -- Christian Bau
August 14, 2005 12:33:38 PM

Archived from groups: comp.security.firewalls (More info?)

>> But there simply is no such thing as a "residential address
>> block"

> Wrong, there are simple lists available and are often used in RBL's

What is the definition of a "residential IP"?

-Frank
Anonymous
August 14, 2005 3:43:45 PM

Archived from groups: comp.security.firewalls (More info?)

"Frankster" <Frank@SPAM2TRASH.com> wrote:
>So... it's a secret?
>
>-Frank

NO! You merely have to ask... *every* ISP in the world.

>"Leythos" <void@nowhere.lan> wrote in message
>news:MPG.1d6943c0b759fc80989bb0@news-server.columbus.rr.com...
>> In article <p_2dneBMGsFv8GLfRVn-hA@giganews.com>, Frank@SPAM2TRASH.com
>> says...
>>> I know what RBLs are about... for mail. "Real-Time Blackhole List". But
>>> where do you find the databases listing residential IPs?
>>
>> By understanding the RBL's and how they were formed - in most cases, if
>> you follow the RBL back to the site that hosts it, or the master site
>> for the particular RBL, they will give you the ranges. If you search you
>> will find.
>>
>> --
>>
>> spam999free@rrohio.com
>> remove 999 in order to email me

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson&gt;
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
Anonymous
August 14, 2005 4:03:23 PM

Archived from groups: comp.security.firewalls (More info?)

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:D dmvca$b6l$1@canopus.cc.umanitoba.ca...
> In article <cLqdnTJjYNt1Q2PfRVn-qA@comcast.com>,
> Charles Newman <charlesnewman1@comcast.do.not.spam.me.net> wrote:
>
> :Comcast wants
> :to be a cheaper alternative for business internet, than
> :T-1 service. I know that when it does launch, the
> :high-end business version of Comcast will have
> :8 megabits download, and 1.5 megabits upload.
> : A T-1 would never reach 8 megabits, and
> :would likely cost a lot more than the Comcast
> :business-level internet that is about to be
> :introduced. And that will include a static IP
> :and will allow servers.
>
> That kind of business cable is available here [Winnipeg Canada]
> for about 1/8th of the price of a T1 -- less than $US100 compared to
> about $US1000 for T1. 10 megabit burstable fibre has been available for
> years here for about $US250. And yet there are still quite a few
> T1 providers.
>
> People around here don't buy T1's for -speed-. Reasons why they
> do buy T1 include:
>
> - T1 provides symmetric bandwidth (SDSL is not very common here)
>
> - T1 is point to point and thus does not have the security issues
> that one has when one is connected to the Internet
>
> - T1 are available -most- places that phone land-lines reach --
> the required infrastructure having existed for long enough for
> very good saturation.
>
> - T1 do not degrade with congestion from other users on your block
> (a significant problem with cable!)

That is one reason why business-level cable
costs a lot more, you are not sharing your
connection with other people. That put one
connection to a head-end. That is why it is
more expensive, and why they can allow servers
on such a connection. I dont know what
Comcast will charge, but I know that
RoadRunner has it in some markets for
$155 per month, quite a bit less than a
T-1 line.

>
> - T1 have fixed latency and bandwidth, not variable as cable has
>
> - T1 is synchronous and thus suitable for multimedia applications
> that degrade when frames are received out of order
>
> - T1 has no bandwidth caps, content filters, forced http proxying,
> --
> The rule of thumb for speed is:
>
> 1. If it doesn't work then speed doesn't matter. -- Christian Bau
Anonymous
August 14, 2005 6:27:15 PM

Archived from groups: comp.security.firewalls (More info?)

In article <87zmrkn93q.fld@barrow.com>, floyd@apaflo.com says...
> Leythos <void@nowhere.lan> wrote:
> >In article <87hddtnx2r.fld@barrow.com>, floyd@apaflo.com says...
> >>
> >> But there simply is no such thing as a "residential address
> >> block" that can universally be blocked. Even attempting to do
> >> so based on local patters is a very poor idea.
> >
> >Wrong, there are simple lists available and are often used in RBL's - we
> >use the residential block list to block inbound SMTP to our servers as
> >we don't have any reason for a residential customer to send us email
> >from their workstation, the ISP's SMTP servers are almost always not
> >included in the residential network lookup lists.
>
> It's a very poor idea.

What's poor about it - almost every ISP has a rule that prohibits
residential users from running their own email servers, and since every
residential user can push through their ISP's mail server even if they
use their own internal email server, there is no reason to allow
residential addresses to send SMTP. The real issue is the sooooo many
residential users machines are compromised with viruses that have their
own SMTP engines that anyone not blocking SMTP from residential
addresses is a fool.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 14, 2005 7:06:13 PM

Archived from groups: comp.security.firewalls (More info?)

In article <bfCdnb3T96Ley2LfRVn-ow@giganews.com>, Frank@SPAM2TRASH.com
says...
> >> But there simply is no such thing as a "residential address
> >> block"
>
> > Wrong, there are simple lists available and are often used in RBL's
>
> What is the definition of a "residential IP"?

A residential IP is considered a ISP's range of Dynamic Addresses that
they designate for non-commercial customers. Almost every ISP has a
range for "residential" users that is different for "Commercial" users,
and the nice RBL lists (ones that do Dynamic) identify these very
nicely.

There are also RBL's that do each country, that do the residential, that
do the Dial-Up users ranges for ISP's, and then known spammers on
commercial accounts....

You might want to look up what RBL's are about.

--

spam999free@rrohio.com
remove 999 in order to email me
August 14, 2005 7:06:14 PM

Archived from groups: comp.security.firewalls (More info?)

I know what RBLs are about... for mail. "Real-Time Blackhole List". But
where do you find the databases listing residential IPs?

-Frank

"Leythos" <void@nowhere.lan> wrote in message
news:MPG.1d6927f42034e667989bad@news-server.columbus.rr.com...
> In article <bfCdnb3T96Ley2LfRVn-ow@giganews.com>, Frank@SPAM2TRASH.com
> says...
>> >> But there simply is no such thing as a "residential address
>> >> block"
>>
>> > Wrong, there are simple lists available and are often used in RBL's
>>
>> What is the definition of a "residential IP"?
>
> A residential IP is considered a ISP's range of Dynamic Addresses that
> they designate for non-commercial customers. Almost every ISP has a
> range for "residential" users that is different for "Commercial" users,
> and the nice RBL lists (ones that do Dynamic) identify these very
> nicely.
>
> There are also RBL's that do each country, that do the residential, that
> do the Dial-Up users ranges for ISP's, and then known spammers on
> commercial accounts....
>
> You might want to look up what RBL's are about.
>
> --
>
> spam999free@rrohio.com
> remove 999 in order to email me
Anonymous
August 14, 2005 9:04:51 PM

Archived from groups: comp.security.firewalls (More info?)

In article <p_2dneBMGsFv8GLfRVn-hA@giganews.com>, Frank@SPAM2TRASH.com
says...
> I know what RBLs are about... for mail. "Real-Time Blackhole List". But
> where do you find the databases listing residential IPs?

By understanding the RBL's and how they were formed - in most cases, if
you follow the RBL back to the site that hosts it, or the master site
for the particular RBL, they will give you the ranges. If you search you
will find.

--

spam999free@rrohio.com
remove 999 in order to email me
August 14, 2005 9:04:52 PM

Archived from groups: comp.security.firewalls (More info?)

So... it's a secret?

-Frank

"Leythos" <void@nowhere.lan> wrote in message
news:MPG.1d6943c0b759fc80989bb0@news-server.columbus.rr.com...
> In article <p_2dneBMGsFv8GLfRVn-hA@giganews.com>, Frank@SPAM2TRASH.com
> says...
>> I know what RBLs are about... for mail. "Real-Time Blackhole List". But
>> where do you find the databases listing residential IPs?
>
> By understanding the RBL's and how they were formed - in most cases, if
> you follow the RBL back to the site that hosts it, or the master site
> for the particular RBL, they will give you the ranges. If you search you
> will find.
>
> --
>
> spam999free@rrohio.com
> remove 999 in order to email me
Anonymous
August 14, 2005 9:08:53 PM

Archived from groups: comp.security.firewalls (More info?)

In the Usenet newsgroup comp.security.firewalls, in article
<ddlkiq$9ci$2@news.shlink.de>, Wolfgang Kueter wrote:

>Well, other people seem not so stupid to write instructions that might make
>others lose their jobs.

He's not the first to do so - by a LONG stretch. The Linux 'HOWTO' dates
from 1998, and actually builds on an older document from 1996 or thereabouts.

>I hope for you that you are prepared to get sued by all those people who
>have lost their jobs because they followed your instruction how to violate
>the security policy of their (former) employer.

IANAL - His 'Disclaimer' section at the bottom of the paper can be
considered as wiggle room. He also has a slightly stronger version of
the disclaimer on the URL page he was posting. Is that enough to
ensure avoidance of legal action? HTFSIK! IANAL - consult your own
lawyer in your local jurisdiction.

Old guy
Anonymous
August 14, 2005 9:11:17 PM

Archived from groups: comp.security.firewalls (More info?)

In the Usenet newsgroup comp.security.firewalls, in article
<cLqdnTJjYNt1Q2PfRVn-qA@comcast.com>, Charles Newman wrote:
>
>"Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message

>> I know that you have less of a choice of providers up there, but down in
>> this part of the country, most businesses don't use comcast, verizon,
>
> Well, Comcast is about to launch a high-end business version of their
>cable services. I got a flyer in my last cable bill advertising it. It did
>not say how much it would cost, but only that Comcast is about to introduce
>it in this area.

If you can find a means of querying ARIN (the Regional Internet Registrar
assigned to North America), you'd find a whois query for the word COMCAST
yields over 250 netblocks. Many of these are labeled as

Comcast Cable Communications SACRAMENTO-7 (NET-24-2-32-0-1) 24.2.32.0 -
24.2.63.255
Comcast Cable Communications SACRAMENTO-8 (NET-24-7-128-0-1) 24.7.128.0 -
24.7.191.255
Comcast Cable Communications SACRAMENTO-9 (NET-24-10-0-0-1) 24.10.0.0 -
24.10.127.255

and it should be obvious to you that this doesn't even include your block
in the 67.160.0.0/11 range. That same list includes no less than 79 blocks
listed similar to

Comcast Business Communications, Inc. CBC-BALTIMORE-1 (NET-64-139-92-0-1)
64.139.92.0 - 64.139.92.255
Comcast Business Communications, Inc. CBC-BALTIMORE-2 (NET-66-208-208-0-1)
66.208.208.0 - 66.208.211.255
Comcast Business Communications, Inc. CBC-BALTIMORE-3 (NET-66-208-212-0-1)
66.208.212.0 - 66.208.212.255
Comcast Business Communications, Inc. CBC-BALTIMORE-4 (NET-66-208-214-0-1)
66.208.214.0 - 66.208.214.255

and

Comcast ATWORKHFC-NJ (NET-64-232-72-0-1) 64.232.72.0 - 64.232.73.255
Comcast ATWORKHFC-PA (NET-64-232-220-0-1) 64.232.220.0 - 64.232.221.255

>Comcast wants to be a cheaper alternative for business internet, than
>T-1 service.

See the response from Walter Roberson of NRC. Comcast is actually rather
late into the market compared to Verizon (nee Bell Atlantic), and AT&T,
or even PacBell.

>And that will include a static IP and will allow servers.

and be on a different IP block.

Old guy
Anonymous
August 14, 2005 11:25:14 PM

Archived from groups: comp.security.firewalls (More info?)

In article <gPKdnYx6RJDhCGLfRVn-hQ@comcast.com>,
Charles Newman <charlesnewman1@comcast.do.not.spam.me.net> wrote:

:"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
:news:D dmvca$b6l$1@canopus.cc.umanitoba.ca...

:> - T1 do not degrade with congestion from other users on your block
:> (a significant problem with cable!)

: That is one reason why business-level cable
:costs a lot more, you are not sharing your
:connection with other people. That put one
:connection to a head-end.

If I recall correctly, around here they use -smaller- clusters
for business, but do not promise an exclusive circuit.

:That is why it is
:more expensive, and why they can allow servers
:o n such a connection.

Servers or not is partly a matter of market differentiation.
The transfer limits for the entry business-class cable service are
-lower- than the transfer limits for residential service.
--
This signature intentionally left... Oh, darn!
Anonymous
August 14, 2005 11:26:52 PM

Archived from groups: comp.security.firewalls (More info?)

In article <ddo5qq$1ud$1@canopus.cc.umanitoba.ca>,
Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
:Servers or not is partly a matter of market differentiation.
:The transfer limits for the entry business-class cable service are
:-lower- than the transfer limits for residential service.

To clarify: that lats remark is in the context of the local
cable broadband provider.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
August 14, 2005 11:40:10 PM

Archived from groups: comp.security.firewalls (More info?)

Charles, you are right. You can always stop it by making changes to
your network. But, I am talking about the most general setup. The setup
which works for most of the companies and is a requirement for some of
them.
Anonymous
August 14, 2005 11:42:31 PM

Archived from groups: comp.security.firewalls (More info?)

X-No-Archive: Yes

"Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message
news:slrndfvg7j.5rm.ibuprofin@compton.phx.az.us...
> In the Usenet newsgroup comp.security.firewalls, in article
> <ddlkiq$9ci$2@news.shlink.de>, Wolfgang Kueter wrote:
>
> >Well, other people seem not so stupid to write instructions that might
make
> >others lose their jobs.
>
> He's not the first to do so - by a LONG stretch. The Linux 'HOWTO' dates
> from 1998, and actually builds on an older document from 1996 or
thereabouts.
>
> >I hope for you that you are prepared to get sued by all those people who
> >have lost their jobs because they followed your instruction how to
violate
> >the security policy of their (former) employer.
>
> IANAL - His 'Disclaimer' section at the bottom of the paper can be
> considered as wiggle room. He also has a slightly stronger version of
> the disclaimer on the URL page he was posting. Is that enough to
> ensure avoidance of legal action? HTFSIK! IANAL - consult your own
> lawyer in your local jurisdiction.


In the handful of states that have passed what
are known as Super-DMCA laws, I could see
a possibile criminal violation, but beyond that,
I dont know.
There are all kinds off stautes you can be
violating now, and never even know it, which
is obviously why he put the disclaimer there.
August 14, 2005 11:44:45 PM

Archived from groups: comp.security.firewalls (More info?)

Wolfgang, you sound pretty stupid to me. I don't give a damn. If
somebody is stupid enough to use it just because I say so, I can't do
anything.

My idea is not to encourage somebody. It's just a piece of information.
I am a sysadmin myself and I know the implications of using this.
That's why I have the disclaimer in the paper.
Anonymous
August 15, 2005 2:48:43 AM

Archived from groups: comp.security.firewalls (More info?)

In article <AJOdnfrxL9KN4mLfRVn-qA@giganews.com>, Frank@SPAM2TRASH.com
says...
> So... it's a secret?

Only if you're not capable of looking.

--

spam999free@rrohio.com
remove 999 in order to email me
August 15, 2005 2:48:44 AM

Archived from groups: comp.security.firewalls (More info?)

Either way, I agree with others that this is like pissing into the wind.
Lots of trouble for very little gain and very likely to have a ton of "false
positives", meaning, you can't tell by the IP someone is issued by their IP
if they will send spam or other malicious code, or be hackers.

Sure, you can block everyone that you think has POTENTIAL to send spam or be
hacker, but you will be blocking one hellovalot of valid IPs at the same
time. Your choice. But somewhere there has to be a balance of function
verses security. Blanket IP block blocking seems insane to me.

-Frank

"Leythos" <void@nowhere.lan> wrote in message
news:MPG.1d69945dfebf553e989bb2@news-server.columbus.rr.com...
> In article <AJOdnfrxL9KN4mLfRVn-qA@giganews.com>, Frank@SPAM2TRASH.com
> says...
>> So... it's a secret?
>
> Only if you're not capable of looking.
>
> --
>
> spam999free@rrohio.com
> remove 999 in order to email me
Anonymous
August 15, 2005 2:49:23 AM

Archived from groups: comp.security.firewalls (More info?)

In article <8764u8mhhq.fld@barrow.com>, floyd@apaflo.com says...
> "Frankster" <Frank@SPAM2TRASH.com> wrote:
> >So... it's a secret?
> >
> >-Frank
>
> NO! You merely have to ask... *every* ISP in the world.

What a dufus answer - all you have to do if find the maintainer of the
RBL and ask them.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 15, 2005 3:25:55 AM

Archived from groups: comp.security.firewalls (More info?)

Leythos <void@nowhere.lan> wrote:
>
>You only hear people say it's "pissing in the wind" if they don't know
>how easy it is to do, if they don't really care, if they don't
>understand security and the world.

Seems to me you've just described the folks who *use* it...

>There
>have yet to be any valid business reasons for someone to check their
>personal web server at their house, or their personal email at their
>home or ISP during business hours....

Just another of the blanket assumptions you make that are total
nonsense in a real world filled with people who are *not* all
from the same cookie cutter.

>As for spam, we have more than a dozen filters on most of the clients
>email servers, match lists, RBL's, etc... We catch over 85% and reject
>it before the client sees it, without a single false reject.

"Without a single false reject"... that you notice (with your eyes
closed and your ears plugged).

>When you starting having the responsibility for protecting networks and
>systems "Blanket IP block blocking seems insane to me" will start making
>sense to you too.

There *is* a need and a market for the service you are
providing. But suggesting that is appropriate for all markets
is a bit much.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson&gt;
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
Anonymous
August 15, 2005 5:17:08 AM

Archived from groups: comp.security.firewalls (More info?)

In article <0OadnWwdX95gf2LfRVn-gA@giganews.com>, Frank@SPAM2TRASH.com
says...
> Either way, I agree with others that this is like pissing into the wind.
> Lots of trouble for very little gain and very likely to have a ton of "false
> positives", meaning, you can't tell by the IP someone is issued by their IP
> if they will send spam or other malicious code, or be hackers.

Strictly speaking, you are correct, a Dynamic IP does not mean the host
is a spammer, but, in general, the overwhelming majority of compromised
systems and spam relays are systems on Dynamic IP's and that comprises
the majority of Residential users of ISP.

You only hear people say it's "pissing in the wind" if they don't know
how easy it is to do, if they don't really care, if they don't
understand security and the world.

As a simple example, I have 4 companies that do no business outside the
USA, being that, we include more than 100 foreign subnets in a permanent
block list (some are /24 some are /16 some are /8), but you would be
amazed at how much chatter and probes for exploits that it stops dead.

We also block access to anything that probes 445 for 20 minutes and
several other ports. Since we've not had a compromised customer in all
these years I'm reasonably sure that we have more than just a clue about
how to do this. It's only as hard is you want to make it, and it's very
easy to implement.

> Sure, you can block everyone that you think has POTENTIAL to send spam or be
> hacker, but you will be blocking one hellovalot of valid IPs at the same
> time. Your choice. But somewhere there has to be a balance of function
> verses security. Blanket IP block blocking seems insane to me.

You missed the intent - you block SMTP and other types of connections,
like SSH and HTTP, to the residential networks (outbound, not inbound)
so that people can't reach their HOME networks from the office. There
have yet to be any valid business reasons for someone to check their
personal web server at their house, or their personal email at their
home or ISP during business hours....

As for spam, we have more than a dozen filters on most of the clients
email servers, match lists, RBL's, etc... We catch over 85% and reject
it before the client sees it, without a single false reject. Of the
remaining 15%, 73% is spam and we catch about 80% of that with match
lists and other methods, and rest if good email. Since we record all
rejects and markings as spam, we've not seen one false positive in more
than 2 years..

When you starting having the responsibility for protecting networks and
systems "Blanket IP block blocking seems insane to me" will start making
sense to you too.


--

spam999free@rrohio.com
remove 999 in order to email me
August 15, 2005 5:17:09 AM

Archived from groups: comp.security.firewalls (More info?)

> Strictly speaking, you are correct, a Dynamic IP does not mean the host
> is a spammer, but, in general, the overwhelming majority of compromised
> systems and spam relays are systems on Dynamic IP's and that comprises
> the majority of Residential users of ISP.

I agree that the majority of compromised systems and spam relays have
Dynamic IPs. However, that is not the same thing as saying, the majority of
Dynamic IP systems send spam, or are open relays. Two different statements.
That's why I don't agree with blanket blocking of Dynamic IPs. As a side
note, this is the first time you mentioned Dynamic IPs. Up to now we were
talking about "residential" IPs. Do you consider the terms synonymous?

> You only hear people say it's "pissing in the wind" if they
> don't know how easy it is to do, if they don't really care, if
> they don't understand security and the world.

Disagree. But that's okay.

> As a simple example, I have 4 companies that do no business outside the
> USA, being that, we include more than 100 foreign subnets in a permanent
> block list (some are /24 some are /16 some are /8), but you would be
> amazed at how much chatter and probes for exploits that it stops dead.

You could stop even more if you blocked even more. I don't see that as
surprising. You do this after making a conscious decision to accept more
"false positive" losses. Again, your choice, but not for everyone.

> Since we've not had a compromised customer in all these years
> I'm reasonably sure that we have more than just a clue about
> how to do this.

Well, not saying that you don't have a clue, only that this analogy doesn't
prove that you do. After all, it's easy to avoid having a compromised
customer, just block everything. Doesn't mean it was a smart solution for
that particular customer just because he wasn't hacked.

> When you starting having the responsibility for protecting
> networks and systems "Blanket IP block blocking seems
> insane to me" will start making sense to you too.

I have had this responsibility as an admin and eventually as a manager of an
IT group in a major Aerospace Corp. But, as a manager, I had much more
responsibility than this. I also had responsibility to ensure company
business could be successfully conducted and that my engineers had the tools
and connectivity they needed to be successful and make our company
successful. I had to do risk analysis on most every major configuration
decision. And that is the KEY. Risk analysis. You have to weigh the
potential risk (including potential loss if something goes wrong) with the
potential impact on operations (often spelled reduced income). There are
some cases where this kind of security is necessary, I know. And if it means
throwing some of the babies out with the bathwater, it can be justified,
sometimes. I used to see this all the time in the realm of "National
Security". However, to think that all (or most) systems would benefit by
using security measures this tight is ludicrous to me.

Not to be argumentative. I understand that different folks have different
philosophies. I think we are both entitled to our own, no problem :) 

-Frank
August 15, 2005 10:41:53 AM

Archived from groups: comp.security.firewalls (More info?)

Leythos, you must kidding yourself by repeating this 'improperly setup
firewall' thing. If it's that uncommon, then why the hell you are
worried about people using this technique to break something. Just
forget it dude. Let others worry about it.

Saying that it will work doesn't mean encouraging :)  My disclaimer says
it all clearly.
August 15, 2005 3:27:15 PM

Archived from groups: comp.security.firewalls (More info?)

> In this paper, I discuss a technique to get into your office computer
> using ssh tunneling with some cool tricks.

Man! All in all, bickering aside, this has been a very good thread. In it
you will find a lot of good info, some technical, some philosophical, some
efficiency oriented, but lots of good info. This thread is a very good
example, IMHO, about how there is no such thing as a "one-size-fits-all"
solution and it underscores the need to do a careful analysis of business
and customer requirements, before blindly applying a cookie-cutter generic
solution.

Additionally, by observing the controversy in this thread amongst IT
professionals, it will give you some idea about why it can be so difficult
to interface with other networks. Each network "owner" has their own ideas
about security and network policies. I have spent a good portion of my time
in IT negotiating a consensus amongst network owner to allow some form of
connectivity.

Anyway, interesting stuff I think :) 

-Frank
Anonymous
August 15, 2005 5:23:44 PM

Archived from groups: comp.security.firewalls (More info?)

In article <1124073885.434398.15140@g14g2000cwa.googlegroups.com>,
manugarg@gmail.com says...
> Wolfgang, you sound pretty stupid to me. I don't give a damn. If
> somebody is stupid enough to use it just because I say so, I can't do
> anything.
>
> My idea is not to encourage somebody. It's just a piece of information.
> I am a sysadmin myself and I know the implications of using this.
> That's why I have the disclaimer in the paper.

I hate to say this, but your statement doesn't make any sense - you say
you are "not to encourage", but you provide the instructions on how to
do it on improperly setup firewalls, and you defend it saying it will
work, but you are not 'encouraging' anyone to do it.

If you don't want people to do it, then take down the document and let
your actions show that you don't want to encourage it - if you are just
playing around and really want people to do it, then leave the document
available for all.

If I leave a loaded cannon in out in front of my house, I'm not
"encouraging" anyone, but the law sees it as an "attractive" type thing
where I'm actually encouraging someone to use it.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
August 15, 2005 5:34:44 PM

Archived from groups: comp.security.firewalls (More info?)

In article <KL6dnfaKQ6HikJ3eRVn-vQ@giganews.com>, Frank@SPAM2TRASH.com
says...
> > Strictly speaking, you are correct, a Dynamic IP does not mean the host
> > is a spammer, but, in general, the overwhelming majority of compromised
> > systems and spam relays are systems on Dynamic IP's and that comprises
> > the majority of Residential users of ISP.
>
> I agree that the majority of compromised systems and spam relays have
> Dynamic IPs. However, that is not the same thing as saying, the majority of
> Dynamic IP systems send spam, or are open relays. Two different statements.
> That's why I don't agree with blanket blocking of Dynamic IPs. As a side
> note, this is the first time you mentioned Dynamic IPs. Up to now we were
> talking about "residential" IPs. Do you consider the terms synonymous?

For the most part, residential and dynamic are the same. Even if you've
had the same Dynamic IP for 2 years, it's still dynamic. There are, and
I know, some business services that some of the lamer ISP's provide to
businesses where they don't get a static IP, but, they also don't expect
those same businesses to have inbound traffic - or the business doesn't
understand enough to get a static IP. So, in general, unless it's a
static IP, I consider it to be residential in nature.

> > You only hear people say it's "pissing in the wind" if they
> > don't know how easy it is to do, if they don't really care, if
> > they don't understand security and the world.
>
> Disagree. But that's okay.
>
> > As a simple example, I have 4 companies that do no business outside the
> > USA, being that, we include more than 100 foreign subnets in a permanent
> > block list (some are /24 some are /16 some are /8), but you would be
> > amazed at how much chatter and probes for exploits that it stops dead.
>
> You could stop even more if you blocked even more. I don't see that as
> surprising. You do this after making a conscious decision to accept more
> "false positive" losses. Again, your choice, but not for everyone.

No, we block a lot more, just not that I've posted here. We start with
the approach of allow nothing in or out and then permit only that which
is needed for business purposes - and there are different
rules/permissions for different types/sets of users.

> > Since we've not had a compromised customer in all these years
> > I'm reasonably sure that we have more than just a clue about
> > how to do this.
>
> Well, not saying that you don't have a clue, only that this analogy doesn't
> prove that you do. After all, it's easy to avoid having a compromised
> customer, just block everything. Doesn't mean it was a smart solution for
> that particular customer just because he wasn't hacked.

But why would you allow everything until it causes a problem and then
take action to block it - the best protection is to block everything
that isn't needed. You can't possibly believe that allow all until
compromised and then create rule makes any sense.

> > When you starting having the responsibility for protecting
> > networks and systems "Blanket IP block blocking seems
> > insane to me" will start making sense to you too.
>
> I have had this responsibility as an admin and eventually as a manager of an
> IT group in a major Aerospace Corp. But, as a manager, I had much more
> responsibility than this. I also had responsibility to ensure company
> business could be successfully conducted and that my engineers had the tools
> and connectivity they needed to be successful and make our company
> successful. I had to do risk analysis on most every major configuration
> decision. And that is the KEY. Risk analysis. You have to weigh the
> potential risk (including potential loss if something goes wrong) with the
> potential impact on operations (often spelled reduced income). There are
> some cases where this kind of security is necessary, I know. And if it means
> throwing some of the babies out with the bathwater, it can be justified,
> sometimes. I used to see this all the time in the realm of "National
> Security". However, to think that all (or most) systems would benefit by
> using security measures this tight is ludicrous to me.

I was responsible for the security of 23 offices in two countries with
more than 2000 employees and many road warriors before I started this
company, we never had a single compromise and yet were able to do all
our work, everyone that was selected could work remotely, etc... If you
don't see security as helping 99% of the installations out there, then
you don't belong in the field/business.

I've never seen a properly designed solution degrade business functions,
and in most cases it only improves business functions/productivity. I
have seen many zealous CIO's lock things down to the point of people not
being able to do their work, but those CIO's are usually the ones that
don't understand security, don't understand human nature, don't
understand the business units needs.

> Not to be argumentative. I understand that different folks have different
> philosophies. I think we are both entitled to our own, no problem :) 

There is really only one true way to look at security, anything less is
a compromise and places the network(s) at risk. It doesn't take a lot to
secure a large company or a small office, the methods and ideals are the
same, there is no compromise, the only difference is the size/capacity.

You keep having your "opinion" and I will too, I'm fine with it, I was
just hoping to see you understand that there are no grey areas in
security, only secure and not-secure, and we get a lot of new customers
because of the companies/techs/designers/architects that don't
understand that idea.

--

spam999free@rrohio.com
remove 999 in order to email me
August 15, 2005 5:34:45 PM

Archived from groups: comp.security.firewalls (More info?)

> You keep having your "opinion" and I will too, I'm fine with it, I was
> just hoping to see you understand that there are no grey areas in
> security, only secure and not-secure, and we get a lot of new customers
> because of the companies/techs/designers/architects that don't
> understand that idea.

Well, this can be one we disagree on. To me, there is a lot of middle ground
between secure and not secure.

-Frank
      • 1 / 2
      • 2
      • Newest
!