Defeating Firewalls: Sneaking Into Office Computers From H..

manu

Distinguished
Apr 17, 2004
37
0
18,530
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-firewalls-sneaking-into.html

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

manu

Distinguished
Apr 17, 2004
37
0
18,530
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. :)
 

manu

Distinguished
Apr 17, 2004
37
0
18,530
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>
> Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

---------
Manu Garg
http://manugarg.com
"Truth will set you free!"
 

manu

Distinguished
Apr 17, 2004
37
0
18,530
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!"
 

manu

Distinguished
Apr 17, 2004
37
0
18,530
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!"
 

Frankster

Distinguished
Oct 7, 2004
168
0
18,680
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
 
G

Guest

Guest
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.
 
G

Guest

Guest
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
 
G

Guest

Guest
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>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
 
G

Guest

Guest
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
 
G

Guest

Guest
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.
 
G

Guest

Guest
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
 
G

Guest

Guest
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
 
G

Guest

Guest
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>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
 
G

Guest

Guest
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
 
G

Guest

Guest
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
 
G

Guest

Guest
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.
 
G

Guest

Guest
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.
 
G

Guest

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

"Wolfgang Kueter" <wolfgang@shconnect.de> wrote in message
news:ddlkiq$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.
 
G

Guest

Guest
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>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
 
G

Guest

Guest
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
 
G

Guest

Guest
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>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
 
G

Guest

Guest
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
 

Frankster

Distinguished
Oct 7, 2004
168
0
18,680
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