Penetration Testing mailing list archives
RE: Anonymizing Packets yet ensuring 0 % packet loss
From: "Strykar" <str () hackerzlair org>
Date: Sun, 16 Sep 2007 21:06:24 +0530
I am working with a research Team out of IIT Delhi, the best educational & research center in India, we were having some debate this week were we were asked to break the security infrastructure of our intranet! We have found out that the rules are written based on the ip classes! & the admin classes are given full access! but the problem is that the admins connect to internet over a different internet backbone than ours. So we need the IP adress of a machine to be spoofed permenantly as the admin's ip adress!
1. Administrators are expected to have "full" access, nothing wrong/new in that. 2. You cannot spoof your administrators public netblock, forget permanently, and use that as a pad to find chinks in the security. That's not how TCP works. You may pull off a few probes spoofing his/an address, but the minute you need anything that needs a reply from the network, you're back in the same boat. This is a good primer on the above: http://en.wikipedia.org/wiki/Transmission_Control_Protocol 3. Which rules are written on IP classes, and what's wrong with that? The Internet is made up of machines identified by IP addresses, it's expected that filtering using this very property of IP will be commonplace.
pentest is basically to desribe that i will be conduction network exploration & default pwd enumeration where ever required. I would use the hidden Ip adress to do FTP & other access so that there is no problem in the logs when they are analysed!
If you are authorized to conduct a pen-test, why can't you access the network? <-- You lost 10 points right here. You HAVE to have been given some access, even if this was an argument started over some chai one afternoon. I assume you mean you're going to try to brute force FTP and other services. You can do this from any IP address for public (visible to Interweb) services on the network. Using Tor might help displace a single source as the attacker. As far as the internally accessible services go, start from a terminal inside the network, peeking at the WiFi setup should be your first stop. Test their switches for port security, the list here goes on and on. Why would there be a "problem" in the logs I the logs when analysed? Didn't you just say you were authorized to do this? This sounds shady to me. Irrespective of the IP ranges you connect from, the logs are going to show up anything half-noisy as a brute-force attack. If they have an IPS/IDS in place, that will ring alarm bells before you move finish name strings starting with "AA".
I really appretiate the concern, I would assure you that it is strictly for an academic view point! we are nt testing it on a real world scenario! It is just to make some new n/w rules! and assure that the basics are correct! Just to test the architecture & the technologies that run it... thank you... Expecting some clarity of hw can i go abt it...
If this is an experiment in the interest of academia, and legal, here's a few things you can start with: 1. Find and list the netblocks owned by them, so you know where to start looking. 2. Identify the operating systems and software used for all public services esp. web/mail/ftp/ and see if they are all patched for known vulnerabilities. Make a list and map the entire network on paper. 3. Scan and check them for open services. Check for services running over UDP and IPv6 too, as these are oft overlooked. 4. Build a list of services and check them for known vulnerabilities; simple banner grabbing may be misleading, actually connect and test for versions and capabilities. 5. Ask users/students what the password, network and security policies in place. This will give a good feel of the setup. 6. Present all this with your opinions in a report. - End of friendly academic viewpoint. Remember that the legality of a verbal agreement between you and a network administrator (this is what this seems like to me) to test his network is dicey, and will wind up with you in the soup in a court of law. Port scanning in India is legal, last time I checked; brute-forcing services is not. There's no point delving into exploiting of services for privilege escalation as that definitely moves into areas shaded grey. If this is a contracted pen-test agreement, you should look into getting a qualified person to do this. This is an area which is too vast to be spoon-fed, besides being the ethically right thing to do. Your vagueness on actual results expected from you doesn't help. At best you could run automated vulnerability checks and present their reports - again, grey areas, and no value added to them. The best ones are open source, well there's Core, but it's not something the client's IT team couldn't have done themselves. If you can get less vague than " It is just to make some new n/w rules! and assure that the basics are correct! Just to test the architecture & the technologies that run it...", try, then someone may help with specifics. - 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 ------------------------------------------------------------------------
Current thread:
- Anonymizing Packets yet ensuring 0 % packet loss Vivek P (Sep 13)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Utmost Bastard (Sep 13)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Vivek P (Sep 13)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Utmost Bastard (Sep 13)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Vivek P (Sep 13)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Brett Cunningham (Sep 14)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Vivek P (Sep 13)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Dotzero (Sep 14)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Vivek P (Sep 16)
- RE: Anonymizing Packets yet ensuring 0 % packet loss Strykar (Sep 16)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Vivek P (Sep 16)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Brett Cunningham (Sep 17)
- RE: Anonymizing Packets yet ensuring 0 % packet loss Strykar (Sep 17)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Utmost Bastard (Sep 13)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Dotzero (Sep 17)
- Re: Anonymizing Packets yet ensuring 0 % packet loss Vivek P (Sep 17)