RE: Anonymizing Packets yet ensuring 0 % packet loss

From: Strykar (str@hackerzlair.org)
Date: Mon Sep 17 2007 - 12:22:09 EDT


> Hi Strykar
>
> thanks for writing back to me! please read inline....
>

No problem.

> Okay! Let me define what is my target so that we can be more specific
> in what we discuss here. The end result that i am looking from this
> exercise of mine is to by pass the security systems in place & prove
> to my authorities that they don't have a proper system in place!
> They are the best, i understand tat point, still i m pretty sure that
> they would have missed something! IBM, SUN SOLARIS, CISCO & MICROSOFT
> directly maintain the infrastructure for IIT delhi & they have blocked
> almost all the fun for the students, you cannot connect outside the
> hostels, cannot set VPNs, Cannot setup LAN chat services, etc etc...
>

To quote someone who works closely with Cisco IPS/IDS, "They don't manage
them directly, no."
A partner/reseller manages their Cisco IPS/IDS devices.

This could work:
for you - They don't seem to have in-house expertise for Cisco.
against you - They've outsourced it to someone who really knows Cisco
devices.

Students aren't allowed access to the Internet?

> hmmm.. i think i understand the basics (may not be the best) ! i
> understand that it is not that easy to tamper with the basics! My
> point of thought was to understand areas where things can be misused
> (not exploited). As the saying goes " Some rules can be bended others
> broken", this is what i am trying to figure out!
>

You cannot bend TCP rules for source IP spoofing.

> No, not exactly, we will be trying any and all possible combinations!
> what so ever it is..
>

For a pen-testing company, you're not very familiar with common terminology
- "trying any and all possible combinations" is called brute forcing.

> My requirement here is to send and receive packet through / as the
> network administrator or anonymous (so that the ip address from which
> we do the attack is not revealed)
>

You need to route/proxy your connections though others to hide your IP.
Tor is an open network you can use for this - this is frowned upon by Tor
operators.
If the administrators are half-competent, they will start red-flagging Tor
exit server traffic and block them the minute they see probes/attacks from
them.
This is will effectively flag/block almost all the Tor network.

Setup your own proxies, do it in countries/netblocks different from your
own.
If this is a non-commercial test, ask friends (on different netblocks) to
allow you to proxy connections via their Internet connection.
Buy cheap hosting and setup your own Tor exit nodes.
Bring them up ONLY when you want to proxy through them, if you keep them
running, they will get cached and may be logged/blocked as detailed above.
Read this: http://tor.eff.org/svn/trunk/contrib/exitlist
Setup as many as you can.

> We do not want the administration to say that " we could have stopped
> you doing this, our logs clearly show your ip addresses scanning the
> network & blah blah" It will become a demerit to us when we have to
> prove them wrong!
>

That's the idea of logging.
Whether you do it from your own IP or a Tor exit node or your own proxy
server.
Stop scanning entire port ranges of the target from a single IP!
See http://insecure.org/nmap/man/man-bypass-firewalls-ids.html
Do select ranges, from different IPs, and spread them out over a week, in
the least.
And definitely do common services (smtp/ftp etc.) from different IPs on
different days as these are closely monitored.
Prepare a plan for this, on paper, before you go about it.

Find out what IPS/IDSs are in use.
Most default IDS/IPS configurations won't ring alarms if you selectively
scan over a week.
Read their default configurations from the vendor or ask here or on the
vendors mailing list.
Try to sound like a prospective buyer/new user.
Many administrators will go with factory defaults and this the first place
you look for evading the firewall/IPS/IDS.

First step complete - service topology.

> Yes i did. we are hereby trying to do it with least possible detection
> & if we are logged it is like "no cover"
>

Refer using proxies above.

> What if each attempt is from different machines at different time. WE
> students run brutus every second day on the administration & web-proxy
> servers (so if the ip is randomly shown, possibility of detection
> becomes minimal)
>

Now you're getting the drift, spread yourself out.
It's hard to filter you from the regular zombies scanning them every day.
Create 'noise' by scanning/connecting from IPs other than your own to make
it harder for them to see your real probes.

> Thanks for that! we are clear how to do pen test! We do it
> professionally as a company for many clients across the world! But i
> appretiate you concern.
> My question was on how to handle the source ip address problem!
>

You were told earlier on the list - Proxies like Tor.
Understand how TCP works, the options available are obvious.
If you are a pen-testing company, you know this - this is basic.
 

> i wil tell my process step by step
>
>
> a. enumerate the services, administration subnets, department subnets,
> library subnets, hostel subnets (already completed)
>
> {Given all subnets operate 24 * 7 * 365 (atleast one node always
> online)}
>
> b. logging enabled on all the services & firewalls, ACS, IDS IPS on
> all entrypoints (CISCO, IBM & SOLARIS manages these)
>
> c. We already have infrastructure to do simultaneous tests & determine
> flaws! but they reveal the source ip (we were caught twice because of
> the ipaddress)
>
> d. WE ARE LOOKING FOR: a solution where my source ip can be spoofed
> but data comes back to my machine {preferably an ip from the admin
> subnet which is off line}
>

Your machine --> Proxy A --> Proxy B --> Target
Target --> Proxy B --> Proxy A --> your machine

Target only sees and logs Proxy B's IP.
Repeat using multiple proxies.

> e. I was told to try Tor, which is underway!, still the problem stays!
> we need to mask the source ip address
>

It's not a problem, it's the design of TCP/IP.
You need to work around this.

> A question (given: the n/w has a single DNS server)
>
> If i poison the DNS server, Will i be able to put myself inside the
> admin subnet (given i know the configuration settings for the
> admins..)...
>

Is the name server authoritative for them?
Find out which name server resolves for the IPS/IDS/logging machines to
start with.
If you can change records there, you MAY be able to look like someone else.

This is exactly why firewalls filter by IP and not names.

This approach isn't trivial, will most likely need you to access the more
than one name server, typically their ISPs DNS - definitely illegal.
What kind of outbound Internet access do you have from the campus network?
It's much easier to spoof yourself inside a LAN than outside of it.
Rules are generally more slack for internal hosts.

> & i would like to know some opensource tool to do DNS spoofing!
>

There aren't any that can do what you're thinking.

Lookup http://monkey.org/~dugsong/dsniff/ and read:
http://www.sans.org/reading_room/whitepapers/dns/1567.php

- S

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:07 EDT