Airplane777
join:2004-06-20
| Monowall WISP client's data gets past my captive portal ?
This was in my thread on APNIC, but I thought this deserved a seperate thread, since the APNIC thread didn't seem to be going in this direction.
This is a thought provoking problem...
My problem here is:
I have people in my neighborhood that are associated to my AP and have gotten DHCP leases from my Monowall, but who have not clicked the "Continue" button on my captive portal (I instituted captive portal), in order to gain access to the Internet. But these people's computers are still passing apparently trashy data into my WISP interface of my Monowall.
I see an IP address that my DHCP has assigned to one of my neighbor's computers. And this IP address is acting as a source and incrementing port numbers trying to get to another IP address out on the Internet that goes to CHINA RAILWAY TELECOMMUNICATIONS CENTER. A bunch of the destination IP numbers that the DHCP IP address tries to go to is to CHINA RAILWAY TELECOMMUNICATIONS CENTER.
Whats really purplexing is that my neighbor's computer was given an IP address from the DHCP of my Monowall...But this computer did not log onto the Internet via the Captive Portal. But the logging information on my Monowall shows that this data is being passed. How can that be?
Seems that the trashy data is bypassing my captive portal?
Thanks for any ideas on how this can happen. |
|
lutful
Premium
join:2005-06-16
Ottawa, ON
| Block traffic to LAN and WISP nets, and then grant access to the internet using firewall rules. Something like this screenshot from »m0n0.myhsr.com/tutorial.html |
|
Airplane777
join:2004-06-20
| Hi Lutful:
I'm going to have to study closer what you posted, but I'm not sure what you posted explains why data can come into my WISP interface.
I figured that the captive portal would act like some kind of firewall for data coming into the WISP interface, if the "continue" button wasn't clicked on. |
|
lutful
Premium
join:2005-06-16
Ottawa, ON | You still need firewall rules. Captive portal only traps HTTP requests to external servers. |
|
Airplane777
join:2004-06-20
3 edits | Are you saying that the trashy data is being passed into my Monowall through the WISP port, but it isn't being allowed out the WAN port to any external server on the Internet?
That might make sense then.
Are you saying that I need some kind of firewall rule to block this trashy data from coming into my WISP interface?...even though this trash data still can't get out onto the Internet (since the captive portal is active)? That might explain why Monowall is logging this data...even though it can't get out to the Internet.
I wish I knew what kind of data it was so I could create a firewall to block it. It is trying to go to some external IP address, specifically using port 80. And the source IP address (as handed out by my DHCP), is always incrementing the port number.
EDIT: In the shot below it wasn't trying to use port 80, but it was trying to use that as a destination port earlier.
Maybe I can do a screen shot and show you. |
|
Airplane777
join:2004-06-20
4 edits | reply to Airplane777
Here is a screen shot. I am showing the heading. And then showing a bunch of the WISP data that looks like it was passed into my WISP interface.
I assume this data was not passed out the WAN port, since the captive portal "continue" button was not clicked on. I know it wasn't clicked on because no one shows up when I do the Status:Captive Portal page.
Look how close together the different times are.
That IP address of 192.168.3.153 has a bunch of different port numbers. Some are incrementing. But some stay the same for several tries...like port 16210.
My DHCP server handed out this IP address to my neighbors computer...even though this neighbor didn't click on the "continue" button, in order to gain access to the Internet.
As a matter of fact, right now I have two neighbors that have obained IP addresses by way of DHCP. But its only this one IP address that seems to be giving problems.
Something wierd is going on with all that data flowing. Would love to find out what is happening.
I guess I could block that IP address from my WISP interface, but my DHCP might hand out a different IP address later on to this same computer. |
|
lutful
Premium
join:2005-06-16
Ottawa, ON
| reply to Airplane777
said by Airplane777  :Are you saying that I need some kind of firewall rule to block this trashy data from coming into my WISP interface? Now I see what you mean. You cannot apply rules before the packets enter the firewall.
But you are blocking them as soon as they enter - so they show up in the log. |
|
Airplane777
join:2004-06-20
| said by lutful :But you are blocking them as soon as they enter - so they show up in the log. I'm really not blocking them from getting into the WISP interface. The green arrow to the left shows they came into the WISP interface. |
|
lutful
Premium
join:2005-06-16
Ottawa, ON
| Sorry - did not look at the log carefully. Please add firewall rules on WISP interface right away.
The packets will still "get into" the interface - you cannot do anything about that in any router.
But they will be blocked and will not "go out" to LAN or WAN. |
|
Airplane777
join:2004-06-20
1 edit | said by lutful :Please add firewall rules on WISP interface right away. The packets will still "get into" the interface - you cannot do anything about that in any router. But they will be blocked and will not "go out" to LAN or WAN. The problem is, I don't know what firewall rules to add in order to block this data at the WISP interface, other then specifically blocking the IP address of 192.168.3.153. That will completely stop the malware on this particular computer from getting in at all. But then my DHCP will probably hand out a different IP address to him a little later and it will start all over again.
Looks like there are too many different IP addresses to block. |
|
openbox9
join:2004-01-26
Alexandria, VA
 ·AT&T Southeast
