[cduke250]

[diagram: my_default_connection_path]
+==============================+
|..................[INTERNET]..................................|
|.........................|..........................................|
|........................\/..........................................|
|.............[GATEWAY+FIREWALL]......................|
|.........................|..........................................|
|........................\/..........................................|
|..................[MY FIREWALL].............................|
|.........................|..........................................|
|........................\/..........................................|
|..........(MY LAN [PC1]-[PC2]-[PC3]).................|
+==============================+


My problem, is when I run nessus or a similar info-sec tool, I like/have to disconnect my PC running the prog from MY FIREWALL. The firewall rules are super-tight so I have to do this or my results will be terribly skewed.

[diagram: my_sec-tool_connection_path]
+==============================+
|..................[INTERNET]..................................|
|.........................|..........................................|
|........................\/..........................................|
|.............[GATEWAY+FIREWALL]......................|
|.........................|..........................................|
|........................\/..........................................|
|..............[PC running sec-tool]........................|
+==============================+

Normally the PC does not have any firewall running. So when I use this sec-tool configuration, I am open to attack from any machines also using the GATEWAY, and open to remote attackers that can bypass the GF (gateway+firewall). The rules on the GF are minimal and are designed for complete internet usage in mind. I do not own(or ownz) the GF.

---------

What I would like to be able to do, is to have a nice shell script that I can start/stop a firewall on the PC running sec-tools. The firewall will have to be such that it won't interfere with any of the sec-tools being used. I'm thinking no firewall on outbound traffic, and just on inbound traffic.

---------

Is this a good idea? How can I do this? Any example scripts? Any pointers or comments? What about setting up a connection on different nic on PC to a syslog type server or snort? Any alternate suggestions would be great.

EDIT: The platforms for the scripts can be either linux (spec. arch-linux then slackware), or any BSD.

[Partizaan]

Why dont u put your own pc in the DMZ en put an little software firewall on it u can disable when needed ? I do it that way.

[KuerbY]

is it a hardware firewall or software firewall, i had the same problem in work some time ago.

so i fixed it with a small iptables script and i put in /etc/init.d/ so i can start/stop it.

iam a bit busy today so dont watch gso often, but you can meet on irc.gso in #gso-chat (little advertisment ;) )

/KuerbY

[cduke250]

Partizaan, on Posted May 13 2005, 01:08 PM, said:

Why dont u put your own pc in the DMZ en put an little software firewall on it u can disable when needed ? I do it that way.

MY_FIREWALL, is seriously locked down. It has a ton of customized firewall code for my setup. So I don't want to mess with it unless I have to.

So there are still a lot of rules that apply to PC1, even when in the DMZ. What I can do is disable snort and other misc tools on the DMZ NIC3 interface on MY_F. To get a tool like nessus to work, I would have to configure a bunch of DMZ pinholes.. basically leaving PC1 running nessus in a nonprotected state.

I want a script that I can hack to fit my situation at any given time (script will be on PC1). I have two nics on PC1 running nessus. (NIC A) is on green trusted network. NIC B is connected to the DMZ. The default setting for both is off. I have to manually start the interfaces using scripts that make sure only 1 interface is up at a time.

So a quick script to start a firewall that doesn't interfere with sec-tools (and can be hacked to fit the situation), is all I need.

+===================================+
|..........................[INTERNET]..................................|
|.................................|..............................................|
|................................\/..............................................|
|...........[GATEWAY+FIREWALL].............................|
|......................|.........................................................|
|.....................\/.........................................................|
|..................|NIC1|....................................................|
|..........[ MY FIREWALL ]..........................................|
|.......|NIC2|.............|NIC3|........................................|
|.........|...........................\..........................................|
|.........|.............................\---> [MY DMZ [PC1] ].....|
|.....[HUB]...................................................................|
|.........|......................................................................|
|........\/......................................................................|
|......[ MY LAN ]........................................................|
+===================================+

KuerbY, on May 16 2005, 05:36 AM, said:

is it a hardware firewall or software firewall, i had the same problem in work some time ago.

