Spoofing IP Addresses when sending emails

[Hugo]

Spammers have been going through our SMTP server; the server accepts
emails from a trusted
white list IPs. I am certain that none of the trusted IP machines are
compromised.

Is it possible to spoof IP address for generating spam? I.e. outgoing
SMTP connections?

It is late in the day so my hypothesis may be crazy: I am assuming
that there a machine(s) that is spoofing IP address in packets for
SMTP connections to our mail server. Can outgoing SMTP transactions
exist without receiving ACK responses back on the packet level?

 

[Mark Space]

Is it possible to spoof IP address for generating spam? I.e. outgoing
SMTP connections?

Yes.

Any field in a TCP packet can be spoofed, regardless of port number or
protocol. Source IP address spoofing is well known. It's even possible
to by-pass firewalls and internal intra-LAN controls if you allow
source-routed packets.

This is why you must always use encryption. Only some form of shared
secret is secure. Please upgrade your stupid spam generating software
already. Please read up on security before putting your easily hackable
junk on the internet.

 

[Tom Anderson]

Yes.

Any field in a TCP packet can be spoofed, regardless of port number or
protocol. Source IP address spoofing is well known. It's even possible
to by-pass firewalls and internal intra-LAN controls if you allow
source-routed packets.

This is why you must always use encryption.

Steady on, old chap. SYN cookies would do the job nicely. As would
configuring his router to reject packets coming from the outside world
which have a source address that belongs to the local network.

If i were the OP, i'd double-check my assumption that the packets really
aren't coming from a local machine. If his network is a single ethernet
address space, i'd log the IP and physical addresses of the spam packets,
and see what the physical address corresponds to.

tom

 

[Mark Space]

Steady on, old chap. SYN cookies would do the job nicely. As would
configuring his router to reject packets coming from the outside world
which have a source address that belongs to the local network.

If i were the OP, i'd double-check my assumption that the packets really
aren't coming from a local machine. If his network is a single ethernet
address space, i'd log the IP and physical addresses of the spam
packets, and see what the physical address corresponds to.

That's what I'm saying. Those "physical" IP addresses in the packets
can be spoofed. They're just data to the lower (link, etc) layers, you
can put anything you want in a TCP header. I'm not talking about email
headers. That's TCP's payload. I'm talking about the TCP header info
itself.

My ISP (AT&T, which used to be SBC, hence my email address in this post)
has used SSL for a long time to ID customers connecting to it's email
server. Thunderbird has a check box for it -- that's all a user needs
to do if you use the default settings. Gmail (which I also have an
account with) uses SSL too. Just based on those two data points, I'd
recommend SSL.

Wikipedia has some good info under its SMTP entry. Including the advice
to not "relay email from an external IP address to an external IP
address" which pretty much covers this whole issue. Beyond that, I'd
recommend reading the man page for sendmail to configure it for SSL.
O'Reilly has some good books on security and configuration too.
However, that's not my profession so I'll leave it to others to point
out the best sources of information for the beleaguered sysadmin.

 

[steve]

That's what I'm saying. Those "physical" IP addresses in the packets
can be spoofed. They're just data to the lower (link, etc) layers, you
can put anything you want in a TCP header. I'm not talking about email
headers. That's TCP's payload. I'm talking about the TCP header info
itself.

My ISP (AT&T, which used to be SBC, hence my email address in this post)
has used SSL for a long time to ID customers connecting to it's email
server. Thunderbird has a check box for it -- that's all a user needs
to do if you use the default settings. Gmail (which I also have an
account with) uses SSL too. Just based on those two data points, I'd
recommend SSL.

Wikipedia has some good info under its SMTP entry. Including the advice
to not "relay email from an external IP address to an external IP
address" which pretty much covers this whole issue. Beyond that, I'd
recommend reading the man page for sendmail to configure it for SSL.
O'Reilly has some good books on security and configuration too.
However, that's not my profession so I'll leave it to others to point
out the best sources of information for the beleaguered sysadmin.

It's really is NOT hard, even without spoofing.
I did something like this for one of my MSc projects. (working proof of
concept)
written in java, it bounced the emails off an open printer in "red neck"
country, what's really funny ,was i went in via a public IP but bounced from
the printers internal network address to the Email servers internal
address.

get a decent firewall
"endian" will do the trick and will block all this shit plus it's open
source.

 

[Mark Space]

It's really is NOT hard, even without spoofing.
I did something like this for one of my MSc projects. (working proof of
concept)
written in java, it bounced the emails off an open printer in "red neck"
country, what's really funny ,was i went in via a public IP but bounced from
the printers internal network address to the Email servers internal
address.

Agreed. I first learned about it reading the docs for IPFILTER, the
firewall that comes with FreeBSD. I was just setting up a NAT/Firewall
server in my house as a fun project. Hobbyist stuff.

IPFILTER also runs on multiple platforms, btw. I found it much, much
more clear to configure than IPTABLES.

<http://www.freebsd.org/doc/en/books/handbook/firewalls-ipf.html>

get a decent firewall
"endian" will do the trick and will block all this shit plus it's open
source.

I think some attempt at general understanding of security issues would
be the best starting point. A firewall is part of a solution, not a
complete solution. In the OPs case, he had a misconfigured SMTP server
(imo). A firewall won't help with configuration of HTTP either.
Consider all the problems one could have with, say, SQL injection in a
Java EE App if data isn't validated properly. The list goes on-and-on.

It's a fascinating subject though. Always something new to learn.