In FreeBSD, there is a kernel parameter tweakable via sysctl (net.inet.tcp.log_in_vain) that provides you with logs of attempted connections to ports which are not running a service (i.e. closed ports). These messages are logged to /var/log/messages (somewhat) in the following format:
2014-06-26 13:18:58|218.77.79.43|58848|192.168.192.28|443|tcp_input: Connection attempt to closed port
Without forwarding all connections from router to my FreeBSD box, I get these messages on a regular basis. How is this happening if I haven't explicitly created port-forward rulesets redirecting traffic to this box on the router?
I'm looking to set up something similar using iptables, reducing as much noise as possible e.g. only see connections for those originating outside of my network as src and ignore any outgoing.
I was attempting to use something like the following to do this:
iptables -I INPUT -m state --state NEW -j LOG --log-prefix "New Connection: "
I'm pretty sure this syntax is fairly outdated. I come from an IPF world so I'm not quite up to speed with the latest iptables syntax conventions.
This rule is generating the type of logs I'm looking for in /var/log/messages:
Jun 28 00:38:12 kermit kernel: [ 6331.339928] New Connection: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:a8:86:dd:8a:c9:26:08:00:45:00:00:48:e8:3f:00:00:40:11:8f:ec │
SRC=192.168.192.40 DST=192.168.192.255 LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=59455 PROTO=UDP SPT=57621 DPT=57621 LEN=52
Thus far, I haven't seen any connections from outside of my own network. Additionally, I can see SSH login attempts in /var/log/auth.log which are not appearing in /var/log/messages using the above iptables rule:
Jun 28 09:31:42 kermit sshd[10097]: pam_unix(sshd:auth): check pass; user unknown
Jun 28 09:31:44 kermit sshd[10097]: Failed password for invalid user admin from 116.10.191.187 port 40312 ssh2
Is it possible using iptables to create the following:
A rule/ruleset which logs all incoming connections to my box to /var/log/messages
Don't log any connections originating from within my own network
Don't log any outgoing connections
Am I required to forward all connections on the router to my box in order to get similar log messages as I did in FreeBSD? (i.e. port-forward all ports)
I found the following (basic) rulset did what I was looking for:
# Generated by iptables-save v1.4.14 on Sat Jun 28 14:02:33 2014
*filter
:INPUT ACCEPT [586:43405]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [367:72794]
:LOGNDROP - [0:0]
-A INPUT ! -s 192.168.192.0/24 -p tcp -m state --state NEW -j LOG --log-prefix "[New Connection]: "
COMMIT
# Completed on Sat Jun 28 14:02:33 2014
Related
I'm using Ubuntu and I have my subversion server running as you can see below:
root 31422 1 0 06:45 ? 00:00:00 /usr/bin/svnserve -d -r /var/svn/repos --log-file=/var/log/svnserve.log
I want to whitelist my subversion server, in other words, I want to allow only my IP address to checkout, commit, log, etc. Does svnserve support that?
NOTE: I'm not using Apache to access my subversion.
svnserve listens on TCP port 3690 by default, so you can use any firewalling solution the restrict access to this port. For example with iptables:
# Let the internal network access it
iptables -A INPUT -s 192.168.0.0/8 -p tcp --dport 3690 -j ACCEPT
# Let a specific external IP access it
iptables -A INPUT -s 1.1.1.1 -p tcp --dport 3690 -j ACCEPT
# Drop all the rest
iptables -A INPUT -p tcp --dport 3690 -j DROP
It would however be better security-wise if you would switch to apache + dav_svn as you get SSL encryption and user authentication and it's not too complicated to setup: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html
I am having some trouble understanding iptables. I know it acts as a filter but something isn't clicking because it isn't working the way I think it should. Let me start by saying that I'm creating a white list, so all policies (INPUT, FORWARD, OUTPUT) default to DROP.
I have the following rules related to SMTP:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --dport 25 -j ACCEPT //needed for receiving?
-A OUTPUT -p tcp --sport 25 -j ACCEPT //needed for sending?
*these 3 lines also exist verbatim for ports 587 & 465
If I remove the first OUTPUT line then my server won't receive emails & if I remove the last line it won't send emails. What I don't understand is why. Shouldn't:
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --sport 25 -j ACCEPT
be enough to let everything through? AFAIK all SMTP communication should go over 25, 587 or 465. My current understanding says an SMTP packet should always match one of these two rules. All input packets should come to port 25, and all output packets be sent from 25? What am I missing?
For SMTP you don't need any --sport rule. The source and destination don't depend on direction - they're match on the packet's source and destination ports. Every connection will have a random source port, so there's nothing to match on.
If I remove the first OUTPUT line then my server won't receive emails & if I remove the last line it won't send emails.
This is wrong. Only the INPUT line matters for receiving emails. Also, only the OUTPUT --dport 25 line matters for sending emails. So these rules should be enough:
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --dport 25 -j ACCEPT
The problem may be that you set OUTPUT to default to DROP, but allowed established connection on INPUT only. Usually people leave OUTPUT defaulting to ACCEPT. If you want to continue using a whitelist for OUTPUT, you'll have to add:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Also, please read up on SMTP ports. Some of those you listed are only needed for email submissions and deprecated encryption, not for server-to-server communication. This may change how you plan your rules.
Previous answer state: Also, only the OUTPUT --dport 25 line matters for sending emails.
This is not always true. For instance some systems are configured as smarthost where the MTA become a client. In such case, the MTA will connect to a remote server on submission port (587) USING SASL authentication to send mails.
To resume, a client is sending mail through a remote server and the remote server itself connect to another remote server on port 587 with SASL authentication.
In such case, the following iptable rules applies (for the smarthost)
iptables -I OUTPUT -p -tcp -dport 597 -j ACCEPT
iptables -I INPUT -p -tcp -sport 587 -j ACCEPT
I am facing an issue and need your expert advice.
I get constant brute force attacks warnings in directadmin from IPs in Russia & China etc etc.
The messages are something like
Feb 27 04:31:15 host1 dovecot[2387]: pop3-login: Aborted login (auth failed, 1 attempts in 2 secs): user=<postmaster#domain.com>, method=PLAIN, rip=194.63.XXX.XXX, lip=XX.XX.99.210, session=<aC8bgAkQ2ADCP45l>
Feb 27 04:31:05 host1 exim[2385]: exim: Aborted login (auth failed, 10 attempts in 20 secs): user=<postmaster#domain.com>, method=PLAIN, rip=194.63.XXX.XXX, lip=XX.XX.99.210, session=<aC8bgAkQ2ADCP45l>
It is not a commercial hosting so only 4-5 different ip addresses actually logs into the email clients to check emails.
So I have decided to block all ip addresses accessing port 25, 465, 587 by putting this in the /etc/csf/csf.deny
tcp:in:d=25:s=0.0.0.0/0
tcp:in:d=465:s=0.0.0.0/0
tcp:in:d=587:s=0.0.0.0/0
And i allowed my ip addresses in the /etc/csf/csf.allow
Is this a good idea?
Can still outside world email me? Port 25 is blocked?
tcp:in:d=25:s=124.12.0.0/20
tcp:in:d=465:s=124.12.0.0/20
tcp:in:d=587:s=124.12.0.0/20
Please advise.
Thank you so much.
Server: Debian GNU/Linux 7.5 x86_64 / Direct Admin / CSF Firewall
A good solution would be to use Fail2ban.
Fail2ban is a Daemon to ban hosts that cause multiple authentication errors
And it uses iptables to do the work.
By default it won't block SMTP attacks, but you can edit its config file /etc/fail2ban/jail.local like this:
[...]
[sendmail]
enabled = true
port = smtp,ssmtp
filter = sendmail
logpath = /var/log/mail.log
bantime = 28800
action = iptables-multiport[name=sendmail, port="pop3,imap,smtp,pop3s,imaps,smtps", protocol=tcp]
Just make sure paths and ports are correct with your config.
Iptables has the ability to inspect the contents of a packet. With that you can look for authentication errors and add them to a ban list. Our mail server is under a constant dictionary attack from a number of sources and this has rate limited that from 10 per minute to one every 5 minutes or do. This is an abbreviated sample, the full script is at http://www.wiseoldcat.com/?q=node/32. The format is the CentOS/Redhat /etc/sysconfig/iptables or iptables-save. This approach could be adapted for imap and pop
:SMTP_Check_Auth_OUTPUT - [0:0]
:SMTP_Check_Auth_INPUT - [0:0]
....
# add jumps for NEW connections to our filters on the INPUT chain for the SMTP and SUBMISSION ports
-A INPUT -p tcp -m multiport --dports 25,587 -m state --state NEW -j SMTP_Check_Auth_INPUT
....
# Add the authentication filter on the OUTPUT side
-A OUTPUT -p tcp -m multiport --sports 25,587 -m state --state ESTABLISHED,RELATED -j SMTP_Check_Auth_OUTPUT
....
# one of our netblocks so RETURN
-A SMTP_Check_Auth_OUTPUT -d 123.123.123.0/24 -j RETURN
# if the contents packet do NOT have the authentication error string then RETURN - customize for your mailserver
-A SMTP_Check_Auth_OUTPUT -p tcp -m string --to 120 --algo kmp --string ! "535 5.7.0 authentication failed" -j RETURN
# set an entry in the recent table
-A SMTP_Check_Auth_OUTPUT -p tcp -m recent --name SMTP_AUTH_ERROR --set --rdest
-A SMTP_Check_Auth_OUTPUT -j LOG --log-prefix "SMTP_AUTH_FAIL: Strike: "
....
# Add the target for the INPUT side
# we are here because this is a new connection - if there hasn't been 3 hits in 20 minutes then RETURN - adjust to your needs
-A SMTP_Check_Auth_INPUT -m recent ! --rcheck --name SMTP_AUTH_ERROR --seconds 1200 --hitcount 3 --rsource -j RETURN
# tag it again
-A SMTP_Check_Auth_INPUT -p tcp -m recent --name SMTP_AUTH_ERROR --set --rsource
# and REJECT the connection
-A SMTP_Check_Auth_INPUT -j REJECT --reject-with icmp-port-unreachable
I have an apache web server where most of my content is hosted, and then I have a node.js server I'm using for various tasks as well. I want users to be able to get information from my node.js server only through reverse proxy from my apache server. I understand how to set up a reverse proxy using mod_proxy on the apache side, but how can I restrict access to the node server except through an apache virtual host? One option I'm sure would work is to host my node server on a separate box and block any ip address except the apache server. Is there a way though that I could have them both running on the same machine and configure node to reject requests except from the apache server?
You could have the running on the same box. In the Node server have something like the following:
if(req.socket.remoteAddress !== '127.0.0.1'){
res.writeHead(403, {"Content-Type": "text/plain"});
res.write('403 Access Denied');
res.end();
} else {
// allow access
doSomething();
}
Of course, that allows other processes on the same box to connect to the Node server.
I've done this using iptables, allowing incoming connections to port 80 for the webserver. Access to port 3000 from the webserver is allowed because it's coming from the same host.
Here's an example rule file:
*filter
# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allows all outbound traffic
# You could modify this to only allow certain traffic
-A OUTPUT -j ACCEPT
# Allows connections for HTTP
-A INPUT -p tcp --dport 80 -j ACCEPT
# Allows SSH connections
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
# Now you should read up on iptables rules and consider whether ssh access
# for everyone is really desired. Most likely you will only allow access from certain IPs.
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# log iptables denied calls (access via 'dmesg' command)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
# Reject all other inbound - default deny unless explicitly allowed policy:
-A INPUT -j REJECT
-A FORWARD -j REJECT
COMMIT
Put this file on your server (e.g. /etc/iptables.up.rules), and run the iptables command to update your iptables rules.
iptables-restore < /etc/iptables.up.rules
I've installed Confluence on Debian Linux 7.0. It runs on 8081 port (for connector, 8091 is used as TomCat server port). I've configured Apache to act as reverse proxy and serve on https://confluence.<mydomain>.com (SSL is configured on Apache side).
The configuration worked perfect unless I set up firewall rules. It still works as expected but became extremely slow (memory and CPU utilisations are low). Switching firewall off brings the performance back to normal. The set of firewall rules for IPv4 is:
*filter
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
# Allow all loopback (lo0) traffic
-A INPUT -i lo -j ACCEPT
# Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# Allows SSH connections
-A INPUT -p tcp --dport 22 -j ACCEPT
# Allow all HTTP and HTTPS connections
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
COMMIT
IPv6 traffic is completely disabled:
*filter
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
COMMIT
I'm using Oracle JVM (1.7), startup options are configured in the following way:
JAVA_OPTS="-Xms512m -Xmx2048m -XX:MaxPermSize=1024m $JAVA_OPTS -Djava.awt.headless=true"
Confluence version is "Confluence 5.4.2 - Standalone (TAR.GZ Archive)", license is Starter (10 users). Database is locally installed PostreSQL.
Anyone has an idea on what I'm doing wrong?