top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Wifi access points, disallow certail access points through iptables in Android

0 votes
435 views

In my Android system, if I want to setup up some network traffic rules sort of like a firewall to disallow certain access points should I use iptables for this. What is the best approach to do something like this?

posted Aug 13, 2013 by Sumit Pokharna

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

iptables is for IPv4 traffic (not ethernet traffic, not 802.11, not ARP, not IPv6, not ....). So Access Point rules must be done in a complete different layer/control program

answer Aug 15, 2013 by anonymous
Similar Questions
+1 vote

I have a hosted VM with a provider, which I've set up mainly as a private mail server. It needs to be protected by some sort of firewall, but there are several to choose from, apart from just writing rules for iptables by hand. I don't think I'll be needing an extreme amount of rules.

Writing rules for iptables is not something I've done in many years, so I was wondering about using either ufw, shorewall or ferm. Has anyone got any experience with either of these? I'm looking for something that is easy to set up and maintain. A pointer to a good guide on any of these would also be much appreciated, especially one that centers on protecting a machine that doesn't serve as a firewall for an entire network, it only has the one interface.

Any suggestions?

+1 vote

I'm looking at a strange phenomenon that occurs on an iptables firewall. There is a DNAT rule configured that maps a public IP to a private one where a web serve is listening. Normal request operate as expected that is the destination ip is modified to the private one when the request arrives at the firewall and on the response packet the private ip is mapped back to the public one.
What I noticed though is that for some response packets the source ip is *not* mapped back to the public ip and instead tcpdump shows that the packets are sent out with the private source ip. The thing all these packets have in common is that they have the RST flag set.

What could be the reason for this? Is there some particular iptables behavior that could explain this?

+1 vote

Recent versions of the Linux kernel and the libnftnl library define nft expression types with the names "match" and "target". However, I could not find any reference to these expression types in the code of the nft user space utility, but only in the code for iptables.

Is it possible to access iptables matches and targets from rules defined with nft, or is this not intended?

0 votes

I have been using denyhosts for almost a year. To date I have only prevented one person logging in and that is ME ( I used the wrong login name).
Also, I know of no successful break-ins.

My iptables is as follows:

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N block
-A INPUT -j block
-A FORWARD -j block
-A block -i wifi_card -p tcp -m tcp --dport 12123 -j ACCEPT
-A block -i Nic_external -p tcp -m tcp --dport 12123 -j ACCEPT
-A block -i Nic_enternal -j ACCEPT
-A block -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A block -i lo -m conntrack --ctstate NEW -j ACCEPT
-A block -j DROP

First, I think that the above will keep the bad guys out, Is that a true statement?

Sencondly, I have added a LOG rule just above the DROP rule and I have been monitoring it for about 1 1/2 weeks. As each entry is logged I have been adding it to /etc/hosts.deny. Currently there are 4318 ip adresses in the file and the number of packets that have been logged is 51592.

Denyhosts is for stopping ssh attempts and nothing else as I understand it.

Having over 4300 lines in /etc/hosts.deny causes almost no delay in logging in remotely.

Am I being to paranoid about keeping the bad guys out or is the iptable above completely adequate?

I would very much like to here your opinion on this,

...