Nick8Premium
join:2001-03-17
UK | Tiny testing - strange results?? I just wrote this out once and forgot I included a PRE tag - didn't close it, pressed back, no post  . Anyway, following a discussion with mhoward I decided to test Tiny to see how it would respond to non TCP,UDP,ICMP TCP/IP protocols... I planned on using hping2 but never actually got around to it because the code for the -H option (IP protocol for raw IP packets) is bugged. Nevertheless, while messing with hping when I found something I think is weird.....
I had "log packets to closed ports" ticked in Tiny with logs written to a file and sent to a syslog daemon. I first tried a few TCP SYN probes against random ports on a Tiny'd machine - no problems, no responses were received (stealthed) and the probes were logged.
Then I tried probing with TCP with no flags set (a violation of the standards) and to my surprise I received RST / ACK set responses (with standard windows sequence no. and ID incrementation). No logs were generated.
The same occurred with other probes with incorrect flags (ACK, FIN, PUSH, etc.) - standard responses and no logs.
UDP probes were dropped and logged properly, like SYNs.
It looks to me as though Tiny only drops UDP and SYN flagged packets (and ICMP). It makes me wonder whether Tiny is letting the other probes hit the OS as opposed to blocking them itself, as the responses were very "windows" like.
I thought the behaviour may be due to the hpinging machine being in a trusted subnet - so I spoofed the source address and the same responses were ready to leave my router out to the spoofed address, if not for filters there.
Turning off "log packets to closed ports" and setting up a deny rule for TCP on an arbitary port with logging enabled produced no logs when the relevant port was probed (SYN or not!!). The packets were dropped (silently) when SYN flagged.
I have tried this on both W98 and ME machines with the same results, can someone else recreate it on theirs??
It's late here and I'm pretty tired, I'm not sure that these observations are significant. However, they have several (not very severe) consequences as I see it:
-> Tiny is not stealthed against anything other than ICMP, UDP and TCP SYN / connection scanning. There is not enough control to stealth against others with filters (in Tiny).
-> OS detection is trivial.
-> It's possible to use a Tiny protected machine as the dummy IP for spoofed probes. The attacker TCP probes (non SYN) you and watches the id field of the responses while he sends probes to the victim, purporting to be you. This activity would not be logged by Tiny.
-> Many portscans are not logged by Tiny and logging a deny rule seems to produce nothing.
-> It's easy to silently determine if you are sending or receiving traffic and hence your suitability for note 3 (a silent computer is ideal but not strictly necessary). This is also the basis of the method of seeing the results of probes in note 3.
-> Possible implications for (raw socket) listeners and triggering with non SYN TCP packets (too late to think).
-> Others I'm too tired to think of....
Despite these, the computer is still secure against inbound connections (and out  ). Just thought that the responses were strange and wanted to know if anyone can verify this or clear it up..... |
|
Nick8Premium
join:2001-03-17
UK | Any comments at all? |
|
|
|
 N9ZNSecurity Is A Community Effort
join:2001-03-29
Tampa, FL
| reply to Nick8
Hold on let me think about this, I just read it 12:02AM on sunday morning.
I am in the process of setting up to evaluate this. I can say just on the surface Tiny should be rejecting anything outside of protocol.
This brings me to another point, which is why would Microsoft allow a response to an invalid packet request. You may have hit a home run on this one.
I'll go ahead and subject Tiny to some test here and get back to you ASAP. Thanks for the response and the time.
[text was edited by author 2001-06-24 03:40:11] |
|
 WildcatboyPremium,Mod
join:2000-10-30
Toronto, ON
kudos:2
Security Product V..
Security
| reply to Nick8
You're correct mbcx8nlp, Tiny doesn't catch or log FIN/PSH/URG/ ... (Neither does ZA I believe). In fact only high priced enterprise package firewalls do that. Using ZA or Tiny on Windows machines, I'm not sure if it's really important to implement those rules either. Creates lots of overhead and you are not accomplishing much either.
The reason I'm saying this is that Windows machines don't follow the common protocols (surprise surprise) and probably for the first time this lack of standard in Windows machines is proving to be useful.
The common standard is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets.(RFC 793). But Windows machines decide to ignore the packet either way, which means even if the port is closed on a windows machine, it shows as open if you do a FIN scan. That makes a FIN scan almost useless on a Win machine.
To make matters even worse (but funny nevertheless) let's say you send a FIN/PUSH/URG to a closed TCP port. Most implementations will set the ACK to be the same as your initial sequence number, but Win machines are totally wacky Sometimes they send back your sequence, other times they sends S++, and other times they send back a seemingly random value. How on Earth MS people coded their machine, one seems to wonder.
Some would say this feature could be used for finger printing, In other words if you scan a machine and show ports as being closed and then do a FIN scan and ports show as open, then you can conclude that it's a Win/NT box and not a *NIX machine, but even that is not true, because some printers do the same, so do Cisco boxes, BSDI, HP/UX, MVS and IRIX. |
|
| said by Wildcatboy:
The common standard is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets.(RFC 793).
I'm curious why RFC defines such behavior. I just looked at RFC793, but still have no clue.
Could you enlighten me a little bit?
Thanks,
-- wiregauze |
|
WildcatboyPremium,Mod
join:2000-10-30
Toronto, ON
kudos:2 Host:
Security Product V..
Security
|
RFC 793 defines TCP's Protocol specifications. I mentioned it in case people are interested in the actual specifications. The Event processing description starts from page 52 and discusses the events that can occur such as user calls (open/send/ ...), Arriving segments and timeouts. The mentioned behaviour is suggested on page 66.
|
|
 SentinelPremium