so i fixed it with a small iptables script and i put in /etc/init.d/ so i can start/stop it.

(Its a hardened custom OS based off of OpenBSD. )

This is exactly what I'm talking about.. The only difference is that it must have a high-degree of customization so as not to interfere with the sec-tools.

I have a few ideas about how to do this.. but this is my first time trying to fit the firewall around a sec-tools platform in this configuration..

I could run a few of the common sec tools on one of my remote sites, and record the whole activity with no firewall present. Then I could run the same tests from within the DMZ and compare. This will tell me what needs to be fixed on MY_FIREWALL.

After that is running smoothly, I could begin to build a firewall and keep hacking it until it works flawless. I'm also thinking about using tools like ftester, netleak, and other server/client firewall policy enumerating tools to help me get it right.

----------

If anyone could point me in the right direction I'd appreciate it. I'll add the final working solution to this thread for you all when I'm done.

[cduke250]

What do you guys think of using netcat to create a "wrapper" path for nessus?

Quote

Netcat as well can make an outbound connection and then run a program or script
on the originating end, with input and output connected to the same network
port.  This "inverse inetd" capability could enhance the backup-server concept
described above or help facilitate things such as a "network dialback" concept.
The possibilities are many and varied here; if such things are intended as
security mechanisms, it may be best to modify netcat specifically for the
purpose instead of wrapping such functions in scripts.

Speaking of inetd, netcat will function perfectly well *under* inetd as a TCP
connection redirector for inbound services, like a "plug-gw" without the
authentication step.  This is very useful for doing stuff like redirecting
traffic through your firewall out to other places like web servers and mail
hubs, while posing no risk to the firewall machine itself.  Put netcat behind
inetd and tcp_wrappers, perhaps thusly:

www stream tcp nowait nobody /etc/tcpd /bin/nc -w 3 realwww 80

and you have a simple and effective "application relay" with access control
and logging.  Note use of the wait time as a "safety" in case realwww isn't
reachable or the calling user aborts the connection -- otherwise the relay may
hang there forever.

You can use netcat to generate huge amounts of useless network data for
various performance testing.  For example, doing

yes AAAAAAAAAAAAAAAAAAAAAA | nc -v -v -l -p 2222 > /dev/null

on one side and then hitting it with

yes BBBBBBBBBBBBBBBBBBBBBB | nc othermachine 2222 > /dev/null

from another host will saturate your wires with A's and B's.  The "very
verbose" switch usage will tell you how many of each were sent and received
after you interrupt either side.  Using UDP mode produces tremendously MORE
trash per unit time in the form of fragmented 8 Kbyte mobygrams -- enough to
stress-test kernels and network interfaces.  Firing random binary data into
various network servers may help expose bugs in their input handling, which
nowadays is a popular thing to explore.  A simple example data-generator is
given in data/data.c included in this package, along with a small collection
of canned input files to generate various packet contents.  This program is
documented in its beginning comments, but of interest here is using "%r" to
generate random bytes at well-chosen points in a data stream.  If you can
crash your daemon, you likely have a security problem.

The hex dump feature may be useful for debugging odd network protocols,
especially if you don't have any network monitoring equipment handy or aren't
root where you'd need to run "tcpdump" or something.  Bind a listening netcat
to a local port, and have it run a script which in turn runs another netcat
to the real service and captures the hex dump to a log file.  This sets up a
transparent relay between your local port and wherever the real service is.
Be sure that the script-run netcat does *not* use -v, or the extra info it
sends to standard error may confuse the protocol.  Note also that you cannot
have the "listen/exec" netcat do the data capture, since once the connection
arrives it is no longer netcat that is running.

