Defeating Firewalls: Sneaking Into Office Computers From H..

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!"
59 answers Last reply
More about defeating firewalls sneaking office computers
  1. Archived from groups: comp.security.firewalls (More info?)

    May I know that "properly setup firewall solution", please!! :)
  2. 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. :)
  3. 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!"
  4. 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!"
  5. 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!"
  6. 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
  7. 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.
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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.
  18. 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.
  19. 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.
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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>
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
  26. Archived from groups: comp.security.firewalls (More info?)

    "Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
    news:ddmvca$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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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:ddmvca$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
    :on 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!
  35. 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
  36. 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.
  37. 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.
  38. 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.
  39. 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
  40. 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
  41. 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
  42. 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>
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
  43. 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
  44. 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
  45. 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.
  46. 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
  47. 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
  48. 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
  49. 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
Ask a new question

Read More

Firewalls Office Networking