join:2001-02-07
Florida
kudos:1 | reply to Nick8
mbcx8nlp,
Does a hardware router such as a Netgear do better on the same tests? Just wondering if we have some first solid proof that a hardware router/firewall is better than a software solution.
--
~AL~ |
|
Nick8Premium
join:2001-03-17
UK | Thanks for clearing that up WCB... I can see the point about unnecessary overhead but considering how the MS TCP/IP stack often responds to malformed packets, it's probably worth it . Seriously tho, the number that would have to be filtered and logged would be low (I wouldn't know this if I relied on the logging of Tiny ).
I think OS detection is trivial - the id (initial sequence no.) field of windows replies increases by 256 with each packet, combine with the sequence number incrementation and it's a fair guess . If the machine is making / receiving connections at the time of probing it would be more difficult.
Software firewalled machines could be an easy target for use in the techinique outlined here (uses id incrementation and TCP probes with non-SYN probes to 'read' it). There must be a large amount of people with windows machines and personal firewalls who leave them connected at night - nice method to scan, spoof and receive the results .
Using a combination of SYN and non-SYN probes, you could determine the use of a software firewall (and a windows machine) and then structure any subsequent probes so as to avoid logging - don't bother spoofing or slowing your probes to a snails pace.
Al - I am not sure how the antiprobe feature works in the new firmware but DrTCPs filters prevent my ZyXEL (no 3.x firmware ) from sending out the RST flagged responses. I will test without the filters to see if the drop option drops strangely flagged probes (and see how the id field increments if it doesn't) although I am confident that it will...
WCB is probably correct about the reason for not filtering the non-SYN flagged packets - they don't pose a security risk as such and filtering them would add some overhead and increase the size of program. |
|
 TheGiantNext Year Is Here.
join:2001-03-28
Augusta, GA | reply to Nick8
Okay, So do I worry about all this or not? If someone was able to get in they still couldn't get back out right?
Thanks one paranoid Chicken! |
|
| reply to Nick8
To run your firewall through test with ICMP and IMGP fragment packets just go to »www.pcflank.com/ and run Advanced Test in Test Your System section... My Zone Alarm defended all the attacks... |
|
Nick8Premium
join:2001-03-17
UK | rooster69 - basically no you are protected against inbound and outbound connections. Someone can not "get in" (or out) as a using the packets which the firewalls ignore.
The only consequences are that of gaining information about your system and use of your IP address for spoofed probes - not too likely. Neither present any risk to the security of your system directly.
Mangust - thanks for the link, I have determined that Tiny does indeed pop-up alerts and log IGMP traffic (by accident while trying to create a TCP no flags packet ). The driver defintely sits lower than the TCP/IP stack since it quoted the stack as the recipient. Why can't it do the same for non-SYN flagged TCP?? I have yet to test it's response to other protocols... |
|
 gwionwild colonial boyPremium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1 | reply to Nick8
Another good thread. My comments at the alternate stacks discussion are incorporated by reference...
No firewall's perfect. Does that mean we sit on our hands, and don't try to discover the weaknesses? Of course not. Forewarned is forearmed. I think it's important to remind the people who can't audit their own firewalls, or wouldn't know where to begin, that this is certainly not a call to arms or a paniced discovery of some deep horror that leves anyone wide open. We don't want any false security, but we don't want false insecurity, either. That's just as dangerous, since a paniced misapprehension can cause us to make wrong decisions, too.
Very well done, fellows. Just the kick in the pants I needed to start looking at my own setup. It's great to see this kind of proactive and articulate testing and discussion. Whether or not we do it, be sure the enemy does. We need to stay at least one step ahead of 'em, and this is a good way to start.
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill |
|