Binding to an arbitrary local port allows you to simulate things like r-service
clients, if you are root locally.  For example, feeding "^@root^@joe^@pwd^@"
[where ^@ is a null, and root/joe could be any other local/remote username
pair]into a "rsh" or "rlogin" server, FROM your port 1023 for example,
duplicates what the server expects to receive.  Thus, you can test for insecure
.rhosts files around your network without having to create new user accounts on
your client machine.  The program data/rservice.c can aid this process by
constructing the "rcmd" protocol bytes.  Doing this also prevents "rshd" from
trying to create that separate standard-error socket and still gives you an
input path, as opposed to the usual action of "rsh -n".  Using netcat for
things like this can be really useful sometimes, because rsh and rlogin
generally want a host *name* as an argument and won't accept IP addresses.  If
your client-end DNS is hosed, as may be true when you're trying to extract
backup sets on to a dumb client, "netcat -n" wins where normal rsh/rlogin is
useless.

If you are unsure that a remote syslogger is working, test it with netcat.
Make a UDP connection to port 514 and type in "<0>message", which should
correspond to "kern.emerg" and cause syslogd to scream into every file it has
open [and possibly all over users' terminals].  You can tame this down by
using a different number and use netcat inside routine scripts to send syslog
messages to places that aren't configured in syslog.conf.  For example,
"echo '<38>message' | nc -w 1 -u loggerhost 514" should send to auth.notice
on loggerhost.  The exact number may vary; check against your syslog.h first.

Netcat provides several ways for you to test your own packet filters.  If you
bind to a port normally protected against outside access and make a connection
to somewhere outside your own network, the return traffic will be coming to
your chosen port from the "outside" and should be blocked.  TCP may get through
if your filter passes all "ack syn", but it shouldn't be even doing that to low
ports on your network.  Remember to test with UDP traffic as well!  If your
filter passes at least outbound source-routed IP packets, bouncing a connection
back to yourself via some gateway outside your network will create "incoming"
traffic with your source address, which should get dropped by a correctly
configured anti-spoofing filter.  This is a "non-test" if you're also dropping
source-routing, but it's good to be able to test for that too.  Any packet
filter worth its salt will be blocking source-routed packets in both
directions, but you never know what interesting quirks you might turn up by
playing around with source ports and addresses and watching the wires with a
network monitor.

You can use netcat to protect your own workstation's X server against outside
access.  X is stupid enough to listen for connections on "any" and never tell
you when new connections arrive, which is one reason it is so vulnerable.  Once
you have all your various X windows up and running you can use netcat to bind
just to your ethernet address and listen to port 6000.  Any new connections
from outside the machine will hit netcat instead your X server, and you get a
log of who's trying.  You can either tell netcat to drop the connection, or
perhaps run another copy of itself to relay to your actual X server on
"localhost".  This may not work for dedicated X terminals, but it may be
possible to authorize your X terminal only for its boot server, and run a relay
netcat over on the server that will in turn talk to your X terminal.  Since
netcat only handles one listening connection per run, make sure that whatever
way you rig it causes another one to run and listen on 6000 soon afterward, or
your real X server will be reachable once again.  A very minimal script just
to protect yourself could be

while true ; do
  nc -v -l -s <your-addr> -p 6000 localhost 2
done

which causes netcat to accept and then close any inbound connection to your
workstation's normal ethernet address, and another copy is immediately run by
the script.  Send standard error to a file for a log of connection attempts.
If your system can't do the "specific bind" thing all is not lost; run your
X server on display ":1" or port 6001, and netcat can still function as a probe
alarm by listening on 6000.

Does your shell-account provider allow personal Web pages, but not CGI scripts?
You can have netcat listen on a particular port to execute a program or script
of your choosing, and then just point to the port with a URL in your homepage.
The listener could even exist on a completely different machine, avoiding the
potential ire of the homepage-host administrators.  Since the script will get
the raw browser query as input it won't look like a typical CGI script, and
since it's running under your UID you need to write it carefully.  You may want
to write a netcat-based script as a wrapper that reads a query and sets up
environment variables for a regular CGI script.  The possibilities for using
netcat and scripts to handle Web stuff are almost endless.  Again, see the
examples under scripts/.

[as0l0]

do you think you might be complicating the issue, when you should mjust move your scanning machine to the DMZ for the duration of the scan?

[cduke250]

Probably.. I'm not very knowledgeable in this area to be honest, and am looking for suggestions..

My main worry is that by using the DMZ through my firewall machine, some weird packets that are sent by my nessus machine will be dropped.

I'm also looking at programs like vtun to create a data tunnel through my firewall machine.

I do something similar to this currently by setting up a data relay on an outside machine elsewhere. I'm just worried that by using proxies like socks or whatever, the results aren't as complete.

[cduke250]

As a side note, using the netcat methods above, quoted from Hobbits nc110.tgz file thats all over, you can capture the exact traffic that is being used by nessus or other tools, thus many times you can reproduce the same exploit just using netcat and some binary you captured and saved in a file.

As long as i'm off topic.. if you want to learn more about netcat, do a thorough search on the net and various repositories for different versions of netcat. Check freebsd, debian, and other opensource platforms and you'll find MANY cool and more powerful versions. Then browse through the netcat.c file and check out all the default disabled options before you compile. netcat is my favorite networking tool.

[as0l0]

cduke250, on Jun 2 2005, 11:09 PM, said:

My main worry is that by using the DMZ through my firewall machine, some weird packets that are sent by my nessus machine will be dropped. 

<{POST_SNAPBACK}>

well, you don't really use a DMZ through a firewall, since the DMZ is beyond the firewall.

[cduke250]

What? I don't understand..

Just because I have a NIC on my firewall machine that is dedicated to the DMZ network, the packets are still routed through my firewall machine.

Anyways, what I have doesn't work the way I want it. any suggestions or examples?

[cduke250]

Ok, I put the computer running sec-tools on the DMZ, which has softer security settings on my firewall. When I run a results-dependant tool like nikto or nessus or sing, from my pc, I first disable snort and iptables for the DMZ NIC.

[Jeremy]

Or make your life easier and setup a stateful firewall. That will allow ALL those scanning tools to work flawlessly.

[dieter]

imho, using a firewall for pentesting screws up results ... especially with udp packets etc.

So I would say: no firewall (at least not on the scanning interface).
You could use a multihomed system and use one interface as "scanning" interface - with no services bound to this interface - and another for "management" interface - with only the "needed" services bound to it (only ssh is needed right ... ;-))

