I have a switch configured to mirror all traffic to an ethernet interface of a server. I can actually see the packets received with tshark, tcpdump, etc, but iptables doesn't seem to see this traffic. My ultimate goal is to ulog syn packets for connection accounting.
I tried to place rules in PREROUTING chain, unsuccessfully.
Can iptable capture packets not sent to the local machine? If no, is there a way to do this?
Which table do you use for monitoring?
What you want to do is to use the filter table (the default one) and the FORWARDING chain: it is specifically designed to capture packets which "traverse" the machine. For instance:
iptables -A FORWARDING -p tcp --dport 80 -j LOG
The INPUT chain will capture packets from the outside destined to the local machine, and the OUTPUT chain will capture packets originating from the machine and going outside.
One side note: packets transiting through loopback go through both INPUT and OUTPUT chains.
As to PREROUTING, it is a chain meant to modify packets, if necessary, before the routing decision -- this is why, for instance, port redirection is done in there. And this is why the filter table has no hook in it: it does not make sense.
iptables will only work with IP packets somehow directed at your machine. So what you are trying to achieve will not be doable with iptables. For it to work would require that you set up your accounting machine as a router for all IP traffic.
What’s wrong with tcpdump for this task?
tcpdump -G 3600 -w tcpsyn-%FT%T.pcap tcp and 'tcp[tcpflags] & (tcp-ack|tcp-syn) = tcp-syn'
If you want all TCP initiation attempts.
tcpdump -G 3600 -w tcpsynack-%FT%T.pcap tcp and 'tcp[tcpflags] & (tcp-ack|tcp-syn) = (tcp-ack|tcp-syn)'
If you want all TCP sessions actually established.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 20 days ago.
Improve this question
I have an application where a device is sending UDP traffic to a Linux box where it gets replicated using UDP samplicator and sent to multiple other devices for analysis. The UDP samplicator is configured to preserve the source addresses of the original incoming packets when they get replicated. That part works perfectly.
I use iptables on the samplicator box today to selectively not forward UDP traffic from certain sources to specific analysis targets because some of the analysis targets only need to see data from certain devices, and that also works perfectly.
Where I'm running into trouble is that there are a few devices that I need to re-write the source addresses on their incoming UDP traffic to overcome some limitations with one specific device vendor. The easiest way to overcome this limitation that I can see would be to use iptables on the samplicator to re-write the source address on incoming UDP packets from device 10.1.2.3 before those packets get replicated to the analysis targets so they see the traffic coming another address, such as 10.4.5.6.
Since this is UDP and the analysis targets are not directly responding to the UDP packets they receive from the devices, I don't need to worry about translating traffic bi-directionally.
10.1.2.3 = IP address that the device's UDP traffic is coming from
10.4.5.6 = The IP address that we need to see it coming from
10.7.8.9 = one of the analysis targets
I tried this on my samplicator box:
sudo iptables -t nat -A POSTROUTING -p udp -s 10.1.2.3 --dport 6343 -j SNAT --to-source 10.4.5.6:6343
however on the analysis targets, I still see lots of UDP traffic coming through with source address 10.1.2.3, and nothing with 10.4.5.6.
$ sudo tcpdump -n -i eth0 host 10.1.2.3 and port 6343
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:02:56.443038 IP 10.1.2.3.19147 > 10.7.8.9.6343: sFlowv5, IPv4 agent 10.1.2.3, agent-id 2, length 276
19:02:56.914536 IP 10.1.2.3.55326 > 10.7.8.9.6343: sFlowv5, IPv4 agent 10.1.2.3, agent-id 1, length 1336
I tried a few other options in iptables, but none seemed to work. Any insight anyone could offer regarding how to get the NAT working correctly would be greatly appreciated.
POSTROUTING means: happens after routing. Two conditions that are not met (nor wanted): you receive traffic with tcpdump before (so you'll never capture this change with this tool) and there is no routing at all involved since the samplicator local process is the destination. If you routed them (in PREROUTING, allowing only DNAT, not SNAT), samplificator would be bypassed, not what you'd want either.
Don't despair, NAT is not used only with routing. You can still NAT the source destined to a local process. tcpdump will still happen before (because it's using RAW sockets) so will see the original source ip and not help with debugging, but your application, as long as it's not using SOCK_RAW to receive traffic, will see the altered source. I checked samplificator's source, it looked like it is receiving packets like usual applications (AF_INET, SOCK_DGRAM).
so the right command should use INPUT, not POSTROUTING:
iptables -t nat -A INPUT -p udp -s 10.1.2.3 --dport 6343 -j SNAT --to-source 10.4.5.6:6343
It's easy to debug and test if you use netcat in verbose mode instead of samplificator (nc -n -v -u -l -p 6343), it will tell you the source seen.
We have a number of iptables rules for forwarding connections, which are solid and work well.
For example, port 80 forwards to port 8080 on the same machine (the webserver). When a given webserver is restarting, we forward requests to another IP on port 8080 which displays a Maintenance Page. In most cases, this other IP is on a separate server.
This all worked perfectly until we installed bridge-utils and changed to using a bridge br0 instead of eth0 as the interface.
The reason we have converted to using a bridge interface is to gain access to the MAC SNAT/DNAT capabilities of ebtables. We have no other reason to add a bridge interface on the servers, as they don't actually bridge connections over multiple interfaces.
I know this is a strange reason to add a bridge on the servers, but we are using the MAC SNAT/DNAT capabilities in a new project and ebtables seemed to be the safest, fastest and easiest way to go since we are already so familiar with iptables.
The problem is, since converting to a br0 interface, iptables PREROUTING forwarding to external servers is no longer working.
Internal PREROUTING forwarding works fine (eg: request comes in on port 80, it forwards to port 8080).
The OUTPUT chain also works (eg: we can connect outwards from the box via a local destination IP:8080, and the OUTPUT chain maps it to the Maintenance Server IP on a different server, port 8080, and returns a webpage).
However, any traffic coming into the box seems to die after the PREROUTING rule if the destination IP is external.
Here is an example of our setup:
Old Setup:
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080
iptables -a FORWARD --in-interface eth0 -j ACCEPT
iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
New Setup: (old setup in various formats tried as well..., trying to log eth0 and br0 packets)
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080
iptables -a FORWARD --in-interface br0 -j ACCEPT
iptables -t nat -A POSTROUTING --out-interface br0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
Before changing to br0, the client request would go to server A at port 9080, and then be MASQUERADED off to a different server $MAINTIP.
As explained above, this works fine if $MAINTIP is on the same machine, but if it's on another server, the packet is never sent to $MAINTIP under the new br0 setup.
We want the packets to go out the same interface they came in on, MASQUERADED, as they did before we switched to using a single-NIC bridge (br0/bridge-utils).
I've tried adding logging at all stages in iptables. For some reason the iptables TRACE target doesn't work on this setup, so I can't get a TRACE log, but the packet shows up in the PREROUTING table, but seem to be silently dropped after that.
I've gone through this excellent document and have a better understanding of the flow between iptables and ebtables:
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
From my understanding, it seems that the bridge is not forwarding the packets out the same interface they came in, and is dropping them. If we had a second interface added, I imagine it would be forwarding them out on that interface (the other side of the bridge) - which is the way bridges are meant to work ;-)
Is it possible to make this work the way we want it to, and PREROUTE/FORWARD those packets out over the same interface they came in on like we used to?
I'm hoping there are some ebtables rules which can work in conjunction with the iptables PREROUTING/FORWARD/POSTROUTING rules to make iptables forwarding work the way it usually does, and to send the routed packets out br0 (eth0) instead of dropping them.
Comments, flames, any and all advice welcome!
Best Regards,
Neale
I guess you did, but just to be sure, did you add eth0 to the bridge?
Although, I am not sure what the problem is, I will give some debugging tips which might assist you or other when debugging bridge/ebtables/iptables issues:
Make sure that "/proc/sys/net/bridge/bridge-nf-call-iptables" is enabled (1)
This cause bridge traffic to go through netfilter iptables code.
Note that this could affect performance.
Check for packet interception by the ebtabels/iptables rules,
Use the commands:
iptables -t nat -L -n -v
ebtables -t nat -L –Lc
This might help you to understand if traffic is matched and intercepted or not.
Check that IP NAT traffic appears in the conntrack table:
conntrack –L (if installed)
Or
cat /proc/net/nf_conntrack
Check MAC learning of the bridge
brctl showmacs br0
Use tcpdump on the eth0 and on br0 to check if packets seen at both as expected
Use the –e option to see MAC address as well.
For debugging, try to put the bridge interface in promiscuous mode, maybe the bridge receives packets with different MAC address (in promiscuous mode it will accept different MAC as well)
Maybe set bridge forward delay to 0
brctl setfd br0 0
And disable stp (spanning tree protocol)
brctl stp br0 off
What is your routing table looks like?
Try adding specific or default route rule with "dev br0"
I hope it helps a bit…
Good luck
Well only 1.5 years old but could be useful for later lookups. Looking at your link just now, it says specifically there brouting will ignore the packet, if MAC is on same side of bridge (and not another port or the bridge itself (see fig 2.b in your link).
Adding to that, I simply quote from this link: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxBridge
"... ebtables DROP vs iptables DROP
In iptables which in most cases is being used to filter network traffic the DROP target means "packet disappear".
In ebtables a "-j redirect --redirect-target DROP" means "packet be gone from the bridge into the upper layers of the kernel such as routing\forwarding" (<-- relevant bit!)
Since the ebtables works in the link layer of the connection in order to intercept the connection we must "redirect" the traffic to the level which iptables will be able to intercept\tproxy.
ANd therein is your answer (bet added for future visitors of course, unless you are still at it ,p)
I'd like to make SSH-identification a little stronger using iptables extensions (or IPSec tools?) for marking (while sending) and matching (while recieving) the packets between my laptop and my server.
I need no VPN, just to send additional information in IP Options header (or in the AH field?).. while talking to server.
It would be nice if it could be possible by using iptables plugins for Debian only (to first alter the headers and then compare the key inside on my remote host).
I googled for a day and found such topics as Inspect protocols AH and ESP for content; Using iptables string-matching filter; Payload mangling etc - but for a now I could not understand the most important thing: which packet to install for Debian on both computers:)
My dream is to block connections using iptables on port 22 (which have no signature inside) before the SSH handshake starts. Can you help me, please?
I did my homework again, and gurus online told me to use the ToS field, "which remains the same while being transmitted over global networks".
An example how to set it:
iptables -t mangle -A PREROUTING -p TCP --dport 22 -j TOS --set-tos 0x10
And it's a very small field (256 bits), filled up with the service information, so there is no much room to play with and you must be very careful. But still!..
Later then the ToS value can be read on the receiving machine using something like
iptables -A INPUT -p tcp -m tos --tos 0x16
It seems I don't understand IPTABLES logic.
I reinstalled ubuntu server 11.10 on my server and turned on forwarding (net.ipv4.ip_forward=1 in /etc/sysctl.conf). Server has two network interfaces - eth0 (ip 192.168.1.1) looks to local network and eth1 (ip 213.164.156.130) looks to internet.
There's also another computer in local network with ip 192.168.1.2.
Then I added two simple rules to ITABLE *nat:
-A PREROUTING -i eth1 -j DNAT --to-destination 192.168.1.2
-A POSTROUTING -o eth1 -j SNAT --to-source 213.164.156.130
I thought that the first rule means forwarding every incoming packet to 192.168.1.2.
But if I run "ping google.com", "wget google.com" from server, they successfully work. Server receives packets and doesn't do forwarding, and I'm really stuck with this.
In case I run these commands from 192.168.1.2 they also work, that means here forwarding works.
These are NAT rules.
In your first rule, address translation occurs before routing the packet. You're changing the destination address to 192.168.1.2 and in the second rule, you're changing the source address before routing to 213.164.156.130.
I'm guessing you can ping & wget because your INPUT and OUTPUT chains have a default action.
TBH, I'm confused about what you actually want to do but if you want to forward packets, you need to modify the FORWARD chain. Here's a link for detailed and helpful information on iptables so you can understand the logic better - Ch14:_Linux_Firewalls_Using_iptables">http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:Ch14:_Linux_Firewalls_Using_iptables.
Here is the situation.
We have multiple server on our intranet 192.168.1.0/24
One of them is the default gateway for all of them and have two interfaces ($GATEWAY_INTERNAL_IP and $GATEWAY_EXTERNAL_IP).
We have also another server PUBLICHOST2 which has two IP as well $PUBLICHOST_EXTERNAL_IP and $PUBLICHOST_INTERNAL_IP.
We have a third server SERVER which have only one IP $PRIVIP and bind on port $PORT.
What we want is to be able to forward port $PORT on $PUBLICHOST_EXTERNAL_IP to host SERVER on $PRIVIP.
But when we do the port forwarding using iptables on PUBLICHOST2, SERVER receive the request but the response goes through the gateway and the connection is not successfull.
How can we properly do the setup so that the response can go back through PUBLICHOST2 ?
Thanks
You may need to set forwarding on for the interface. Try tne command.
sysctl -w net.ipv4.conf.eth0.forwarding=1
If you need additional help look for documentation on routeback or the Shorewall FAQ.
Well here what happens:
Client1 sends a request to PublicHost
The requests arrives and the iptables rules redirects the traffic (PAT) to the Server on the correct AppPort
Server sends back a reply to Client1 which will be routed by Gateway
Gateway is doing NAT and replaces the source IP with it's own
Client1 or Client1sGateway receives the IP packet with Gateway as the source but it expected PublicHost's IP in the source field of the IP packet.
Eventually Client1 resends the SYN/ACK (except if you're using a synproxy) to PublicHost and then drops the connection when whatever network related timer expires.
Now if you want to fix this, you should route all TCP traffic going OUT of Server and with a source port of AppPort to PublicHost.
If this doesn't work, PublicHost is not properly configured. Be sure to test the configuration with tcpdump.
I've been trying to do something similar. After running through a bunch of tutorials that never seemed to work until I Wiresharked the connection to discover that the destination address was still set to the external IP address, (exactly like you've described), I tried using the POSTROUTING chain to change the source IP address to that of the server:
iptables -t nat -A POSTROUTING -p <tcp/udp> --dport <destination_port> -j SNAT --to <$PUBLICHOST_INTERNAL_IP>
After I added that rule, the connection was forwarded into the private network and the response packets retraced the same path back to the client, rather than through the network gateway. I'm not positive what allowed the response packets back out through the firewall server, but I think it was because of the rule I already had on the INPUT chain to allow established connections:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
The thing to be sure to keep in mind with this solution is: if you ever change the firewall server's internal IP address, then you will need to update the above POSTROUTING rule. (Needless to say, it's probably best if the firewall server has a statically assigned internal IP address).