My server is getting hammered with spamming. How do I block these two IP addresses from sending emails? What's the iptables command to block these IP addresses?
http://pastebin.com/vt4qei89
Thanks!
The best way of using iptables for blocking a large number of IP-addresses is by using ipset. It acts as a "database" of IPs, allowing iptables to quickly look up an IP and decide whether to block it or not.
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.
I'm receiving too many requests on my server from different ip addresses. I discovered, watching apache access.log, that all these ip addresses are requesting a specific file (teXeFe.php). I'd like to block the access to all these ip addresses. How can I do it?
How about using the iptables string match ?
Something like,
iptables -I INPUT 1 -m string --algo bm --string "teXeFe.php" -j DROP
I inserted the rule at position one just for testing since I had other rules that matched before this one if it was insterted furhter down the chain. Anyway, you get the concept. You could also be a little more specific in the rule (including the GET /full/url/path etc).
Here is page describing the string-matching filter,
- http://spamcleaner.org/en/misc/w00tw00t.html
And here's another stackoverflow-question about it,
- iptable rule to drop packet with a specific substring in payload
Hope that helps!
The provided solution did not work for me. Here is what did:
iptables -A INPUT -p tcp -m string --string "/path/to/file.php" --algo kmp -j REJECT
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
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.
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).