 lutful Premium join:2005-06-16 Ottawa, ON | reply to Airplane777 Re: Monowall WISP client's data gets past my captive portal ?
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. |
|
 lutful Premium join:2005-06-16 Ottawa, ON
·TekSavvy Solutions..
| 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
·TekSavvy Solutions..
| 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. |
|
 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. |
|
 openbox9
join:2004-01-26 Alexandria, VA
·AT&T Southeast
| said by Airplane777 :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. pinging is part of the ICMP protocol. It does not use TCP/UDP ports.said by Airplane777 :So that terrible data from my neighbor has figured some way around the captive portal. I don't have any experience with m0n0wall, so I can't be much more help. Do you have a BT client installed to test without authenticating to your portal? |
|
 Mike_27 Premium join:2004-05-15 Gardiner, MT
1 edit | reply to Airplane777 said by Airplane777 :So that terrible data from my neighbor has figured some way around the captive portal. I think you have anwsered this yourself in an earlier post.
said by Airplane777 :These neighbor is just associated to my AP. He did not log in via the captive portal. Kick him so he has to authenticate via your captive portal.
Mike |
|
 Airplane777
join:2004-06-20 | reply to openbox9 Hi openbo9:
I don't even know where to get BT. I never had a reason to use it before. |
|
 robbin Premium,MVM join:2000-09-21 Leander, TX | Google for BitTorrent or just go to »www.bittorrent.com |
|
 Airplane777
join:2004-06-20
3 edits | When I download it, do I just go to some other location on the Bit Torrent web site and try to download a music file? I'm not sure that will help me to learn how to block or mitigate it.
I have a suspicion Monowall can't stop or mitigate it. I'll probably have to use deep packet inspection like with Net Enforcer. |
|
 lutful Premium join:2005-06-16 Ottawa, ON
·TekSavvy Solutions..
| reply to robbin Airplane777 kindly sent me his config file and the rules are set to allow those traffic ...
<filter> <rule> <type>block</type> <interface>opt1</interface> <protocol>tcp</protocol> <source><network>opt1</network></source> <destination><any/><port>5000</port></destination> <descr>Block Outgoing TCP data on WISP Interface, coming from WISP subnet using any port, TO any IP using UPnP port 5000.</descr> </rule> <!... and similar rules for UPnP2 port 1900. http-rp-epmap port 593. NetBios ports 135-139 SMB port 445 port 1433 or 1434 ...>
<rule> <type>pass</type><interface>opt1</interface> <source><network>opt1</network></source> <destination><network>lan</network><not/></destination> <descr>Pass any Outgoing data on WISP Interface, coming from WISP subnet using any port, TO any IP (EXCEPT LAN) using any port.</descr> </rule> </filter> |
|