| Airplane, if I had to make a guess, I'd say that m0n0wall captive portal only works for http requests and that if someone associates with your AP, they can still transfer all other traffic without "authenticating" to your portal. I'd also guess that the .153 address using the port numbers 2549-2558 might be BT traffic since they're all about the same time and the connections are to different IP addresses. Without blocking everything but port 80 or using some sort of MAC or 802.1x authentication, I don't think you'll be able to solve this problem. |
|
Airplane777
join:2004-06-20
1 edit | said by openbox9 :Airplane, if I had to make a guess, I'd say that m0n0wall captive portal only works for http requests and that if someone associates with your AP, they can still transfer all other traffic without "authenticating" to your portal. Hi openbox9:
Thanks much for your reply.
Gee...I never thought about my Monowall being able to pass traffic on ports other then port 80, even though the "Continue" button was not clicked on.
I'm going to try that on my laptop. I'll go to the captive portal page and not click on the Continue button...and I'll try to send an email to myself. That outgoing email will be on another port other then 80. I'll see if that works.
said by openbox9 :I'd also guess that the .153 address using the port numbers 2549-2558 might be BT traffic since they're all about the same time and the connections are to different IP addresses. Without blocking everything but port 80 or using some sort of MAC or 802.1x authentication, I don't think you'll be able to solve this problem. It would be nice if Monowall would let me block based on MAC addresses. Then no matter what IP address my DHCP gives him, he would be blocked.
Gee...after I said that, I realized that I can stop this guy based on his MAC address right in my AP. My AP has that capability. Although if I have a customer with BT, I would prefer not to completely block them. I'd like to just block the BT if possible. I just don't see how to do that with Monowall yet.
There is one good thing though. When I start selling my WISP service, then no one will get an IP address from my DHCP. I'll have DHCP turned off. Then I'll know each person's IP address. Then I can just block the person's static IP address if I notice them sending out "junk" like this...lol.
Maybe one other way to stop this would be a firewall with stateful packet inspection...like Net Equalizer, or Net Enforcer...something with stateful packet inspection. If I understand correctly, then it won't matter about the changing IP addresses or ports? |
|
openbox9
join:2004-01-26
Alexandria, VA
·AT&T Southeast
| said by Airplane777 :I'm going to try that on my laptop. I'll go to the captive portal page and not click on the Continue button...and I'll try to send an email to myself. That outgoing email will be on another port other then 80. I'll see if that works. Don't even worry about going to your captive portal page. The simplest test I can think of is to associate your laptop to your AP and then try to ping anything outside of your network. If you're able to ping, then your portal is not stopping you and it most likely only works for http requests. I'll lay 50:1 odds this is the case  said by Airplane777 :Although if I have a customer with BT, I would prefer not to completely block them. I'd like to just block the BT if possible. I just don't see how to do that with Monowall yet. Good luck on that. If you can figure out an easy and low cost method to block only BT, you'd be a rich man because every ISP in the world would want the technology.said by Airplane777 :Maybe one other way to stop this would be a firewall with stateful packet inspection...like Net Equalizer, or Net Enforcer...something with stateful packet inspection. I don't think stateful inspection is going to help with your problem, especially since m0n0wall already uses stateful inspection. |
|
Airplane777
join:2004-06-20 | Isn't stateful packet inspection at layer 7? I didn't think Monowall could do layer 7 inspection.
I think I read that somewhere. I forget where. |
|
John Galt
Forward, March
Premium
join:2004-09-30
Happy Camp
·CenturyLink
| reply to openbox9
said by openbox9 :said by Airplane777 :Although if I have a customer with BT, I would prefer not to completely block them. I'd like to just block the BT if possible. I just don't see how to do that with Monowall yet. Good luck on that. If you can figure out an easy and low cost method to block only BT, you'd be a rich man because every ISP in the world would want the technology Copyright issues aside...you don't want to block P2P, you want to mitigate its effects on your network.
"Port chasing" is a long row to hoe...you are never done as P2P clients become more adaptive.
I like the method that NetEqualizer uses...
"NetEqualizer's customer base comprises a growing subset of IT administrators that don't feel the need to identify types of traffic explicitly, as long as their impact is kept in check."
»www.ereleases.com/pr/20060905005.html
--
A is A |
|
Airplane777
join:2004-06-20
| After I start to get some customers, I just might utilize a Net Equalizer along with my Monowall.
That will be fair to all, it will throttle back anyone who clogs up the network, and it won't block any p2p...if I understand this correctly.
I'm not sure Monowall can mitigate p2p all that well...other then me having a "catch all" queue with very low weight...as long as the p2p is not using port 80. If port 80 is used by p2p, that would be a real bummer. |
|
Airplane777
join:2004-06-20
4 edits | reply to Airplane777
These neighbor is just associated to my AP. He did not log in via the captive portal.
When I get my WISP going, I'll turn off the captive portal. Right now anyone who authenticates via the captive portal gets an "Introduction" message of who I am and that I will soon offer WISP services in the area.
But even with captive portal turned off, this data will still flow without something like like NetEQualizer to mitigate things.
Doesn't look too good.
I see they are doing a lot of incrementing of the source ports.
Do you guys think this is p2p? Maybe Bit Torrent? |
|
openbox9
join:2004-01-26
Alexandria, VA
·AT&T Southeast
| reply to John Galt
said by John Galt :Copyright issues aside...you don't want to block P2P, you want to mitigate its effects on your network. "Port chasing" is a long row to hoe...you are never done as P2P clients become more adaptive. I totally agree and I didn't mean to imply otherwise. Trying to outright block anything will only fuel the geeks and hackers (not crackers, but maybe them as well) to find another solution. Mitigation and minimizing the effects is definitely the way to go. |
|
Airplane777
join:2004-06-20
3 edits | reply to openbox9
said by openbox9 :Don't even worry about going to your captive portal page. The simplest test I can think of is to associate your laptop to your AP and then try to ping anything outside of your network. If you're able to ping, then your portal is not stopping you and it most likely only works for http requests. I'll lay 50:1 odds this is the case I tried pinging yahoo.com, and it would not ping. It does ping if I authenticate via the captive portal page.
So it looks like it won't let pinging traffic through. What port does pinging traffic use? I'm pretty sure it's not port 80.
I can't even ping my WISP gateway port from my laptop computer, without being authenticated. So that terrible data from my neighbor has figured some way around the captive portal. |
|
Airplane777
join:2004-06-20
1 edit | reply to Airplane777
deleted |
|