Agree, for windows systems, things get harder to do it like this :-/

regards,
Dieter

[cduke250]

Good advice..

I guess what I ultimately want is a connection to the net that is as close to the backbones as possible.

Or IOW, I want to be as close to the target as possible. Things like proxies/firewalls/gateways can really make a huge difference in your scan results.

dieter-
You understand my problem perfectly. The more hops between you and the target (esp. firewalls) the more packets get dropped, and certain attacks using side-channels or rare protocols won't ever get back to you. A big issue is packets getting dropped or never getting back to you like udp,ipv6,icmp,etc..

A good example is tracerouting using udp,icmp,and tcp. If you do this from multiple looking-glasses you will get different results and sometimes find what you were looking for. ISP service limits many attacks because of those damn worms and viruses and DdoS attacks that caused all of them to start using all sorts of differernt methods like egress/ingress filtering and causes problems by using tight stateful inspection.

Q: How can I get a connection closer to the backbones while maintaining a decent level of anonymity? I mean I don't want a dedicated line that could easily be traced right to me. Anonymity isn't so important because there are known ways to get anonymous with any connection.

I'm thinking more along the lines of not buying a new service, but instead using alternative methods like tunneling and encapsulation to effectively bypass all these problems.

[ me ]<--->[firewall]<--->[isp gateway/firewall]<--->[isp router]<----->[hops]<-->[target]
...|____________________........................................................
......................................|
.................................|..............................................
................................................|
.................................|_____[ shell account/socks5/etc. ]<---->[hops]_______________|

[dieter]

Quote

Or IOW, I want to be as close to the target as possible. Things like proxies/firewalls/gateways can really make a huge difference in your scan results

Then I would put a scanning box just in front of the to-be-tested-network

you - fw - isp - hops - target router -+- target fw (if any) - target network
.....................................................|
.....................................................+ scanning system

This would bypass any fw restrictions between you and the target network. Of course, you'll have to be using 2 interfaces for best results (one with no services bound to it), another with only ssh and iptables on it (so that it's only you connecting to that box).

regards,
Dieter