|
imij0607
|
 |
« on: March 19, 2013, 09:49:57 AM » |
|
This might be the right place to ask this question...if not please let me know and I'll redirect.
I'm wondering what kind of scan (hping, nmap, etc) would make it look like the firewall blocked traffic, but the host actually replied to the ping?...meaning the traffic was not dropped by firewall.
|
|
|
|
|
Logged
|
|
|
|
ajohnson
Recruiters
Hero Member
 Offline
Posts: 1057
aka dynamik
|
|
« Reply #1 on: March 19, 2013, 11:20:32 AM » |
|
I don't think there's a straight-forward answer to that. If that condition is possible anywhere, it's going to depend greatly on the make and version of the firewall. You'd have to find some sort of glitch regarding checksums, payload contents, fragment reassembly, etc. Varying the ICMP type may be useful as well (i.e. timestamp instead of echo).
Research network fuzzing, and then compare what gets through with what's in the drop log.
|
|
|
|
|
Logged
|
WIP: GCFA | www.infosiege.net | @infosiege The day you stop learning is the day you start becoming obsolete. |
|
|
|
imij0607
|
|
« Reply #2 on: March 19, 2013, 11:45:47 AM » |
|
right - i definitely need to get a sniffer on that segment...it could be false positive via mis-config of appliances...
|
|
|
|
|
Logged
|
|
|
|
|
chrisj
|
|
« Reply #3 on: March 19, 2013, 03:51:53 PM » |
|
A ping will go through, if you're not blocking ICMP.
|
|
|
|
|
Logged
|
OSWP, Sec+
|
|
|
|
imij0607
|
|
« Reply #4 on: March 19, 2013, 04:39:30 PM » |
|
right - ping would go through but this is port 80 HTTP traffic...that much i know...
technically the firewall is blocking port 80 inbound and outbound...soooo....
lol =)
|
|
|
|
|
Logged
|
|
|
|
|
dark_knight_baby
|
|
« Reply #5 on: March 20, 2013, 12:05:43 AM » |
|
hmmm stealth scans? why not muddying the waters of their log files? like use the Decoy functionality in nmap with matching spoofing of MAC and slowing down your timing....assuming you got target IPs you can do a ZOMBIE technique with Decoy....it will surely slowdown the guys who will try to trace the attack...
just my 2 cents
|
|
|
|
|
Logged
|
Comptia A+ ce
Comptia Security+ ce
currently under going CPTE
|
|
|
|
mrvore
|
|
« Reply #6 on: March 20, 2013, 07:25:13 AM » |
|
SYN Stealth Scan [-sS] in Nmap
To initiate a TCP connection, the initiating system sends a SYN packet to
the destination, which will respond with a SYN of its own, and an ACK, acknowledging
the receipt of the first packet (these are combined into a single SYN/ACK
packet). The first system then sends an ACK packet to acknowledge receipt of
the SYN/ACK, and data transfer can then begin.
SYN or Stealth scanning makes use of this procedure by sending a SYN packet
and looking at the response. If SYN/ACK is sent back, the port is open and the
remote end is trying to open a TCP connection. The scanner then sends an RSTto tear down the connection before it can be established fully; often preventing
the connection attempt appearing in application logs. If the port is closed, an
RST will be sent. If it is filtered, the SYN packet will have been dropped and
no response will be sent. In this way, Nmap can detect three port states - open,
closed and filtered. Filtered ports may require further probing since they could
be subject to firewall rules which render them open to some IPs or conditions,
and closed to others.
Modern firewalls and Intrusion Detection Systems can detect SYN scans, but
in combination with other features of Nmap, it is possible to create a virtually
undetectable SYN scan by altering timing and other options.
I hope this may shed some light on what you are looking for.
|
|
|
|
|
Logged
|
broke user and failed programmer
|
|
|
|
